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

1. Draw up a matrix with all the applications in the Baseline Applications Architecture on the vertical axis, and all the applications in the Target Applications Architecture on the horizontal axis.
2. Add to the Baseline Architecture axis a final row labeled "New Applications", and to the Target Architecture axis a final column labeled "Eliminated Applications".
3. Where an application exists in both the Baseline and Target Architectures, record this fact with "Retained" at the intersecting cell.
4. Where an application in the Baseline Architecture is missing in the Target Architecture, the 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.
5. Where an application in the Target Applications Architecture cannot be found in the 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.
6. 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.
7. 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 1.0 (detailed), if appropriate
• Target Business Architecture (Business Architecture), Version 1.0 (detailed)
• Re-usable building blocks, from organization's Enterprise Continuum (Introduction to the Enterprise Continuum), if available
• Baseline Applications Architecture, Version 0.1, if appropriate and if available
• Target Applications Architecture, Version 0.1, if available

Steps

1. Develop Baseline Applications Architecture 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 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.
   

2. Review and Validate Principles, Reference Models, Viewpoints, and Tools
   1. 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 .

   2. 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.
   3. 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.
   4. 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.

3. Create Architecture Model(s)
   1. 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 - 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.
   2. 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.
   3. Relate the application systems to the business functions in the Business Architecture.
      1. For each application, identify each lowest-level business function that it supports in the Business Architecture.
      2. Generate application-business function matrices tabulating all the relationships.
      3. 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).
      4. 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.
      5. 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.
   4. Ensure that all information requirements in the Business Architecture are met.
   5. 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).

   6. Validate that the models support the principles, objectives, and constraints.
   7. Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
   8. Test architecture models for completeness against requirements.
4. Identify Candidate Application Systems
   1. 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.
   2. 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.
   3. Even if a complete Data Architecture is not available, review whatever lists of data exist.
   4. Develop a user location/applications matrix.
   5. Consider other potential application systems based on innovative use of new developments in technology.
   6. 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.
   7. Create application definitions for all candidate application systems. For each application:
      1. Assign a unique name and identifier.
      2. Write a brief description of what the application does (not how it works).
      3. Write a brief description of the business benefits arising from the application.
      4. Simplify complicated applications by decomposing them into two or more applications.
      5. Ensure that the set of application definitions is internally consistent, by removing duplicate functionality as far as possible, and combining similar applications into one.
      6. Identify technology requirements and candidate technology building blocks, where this affects the applications design, including re-usable Solution Building Blocks from the Architecture Continuum, and external software packages.
      7. Identify any critical infrastructure dependencies (e.g., operating system and network services required).
      8. Identify any critical application dependencies, and minimize as far as possible.
      9. 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).
      10. Time permitting, draw simple diagrams to illustrate views of the Applications Architecture relevant to different stakeholders.
5. Conduct Formal Checkpoint Review of 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.

6. Review Qualitative Criteria (e.g., security, availability, performance, 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.

7. Complete Applications Architecture
   1. Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected from the Architecture Continuum.
   2. Fully document each Architecture Building Block.
   3. Final cross-check of overall architecture against business requirements. Document rationale for building block decisions in architecture document.
   4. Document final requirements traceability report.
   5. 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.
   6. Document rationale for building block decisions in architecture document.
   7. 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.
   8. 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:
      1. 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.

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

      3. Identify any constraints on the Technology Architecture about to be designed.
      4. Refine the proposed Applications Architecture only if necessary.
8. Perform Gap Analysis (see Approach) and Create Report
   1. Create gap matrix as described above.
   2. Identify building blocks to be carried over, classifying as either changed or unchanged.
   3. Identify eliminated building blocks.
   4. Identify new building blocks.
   5. 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)
• Baseline Applications Architecture, Version 1.0, if appropriate
• Validated application principles, or new application principles (if generated here)
• Target Applications 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, 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

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.
  
  

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.