3. Create an architectural model of building blocks

Objective    Approach     Inputs     Activities    Outputs

Objective

The reason for selecting viewpoints in the previous step is to be able to develop views for each of those viewpoints in this step. The architectural model created in this step comprises those several views.

The objective of this step is to broadly determine how the services required in the target system will be grouped after considering all pertinent viewpoints of the architecture's use. This differs from step 1 in that step 1 dealt mainly with the required functionality of the system, whereas here we are considering many viewpoints that are not expressed explicitly as required functionality.

The rationale behind this is to enable the services required within the system to be selected during the next step, through the creation of an architecture model that clearly depicts the required services.

Approach

At this step, the purpose of examining different viewpoints in step 2 becomes clear. The constraints defined and the unique system insights gained through an examination of the viewpoints pertinent to the current system and the target system can be used to validate the ability of the broad architectural model to accommodate the system requirements.

The broad architectural model starts as a TOGAF TRM-based model (or a model based upon the organization's Foundation Architecture), derived from the service to function mapping carried out as part of the service examination in step 1. An architecture based exactly on the TOGAF TRM may not be able to accommodate the stakeholder needs of all organizations. If the examination of different  viewpoints identifies architectural features that cannot be expressed in terms of the TOGAF TRM, changes and amendments to the TOGAF TRM should be made to create an organization-specific TRM.

Once the baseline description has been established and appropriate views described, it is possible to make decisions about how the various elements of system functionality should be implemented. This should only be in broad terms, to a level of detail which establishes how the major business functions will be implemented - for example as a transaction processing application or using a client/server model.

Therefore this step defines the future model of Building Blocks (e.g. collections of functions and services generated from previous steps). It is here that reuse of building blocks from your business' architecture continuum is examined carefully, assuring that maximum reuse of existing material is realized.

Once the architecture model of building blocks is created, the model must be tested for coverage and completeness of the required technical functions and services. For each building block decision, completely follow through its impact and note the rationale for decisions, including the rationale for decisions not to do something.

Inputs

The inputs to this step are:

• Business Architecture Version 2
• Technical Architecture Version 0.2
  • Technical Architecture - Target Architecture Viewpoints
  • Technical Architecture - Constraints
• Re-usable architecture building blocks (from organization's Architecture Continuum, if available)

Activities

Key activities in this step include:

1. For each viewpoint, create the model for the specific view required, using the selected tool.
2. Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models.
3. 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.
4. Validate that the models accommodate the constraints.
5. Note changes to the services viewpoint (the TRM model) and document.
6. Identify solution building blocks that would be used to implement the system, and create a model of building blocks.
7. Check building blocks against existing library of building blocks and re-use as appropriate.
8. Test architecture models for completeness against requirements.
9. Document rationale for building block decisions in architecture document.

Outputs

The outputs of this step are:

• Technical Architecture Version 0.3
• Technical Architecture Model
• Technical Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific architecture continuum.

Step 4: Select services portfolio per building block

Copyright © The Open Group, 1998, 2000, 2001