Step 3 is to create an architectural model of building blocks.
GRAPHIC HERE
The reason for selecting viewpoints in Step 2 is to be able to develop views for each of those viewpoints in Step 3. The architectural model created in Step 3 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.
At Step 3, 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 re-use of building blocks from your business' Architecture Continuum is examined carefully, assuring that maximum re-use 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.
The inputs to Step 3 are:
Business Architecture V2
Technology Architecture V0.2
Technology Architecture - viewpoints
Technology Architecture - constraints
Re-usable Architecture Building Blocks, from organization's Architecture Continuum, if available (see Re-Usable Architecture Building Blocks)
Key activities in Step 3 include:
To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Continuum.
For each viewpoint, create the model for the specific view required, using the selected tool or method. Consider developing at least the following views:
Networked Computing/Hardware view
Communications view
Processing view
Cost view
Standards view
Assure that all stakeholder concerns are covered. If they are not, create new models to address concerns not covered, or augment existing models.
Ensure that all information requirements in the Business Architecture, Data Architecture, and Applications Architecture are met.
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).
Validate that the models support the principles, objectives, and constraints.
Note changes to the viewpoint represented in the selected models from the Architecture Continuum, and document.
Identify Solution Building Blocks that would be used to implement the system, and create a model of building blocks.
Check building blocks against the existing library of building blocks and re-use as appropriate.
Test architecture models for completeness against requirements.
Document rationale for building block decisions in the architecture document.
The outputs of Step 3 are:
Technology Architecture V0.3
Technology Architecture Model
Networked Computing/Hardware view
Communications view
Processing view
Cost view
Standards view
Technology Architecture - change requests and/or extensions or amendments to be incorporated in an organization-specific Architecture Continuum