Phase C: Information System Architectures - Applications
Architecture
Phase C: Information Systems Architectures - Applications
Architecture
Objective |
Approach |
Inputs |
Steps |
Outputs
This chapter describes the Applications Architecture part of Phase C.
Objective
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.
Approach
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 TeleManagement Forum
(TMF) (TMF - www.tmforum.org) has developed detailed applications models relevant to the
Telecommunications industry.
- The Object Management Group
(OMG) (OMG - www.omg.org) has a number of vertical Domain Task Forces developing software models relevant
to specific vertical 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 (III-RM; see Integrated Information Infrastructure Reference Model) that focuses on the application-level
components and services necessary to provide an integrated information infrastructure.
In addition, the ebXML initiative (refer to www.ebxml.org) 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 modeling 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. Gap Analysis Matrix 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 Baseline Applications Architecture on the vertical axis, and all the applications in the Target Applications
Architecture on the horizontal axis.
- Add to the
Current Baseline 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 Baseline and Target Architectures, record this fact with "Retained" at the intersecting cell.
- Where an application in the
current architecture Baseline
Architecture is missing in the Target Architecture, the current Baseline 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, Baseline 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.
Inputs
Inputs to this phase are:
- Application principles (Application Principles), if existing
- Request for Architecture Work (Request for Architecture Work)
- Statement of Architecture Work (Major Output Descriptions)
- Architecture Vision (Business Scenario/Architecture Vision)
- Relevant technical requirements that will apply to this phase
- Gap analysis results (from Business Architecture)
- Baseline Business Architecture, Version
2 1.0
(detailed), if appropriate
- Target Business Architecture (Business Architecture), Version
2 1.0 (detailed)
- Re-usable building blocks, from organization's Enterprise Continuum (Introduction to the
Enterprise Continuum), if available
Data Architecture Baseline Description,
Applications Architecture, Version 0.1, if appropriate and if available
- Target
Data Applications Architecture, Version 0.1, if available
Steps
- Develop Baseline Applications Architecture
Baseline
Description
Develop a Baseline Description of the existing applications architecture, 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 described in Approach . 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.
- Review and Validate Principles, Reference Models, Viewpoints, and Tools
- Review and validate (or generate, if necessary) the set of application principles.
These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying
principles, and a sample set of application principles, are given in Part IV: Resource Base , 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 (MDA)
offers an approach to modeling Applications Architectures that preserves the business logic from changes to the underlying platform
and implementation technology.
- Create 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 TeleManagement Forum
(TMF) (TMF - www.tmforum.org) has developed detailed applications models relevant to the
Telecommunications industry.
- The Object Management Group
(OMG) (OMG - www.omg.org) has a number of vertical Domain Task Forces developing software models relevant
to specific vertical 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:
- Common Applications Services view - both those being consumed, and those being produced for others to consume.
- Applications Interoperability view, assumptions, dependencies, and standards (an example is the LISI Interoperability Model -
refer to www.c3i.osd.mil/org/cio/i3/lisirpt.pdf). Also, The Open Group
has a Reference Model for Integrated Information Infrastructure (III-RM; see Integrated Information
Infrastructure Reference Model) that can be used as a basis for this.
- 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 application, and rationalize: either provide application support by
amending or updating the set of application definitions, iterating Steps 1 to 3; or else document the reason why no application
support is warranted.
- Use the application-business function matrices generated 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.
One method of doing this is CMU/SEI's Architecture Trade-off Analysis (ATA) Method (refer to www.sei.cmu.edu/ata/ata_method.html).
- 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 Candidate Application
Systems
- Review the re-usable Architecture Building Blocks and re-usable
solution building
blocks 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 Consider other potential application
systems based on innovative use of new developments in technology.
- Merge all lists into a single, de-duplicated 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 Solution Building
Blocks from the 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 Formal Checkpoint
Review of the architecture model Architecture
Model and building blocks Building Blocks
with stakeholders. Stakeholders
Review the application-business function matrices generated in Step 3, and the Business Architecture generated in Phase B.
- Review
the qualitative criteria Qualitative
Criteria (e.g., security, availability, performance, costs), costs)
Review the qualitative criteria, 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 (SLAs)).
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, re-using 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 re-used, and publish via the architecture repository.
- Document rationale for building block decisions in architecture document.
- Prepare Applications Architecture
report. 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.
- Perform Gap
analysis Analysis (see Approach) and report Create 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.
Outputs
The outputs of this phase are:
- Statement of Architecture Work (updated if necessary)
Applications Architecture Baseline Description, Applications Architecture, Version 1.0, if
appropriate
- Validated application principles, or new application principles (if generated here)
- Target Applications
Architecture Architecture, Version
1.0
- 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; for example:
- Common Applications Services view
- Applications Interoperability view
- Applications/Information view
- Applications/User Locations view
- Gap analysis results
- Applications Architecture
report, 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
return to top of page
Navigation
The TOGAF document set is designed for use with frames. To navigate around the document:
- In the main Contents frame at the top of the page, click the relevant hyperlink (Part I, Part II, etc.) to load the Contents
List for that Part of the TOGAF document into the Secondary Index frame in the left margin.
- Then click in that Contents List to load a page into this main frame.
return to top of page
Downloads
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site . The license is free to any
organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for
use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063 .
Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group