7. Phase C: Information Systems Architectures — Application Architecture

This chapter describes the Application Architecture part of Phase C.

7.1 Objectives

The objectives of the Application Architecture part of Phase C are to:

• Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
• Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures

7.2 Inputs

This section defines the inputs to Phase C (Application Architecture).

7.2.1 Reference Materials External to the Enterprise

• Architecture reference materials (see the TOGAF Standard — Architecture Content)

7.2.2 Non-Architectural Inputs

• Request for Architecture Work (see the TOGAF Standard — Architecture Content)
• Capability Assessment (see the TOGAF Standard — Architecture Content)
• Communications Plan (see the TOGAF Standard — Architecture Content)

7.2.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see the TOGAF Standard — Architecture Content), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy
• Tailored Architecture Framework (see the TOGAF Standard — Architecture Content), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Application principles (see the TOGAF Standard — ADM Techniques), if existing
• Statement of Architecture Work (see the TOGAF Standard — Architecture Content)
• Architecture Vision (see the TOGAF Standard — Architecture Content)
• Architecture Repository (see the TOGAF Standard — Architecture Content), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Draft Architecture Definition Document, which may include Baseline and/or Target Architectures of any architecture domain
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including:
  • Gap analysis results (from Business Architecture and Data Architecture, if available)
  • Relevant technical requirements that will apply to this phase
• Business and Data Architecture components of an Architecture Roadmap, if available (see the TOGAF Standard — Architecture Content),

7.3 Steps

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 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 the TOGAF Standard — Applying the ADM.

All activities that have been initiated in these steps should be closed during the Finalize the Application Architecture step (see 7.3.8 Finalize the Application Architecture). The documentation generated from these steps must be formally published in the Create/Update the Architecture Definition Document step (see 7.3.9 Create/Update the Architecture Definition Document).

The steps in Phase C (Application Architecture) are as follows:

• Select reference models, viewpoints, and tools (see 7.3.1 Select Reference Models, Viewpoints, and Tools)
• Develop Baseline Application Architecture Description (see 7.3.2 Develop Baseline Application Architecture Description)
• Develop Target Application Architecture Description (see 7.3.3 Develop Target Application Architecture Description)
• Perform gap analysis (see 7.3.4 Perform Gap Analysis)
• Define candidate roadmap components (see 7.3.5 Define Candidate Roadmap Components)
• Resolve impacts across the Architecture Landscape (see 7.3.6 Resolve Impacts Across the Architecture Landscape)
• Conduct formal stakeholder review (see 7.3.7 Conduct Formal Stakeholder Review)
• Finalize the Application Architecture (see 7.3.8 Finalize the Application Architecture)
• Create/Update the Architecture Definition Document (see 7.3.9 Create/Update the Architecture Definition Document)

7.3.1 Select 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 the TOGAF Standard — ADM Techniques.

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 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.

7.3.1.1 Determine Overall Modeling Process

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:

• Understand the list of applications or application components that are required, based on the baseline Application Portfolio, what the requirements are, and the Business Architecture scope
• 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 logical applications and the most appropriate physical applications
• Develop matrices across the architecture by relating applications to business services, business capabilities, data, processes, etc.
• Elaborate a set of Application Architecture views by examining how the application will function, capturing integration, migration, development, and operational concerns

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.

7.3.1.2 Identify Required Catalogs of Application Building Blocks

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 -> application service).

Catalogs form the raw material for the development of matrices and diagrams and also act as a key resource for managing the business and IT capability.

The structure of catalogs is based on the attributes of metamodel entities, as defined in the TOGAF Standard — Architecture Content.

The TOGAF Standard — Architecture Content contains a detailed description of catalogs which should be considered for development within an Application Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

7.3.1.3 Identify Required Matrices

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 the Data Architecture if it is deemed to be valuable to the 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 applications 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 TOGAF Standard — Architecture Content contains a detailed description of matrices which should be considered for development within an Application Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

7.3.1.4 Identify Required Diagrams

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 subsystems as a foundation to organize design activity.

The TOGAF Standard — Architecture Content contains a detailed description of diagrams which should be considered for development within an Application Architecture, describing them in detail and relating them to entities, attributes, and relationships in the TOGAF Enterprise Metamodel.

7.3.1.5 Identify Types of Requirement to be Collected

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:

• Relate to the application domain
• Provide requirements input into the Data and Technology Architectures
• Provide detailed guidance to be reflected during design and implementation to ensure that the solution addresses the original architecture requirements

Within this step, the architect should identify requirements that should be met by the architecture (see 13.5.2 Requirements Development).

7.3.2 Develop Baseline Application Architecture Description

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 7.5 Approach . To the extent possible, identify the relevant Application Architecture building blocks, drawing on the Architecture Repository (see the TOGAF Standard — Architecture Content). If not already existing within the Architecture Repository, define each application in line with the Application Portfolio catalog (see the TOGAF Standard — Architecture Content).

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.

7.3.3 Develop Target Application Architecture Description

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 application 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 the TOGAF Standard — Architecture Content).

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.

If appropriate, investigate different Target Architecture alternatives and discuss these with stakeholders using the Architecture Alternatives and Trade-offs technique (see the TOGAF Standard — ADM Techniques).

7.3.4 Perform Gap Analysis

Verify the architecture models for internal consistency and accuracy:

• 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 Repository, and document
• Test architecture models for completeness against requirements

Identify gaps between the baseline and target, using the gap analysis technique as described in the TOGAF Standard — ADM Techniques.

7.3.5 Define Candidate Roadmap Components

Following the 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.

7.3.6 Resolve Impacts Across the Architecture Landscape

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:

• Does this Application Architecture create an impact on any pre-existing architectures?
• Have recent changes been made that impact the Application Architecture?
• Are there any opportunities to leverage work from this Application Architecture in other areas of the organization?
• Does this Application Architecture impact other projects (including those planned as well as those currently in progress)?
• Will this Application Architecture be impacted by other projects (including those planned as well as those currently in progress)?

7.3.7 Conduct Formal Stakeholder Review

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.

7.3.8 Finalize the Application Architecture

• Select standards for each of the building blocks, re-using as much as possible from the reference models selected from the Architecture Repository
• Fully document each building block
• Conduct a final cross-check of overall architecture against business requirements; document the rationale for building block decisions in the architecture document
• Document the final requirements traceability report
• Document the final mapping of the architecture within the Architecture Repository; from the selected building blocks, identify those that might be re-used, and publish via the Architecture Repository
• Finalize all the work products, such as gap analysis

7.3.9 Create/Update the Architecture Definition Document

• Document the rationale for building block decisions in the Architecture Definition Document
• Prepare the Application Architecture sections of the Architecture Definition Document; if appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture; route the document for review by relevant stakeholders, and incorporate feedback

7.4 Outputs

The outputs of Phase C (Application Architecture) may include, but are not restricted to:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Statement of Architecture Work (see the TOGAF Standard — Architecture Content), updated if necessary
  • Validated application principles, or new application principles (if generated here)
  
  
• Draft Architecture Definition Document (see the TOGAF Standard — Architecture Content), including:
  • Baseline Application Architecture, Approved, if appropriate
  • Target Application Architecture, Approved
  • Views corresponding to the selected viewpoints, addressing key stakeholder concerns
• Draft Architecture Requirements Specification (see the TOGAF Standard — Architecture Content), including such Application Architecture requirements as:
  • Gap analysis results
  • Applications interoperability requirements
  • Relevant technical requirements that will apply to this evolution of the architecture development cycle
  • Constraints on the Technology Architecture about to be designed
  • Updated business requirements, if appropriate
  • Updated data requirements, if appropriate
• Application Architecture components of an Architecture Roadmap (see the TOGAF Standard — Architecture Content)

The TOGAF Standard — Architecture Content contains a detailed description of architectural artifacts which might be produced in this phase.

7.5 Approach

7.5.1 Architecture Repository

As part of this phase, the architecture team will need to consider what relevant Application Architecture resources are available in the Architecture Repository (see the TOGAF Standard — Architecture Content).

In particular:

• Generic business models and related application models relevant to the organization's industry sector
• 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 the TOGAF® Series Guide: The TOGAF Integrated Information Infrastructure Reference Model (III-RM) — that focuses on the application-level components and services necessary to provide an integrated information infrastructure.

---

---