Phase C: Information System Architecture - Applications
Objective Approach Inputs
Steps Outputs
The objective here is to define the major kinds of application system necessary to
process the data and support the business.
It is important to note that this effort is NOT concerned with applications systems
design. The goal is to define what kinds of application systems are relevant to the
enterprise, and what those applications need to do in order to manage data and to present
information to the human and computer actors in the enterprise.
The applications are not described as computer systems, but as logical groups of
capabilities that manage the data objects in the data architecture and support the
business functions in the Business Architecture. The applications and their
capabilities are defined without reference to particular technologies. The applications
are stable and relatively unchanging over time, whereas the technology used to implement
them will change over time, based on the technologies currently available and changing
business needs.
Enterprise Continuum
As part of this Phase, the architecture team will need to consider what relevant
applications architecture resources are available in the Enterprise Continuum.
In particular:
- Generic business models relevant to your organization's industry "vertical"
sector. For example:
- the TeleMangement Forum (TMF) has developed detailed applications models relevant to the
Telecommunications Industry;
- the Object Management Group (OMG) has a number of vertical Domain Task Forces developing
software models relevant to specific domains such as Healthcare, Transportation, Finance,
etc.
- Application models relevant to common high-level business functions, such as electronic
commerce, supply chain management, etc.
The Open Group has a Reference Model for
Integrated Information Infrastructure that focuses on the application-level components
and services necessary to provide an integrated information instructure.
In addition the ebXML Initiative
aims to provide an open, XML-based infrastructure enabling global use of electronic
business information in an interoperable, secure and consistent manner. UML is used for
modelling aspects and XML for syntax aspects. The initiative was formed as a joint venture
by the UN/CEFACT community and the OASIS consortium, with ANSI X.12 also fully
participating.
Gap Analysis
A key step in validating an architecture is to consider what may have been forgotten.
The architecture must support all of the essential information processing needs of the
organization. The most critical source of gaps that should be
considered is stakeholder concerns that have not been addressed in architectural work.
Gap analysis highlights shortfalls in applications services and/or applications
components that have been accidentally left out, deliberately eliminated, or are yet to be
defined. Table 1 in Phase D illustrates an example of a
gap analysis matrix. The suggested steps are as follows:
- Draw up a matrix with all the applications in the current Applications Architecture on
the vertical axis, and all the applications in the Target Applications Architecture on the
horizontal axis.
- Add to the Current Architecture axis a final row labeled 'New Applications', and to the
Target Architecture axis a final column labeled 'Eliminated Applications'.
- Where an application exists in both the current and target architectures, record this
fact with 'Retained' at the intersecting cell.
- Where an application in the current architecture is missing in the target architecture,
the current and target architectures must be reviewed.
- If the current application was correctly eliminated, mark it as such in the appropriate
'Eliminated Applications' cell.
- If the current application is to be replaced, wholly or partly, by one or more
applications in the target architecture, make a note to this effect in the corresponding
intersecting cell(s).
- If the current application was unintentionally eliminated in the target architecture,
note this fact in the appropriate 'Eliminated Applications' cell. The omission will need
to be addressed in an iteration of the Target Applications Architecture design.
- Where an application in the Target Applications Architecture cannot be found in the
current architecture, mark it at the intersection with the 'New' row, as a gap that needs
to filled, either by developing or procuring the application.
- When the exercise is complete, anything under 'Eliminated Applications' or 'New
Applications' is a potential gap, which should either be explained as correctly
eliminated, or marked as to be addressed, either by reinstating in the target
architecture, or by developing/procuring the application.
- Check that the applications gap analysis is complete.
Table 1 in Phase D illustrates an example of a gap
analysis matrix.
Inputs to this phase are:
- Applications Baseline Description. Develop a baseline description of
the existing Applications architecture, to the extent necessary to support the target
Applications Architecture. The scope and level of detail to be defined will depend on the
extent to which existing Application components are likely to be carried over into the
target Applications architecture, and on whether existing architectural descriptions
exist, as describe under Approach, above. Define for each
application:
- Name (short and long)
- Who maintains
- Owner(s) / business unit(s) responsible for requirements
- Other users
- Plain language description of what the application does (not how it does it)
- Status (planned, operational, obsolete)
- Business functions supported
- Organizational units supported
- Hardware / software platform(s) on which it runs
- Networks used
- Precedent and successor applications
To the extent possible, identify the relevant Applications architecture building
blocks, drawing on the Architecture Continuum.
- Principles, Reference Models, Viewpoints and Tools:
- Review and validate (or generate, if necessary) the set of Applications principles.
- These will normally form part of an overarching set of Architecture Principles.
Guidelines for developing and applying principles, and a sample set of Applications
principles, are given in Part IV, Architecture
Principles.
- Select relevant Applications architecture resources (reference models, patterns, etc.)
from the Architecture Continuum, on the basis of the business drivers, and the
stakeholders and concerns.
- Select relevant Applications architecture viewpoints (for example, stakeholders of
the Applications - viewpoints relevant to functional and individual users of applications,
Software Engineering View, Application-to-application Communication View, Software
Distribution View, Enterprise Manageability View, etc.) - i.e., those that will enable the
architect to demonstrate how the stakeholder concerns are being addressed in the
Applications Architecture.
- Identify appropriate tools and techniques to be used for capture, modeling, and
analysis, in association with the selected viewpoints. Depending on the degree of
sophistication warranted, these may comprise simple documents or spreadsheets, or more
sophisticated modeling tools and techniques.
- Consider using platform-independent descriptions of business logic. For example, the
OMG's Model-Driven Architecture offers an approach to modeling application architectures
that preserves the business logic from changes to the underlying platform and
implementation technology.
- Architecture Model(s).
- For each viewpoint, create the model for the specific view required, using the selected
tool or method. Examples of Applications models are:
- the TeleMangement Forum (TMF) has developed detailed applications models relevant to the
Telecommunications Industry;
- the Object Management Group (OMG) has a number of vertical Domain Task Forces developing
software models relevant to specific domains such as Healthcare, Transportation, Finance,
etc.
- Assure that all stakeholder concerns are covered. If they are not, create new models to
address concerns not covered, or augment existing models (see above).
Model at least the following:
- Relate the application systems to the business functions in the Business Architecture.
- For each application, identify each lowest level business function that it supports in
the Business Architecture.
- Generate Application-Business Function matrices tabulating all the relationships.
- Review and validate the Application-Business Function matrices. In cases where a
business function is supported by more than one application, check for any unnecessary
duplication of functionality (and if found, eliminate it by redefining the applications
concerned).
- Identify any business functions not supported by an applicaiton, and rationalize: either
provide application support by amending or updating the set of application definitions,
iterating steps 1 - 3; or else document the reason why no application support is
warranted.
- Use the Application-Business Function matrices generated under step (ii) above, and the
business function-to-organizational-unit mappings (business functions cross-linked to the
organizational units that perform them) contained in the Business Architecture, to relate
the application systems to the organizational units that they support.
- Ensure that all information requirements in the Business Architecture are met.
- Perform trade-off analysis to resolve conflicts (if any)
among the different views.
- Validate that the models support the principles, objectives and constraints.
- Note changes to the viewpoint represented in the selected models from the Architecture
Continuum, and document.
- Test architecture models for completeness against requirements.
- Identify candidate application systems.
- Review the re-usable architecture building blocks and re-usable solution building blocks
from the enterprise's Architecture Continuum, the Business Scenario description, and the
Baseline Description, and list all the potential application systems.
- If available, review the Entity-to-business-function matrices from the Data
Architecture, and identify potential applications to perform the required data management
functions, and/or to automate particular business functions.
- Even if a complete Data Architecture is not available, review whatever lists of data
exist
- Develop a user location / applications matrix
- Brainstorm other potential application systems based on innovative use of new
developments in technology.
- Merge all lists into a single, deduplicated list of candidate application systems,
including for each a brief description of business function(s) supported and data /
information managed.
- Create application definitions for all candidate application systems. For each
application:
- Assign a unique name and identifier.
- Write a brief description of what the application does (not how it works).
- Write a brief description of the business benefits arising from the application.
- Simplify complicated applications by decomposing them into two or more applications.
- Ensure that the set of application definitions is internally consistent, by removing
duplicate functionality as far as possible, and combining similar applications into one.
- Identify technology requirements and candidate technology building blocks, where this
affects the applications design, including re-usable solution building blocks from the
enterprise's Architecture Continuum, and external software packages.
- Identify any critical infrastructure dependencies (e.g., operating system and network
services required).
- Identify any critical application dependencies, and minimize as far as possible.
- Time permitting, relate the applications to the files and databases described in the
Baseline Description, and/or to the data entities defined in the Data Architecture (if
available).
- Time permitting, draw simple diagrams to illustrate views of the applications
architecture relevant to different stakeholders.
- Conduct a formal checkpoint review of the architecture model and
building blocks with stakeholders.
- Review the Application-Business Function matrices generated in step 3, and the Business
Architecture generated in Phase B.
- Review the qualitative criteria (e.g., security, availability,
performance, costs), providing as many measurable criteria as possible (e.g., privacy /
confidentiality, reliability, minimum tolerable outages, cycle requirements and
transaction volume requirements at peak and mean times, numbers and locations of users,
etc.). Use to specify required service levels for Applications services (for example, via
formal Service Level Agreements).
- The goal here is to guide the Data and Technology Architecture efforts as to the
qualities required in the data, and the underlying technology, that support and are
processed by the application.
- Complete the Applications architecture.
- Select standards for each of the architecture building blocks, reusing as much as
possible from the reference models selected from the Architecture Continuum.
- Fully document each architecture building block.
- Final cross check of overall architecture against business requirements. Document
rationale for building block decisions in architecture document.
- Document final requirements traceability report.
- Document final mapping of the architecture within the Architecture Continuum. From the
selected architecture building blocks, identify those that might be reused, and publish
via the architecture repository.
- Document rationale for building block decisions in architecture document.
- Prepare Applications Architecture Report. Generate the Applications Architecture
document. If appropriate, use reports and/or graphics generated by modeling tools to
demonstrate key views of the architecture. Route the Applications Architecture
document for review by relevant stakeholders, and incorporate feedback.
- Checkpoint/Impact analysis: Check the original motivation for the architecture project
and the Statement of Architecture Work against the proposed Applications Architecture.
Conduct an impact analysis, to:
- Identify any areas where the Business Architecture (e.g., business practices) may need
to change to cater for changes in the Applications Architecture (for example, changes to
forms or procedures, application systems or database systems).
- If the impact is significant, this may warrant the Business Architecture being
revisited.
- Identify any areas where the Data Architecture (if generated at this point) may need to
change to cater for changes in the Applications Architecture (or to identify constraints
on the Data Architecture, if about to be designed).
- If the impact is significant, this may warrant the Data Architecture being revisited, if
already developed in this cycle).
- Identify any constraints on the Technology Architecture about to be designed.
- Refine the proposed Applications Architecture only if necessary.
- Gap analysis (see under Approach, above) and report
- Create gap matrix as described above.
- Identify building blocks to be carried over, classifying as either changed or unchanged.
- Identify eliminated building blocks.
- Identify new building blocks.
- Identify gaps and classify as those that should be developed and those inherited.
The outputs of this phase are:
- Statement of Architecture Work (updated if necessary)
- Applications Baseline Description - if appropriate
- Validated Applications Principles, or new Applications Principles (if generated here)
- Target Applications Architecture
- Process Systems Model
- Place Systems Model
- Time Systems Model
- People Systems Model
- Applications interoperability requirements
- Viewpoints addressing key stakeholder concerns.
- Views corresponding to the selected viewpoints; e.g.:
- Common Applications services view
- Applications Interoperability view
- Applications / Information View
- Applications / User locations View
- Gap analysis results
- Applications Architecture Report, summarizing what was done and the key findings
- Impact Analysis
- Areas where the Business Architecture may need to change to cater for changes in the
Applications Architecture
- Identify any areas where the Data Architecture (if generated at this point) may need to
change to cater for changes in the Applications Architecture.
- Constraints on the Technology Architecture about to be designed.
- Updated business requirements (if appropriate)
Copyright © The Open Group, 2002