This chapter describes the Application Architecture part of Phase C.

11.1 Objectives

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.

11.2 Approach

11.2.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 Part V, 41. Architecture Repository).

In particular:

• Generic business models relevant to the organization's industry "vertical" sector; for example:
  • The TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed applications models relevant to the Telecommunications industry.
  • The Object Management Group (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 Part VI, 44. 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 - 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. The Unified Modeling Language (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.

11.3 Inputs

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

11.3.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 36.2.5 Architecture Repository)

11.3.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work)
• Capability Assessment (see Part IV, 36.2.10 Capability Assessment)
• Communications Plan (see Part IV, 36.2.12 Communications Plan)

11.3.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), 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 Part IV, 36.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Application principles (see Part III, 23.6.3 Application Principles), if existing
• Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
• Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
• Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
  • Baseline Business Architecture, Version 1.0 (detailed), if appropriate
  • Target Business Architecture, Version 1.0 (detailed)
  • Baseline Data Architecture, Version 1.0 (detailed), or Version 0.1 (Vision)
  • Target Data Architecture, Version 1.0 (detailed), or Version 0.1 (Vision)
  • Baseline Application Architecture, Version 0.1, if appropriate and if available
  • Target Application Architecture, Version 0.1, if available
  • Baseline Technology Architecture, Version 0.1 (Vision)
  • Target Technology Architecture, Version 0.1 (Vision)
• Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), 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 Part IV, 36.2.7 Architecture Roadmap)

11.4 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 (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:

• 11.4.1 Select Reference Models, Viewpoints, and Tools
• 11.4.2 Develop Baseline Application Architecture Description
• 11.4.3 Develop Target Application Architecture Description
• 11.4.4 Perform Gap Analysis
• 11.4.5 Define Roadmap Components
• 11.4.6 Resolve Impacts Across the Architecture Landscape
• 11.4.7 Conduct Formal Stakeholder Review
• 11.4.8 Finalize the Application Architecture
• 11.4.9 Create Architecture Definition Document

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

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

Examples of applications models are:

• The TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed applications models relevant to the Telecommunications industry.
• The Object Management Group (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.

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
• Identify logical applications and the most appropriate physical applications
• Develop matrices across the architecture by relating applications to business service, business function, data, process, 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.

11.4.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 ->] 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:

• Application Portfolio catalog
• Interface catalog

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

• System/Organization matrix
• Role/System matrix
• Application Interaction matrix
• System/Function matrix

The structure of matrices is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel .

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

The following diagrams should be considered for development within an Application Architecture:

• Application Communication diagram
• Application and User Location diagram
• Enterprise Manageability diagram
• Process/System Realization diagram
• Application Migration diagram
• Software Distribution diagram
• Software Engineering diagram

The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel .

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

Within this step, the architecture engagement should identify types of requirement that must be met by the architecture implementation, including:

• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Application Architecture principles
• Policies
• Standards
• Guidelines
• Specifications

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

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

11.4.4 Perform Gap Analysis

First, verify the architecture models for internal consistency and accuracy.

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:

• Create gap matrix, as described in Part III, 27. Gap Analysis
• 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 that should be procured

11.4.5 Define Roadmap Components

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.

11.4.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)?

11.4.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, application systems, 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.

11.4.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 final cross-check of overall architecture against business requirements; document rationale for building block decisions in the architecture document
• Document final requirements traceability report
• Document 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

11.4.9 Create Architecture Definition Document

• Document rationale for building block decisions in the Architecture Definition Document
• Prepare 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

11.5 Outputs

The outputs of Phase C (Application Architecture) include:

• Refined and updated versions of the Architecture Vision phase deliverables, where applicable:
  • Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work), updated if necessary
  • Validated application principles, or new application principles (if generated here)
• Draft Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document), including:
  • Baseline Application Architecture, Version 1.0, if appropriate
  • Target Application Architecture, Version 1.0
    • Process systems model
    • Place systems model
    • Time systems model
    • People systems model
  • Views corresponding to the selected viewpoints, addressing key stakeholder concerns
• Draft Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), 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 Part IV, 36.2.7 Architecture Roadmap)

return to top of page