| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes the Application Architecture part of Phase C.
The objectives of the Application Architecture part of Phase C are to:
As part of this phase, the architecture team will need to consider what relevant Application Architecture resources are available in the Architecture Repository (see Part V, 41. Architecture Repository).
In particular:
The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) - see Part VI, 44. Integrated Information Infrastructure Reference Model - that focuses on the application-level components and services necessary to provide an integrated information infrastructure.
This section defines the inputs to Phase C (Application Architecture).
The level of detail addressed in Phase C will depend on the scope and goals of the overall architecture effort.
New application building blocks being introduced as part of this effort will need to be defined in detail during Phase C. Existing application building blocks to be carried over and supported in the target environment may already have been adequately defined in previous architectural work; but, if not, they too will need to be defined in Phase C.
The order of the steps in this phase (see below as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.
All activities that have been initiated in these steps must be closed during the Finalize the Application Architecture step (see 11.4.8 Finalize the Application Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 11.4.9 Create Architecture Definition Document).
The steps in Phase C (Application Architecture) are as follows:
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 III, 23. Architecture Principles.
Select relevant Application Architecture resources (reference models, patterns, etc.) from the Architecture Repository, on the basis of the business drivers, the stakeholders, and their concerns.
Select relevant Application Architecture viewpoints (for example, stakeholders of the applications - viewpoints relevant to functional and individual users of applications, etc.); i.e., those that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Application 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 Application Architectures that preserves the business logic from changes to the underlying platform and implementation technology.
For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.
Ensure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models (see above).
The recommended process for developing an Application Architecture is as follows:
The level and rigor of decomposition needed varies from enterprise to enterprise, as well as within an enterprise, and the architect should consider the enterprise's goals, objectives, scope, and purpose of the enterprise architecture effort to determine the level of decomposition.
The level of granularity should be sufficient to enable identification of gaps and the scope of candidate work packages.
The organization's Application Portfolio is captured as a catalog within the Architecture Repository. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., logical application component -> physical application component ->] information system service).
Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.
The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.
The following catalogs should be considered for development within an Application Architecture:
Matrices show the core relationships between related model entities.
Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.
Once the baseline Application Portfolio has been assembled, it is necessary to map the applications to their purpose in supporting the business. The initial mapping should focus on business services within the Business Architecture, as this is the level of granularity where architecturally significant decisions are most likely to be needed.
Once applications are mapped to business services, it will also be possible to make associations from applications to data, through the business-information diagrams developed during Business Architecture.
If readily available, baseline application data models may be used to validate the Business Architecture and also to identify which data is held locally and which is accessed remotely.
The Data Architecture phase will focus on these issues, so at this point it may be appropriate to drop into a short iteration of Data Architecture if it is deemed to be valuable to scope of the architecture engagement.
Using existing information in the baseline application catalog, the Application Architecture should identify user and organizational dependencies on applications. This activity will support future state planning by determining impacted user communities and also facilitating the grouping of application by user type or user location.
A key user community to be specifically considered is the operational support organization. This activity should examine application dependencies on shared operations capabilities and produce a diagram on how each application is effectively operated and managed.
Specifically considering the needs of the operational community may identify requirements for new or extended governance capabilities and applications.
The following matrices should be considered for development within an Application Architecture:
The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.
Diagrams present the Application Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.
Once the desired functionality of an application is known, it is necessary to perform an internal assessment of how the application should be best structured to meet its requirements.
In the case of packaged applications, it is likely to be the case that the application supports a number of configuration options, add-on modules, or application services that may be applied to the solution. For custom developed applications, it is necessary to identify the high-level structure of the application in terms of modules or sub-systems as a foundation to organize design activity.
The following diagrams should be considered for development within an Application Architecture:
The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.
Once the Application Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the application-focused requirements for implementing the Target Architecture.
These requirements may:
Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).
Develop a Baseline Description of the existing Application Architecture, to the extent necessary to support the Target Application Architecture. The scope and level of detail to be defined will depend on the extent to which existing applications are likely to be carried over into the Target Application Architecture, and on whether architecture descriptions exist, as described in 11.2 Approach. To the extent possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository). If not already existing within the Architecture Repository, define each application in line with the Application Portfolio catalog (see Part IV, 34. Content Metamodel).
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.
Develop a Target Description for the Application Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Data Architecture. The scope and level of detail to be defined will depend on the relevance of the applications elements to attaining the Target Architecture Vision, and on whether architectural descriptions exist. To the extent possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.
Verify the architecture models for internal consistency and accuracy:
Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.
Following creation of a Baseline Architecture, Target Architecture, and gap analysis, an application roadmap is required to prioritize activities over the coming phases.
This initial Application Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.
Once the Application Architecture is finalized, it is necessary to understand any wider impacts or implications.
At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:
Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Application Architecture. Conduct an impact analysis, to identify any areas where the Business and Data Architectures (e.g., business practices) may need to change to cater for changes in the Application Architecture (for example, changes to forms or procedures, applications, or database systems). If the impact is significant, this may warrant the Business and Data Architectures being revisited.
Identify any constraints on the Technology Architecture (especially the infrastructure) about to be designed.
The outputs of Phase C (Application Architecture) may include, but are not restricted to:
The outputs may include some or all of the following:
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G116.