Step 7 is to complete the architecture definition.
GRAPHIC HERE
The objective of this step is to fully specify the Technology Architecture. This is a complex and iterative process in which the selection of building blocks and interfaces has a big impact on how the original requirements are met. The figure above shows this as two boxes, captioned as Steps 7a and 7b, but in reality the process is more complicated. See Book 3: Building Blocks for further details.
Completion of the architecture definition may be achieved in two steps, by defining an intermediate Transitional Architecture in addition to the final Target Architecture, if complexity of migration requires it.
The specification of building blocks as a portfolio of services is an evolutionary process:
The earliest building block definitions start as relatively abstract ones, defined by standards and services that map most easily to the architectural framework. These building blocks are most probably Architecture Building Blocks.
At this stage a model and a portfolio of services have been established. The next step is to select the set of specifications that provide the services and that can be combined as required to create the building blocks.
During this final step in the development of building blocks it must be verified that the organization-specific requirements will be met. The development process must include recognition of dependencies and boundaries for functions and should take account of what products are available in the marketplace. There are Architecture Building Blocks and related Solution Building Blocks.
An example of how this might be expressed can be seen in the building blocks example (Book 3: Building Blocks). Building blocks can be defined at a number of levels matching the degree of integration that best defines the architecture of the system at any stage.
Fundamental functionality and attributes - semantic, unambiguous including security capability and manageability
Interfaces - chosen set, supplied (APIs, data formats, protocols, hardware interfaces, standards)
Dependent building blocks with required functionality and named used interfaces
Map to business/organizational entities and policies
Finally the building blocks become more implementation-specific as Solution Building Blocks and their interfaces become the detailed architecture specification. SBBs are a means to determine how portions of the Target Architecture might be procured, developed, or re-used. The SBBs architecture should have separate elements for developed, re-used, and procured building blocks, each described in terms of their minimum specification.
A full list of standards and specifications recommended by The Open Group can be found in Book 3: Standards Information Base.
The inputs to Step 7 are:
Business Architecture V2
Technology Architecture V0.6
Re-usable Architecture Building Blocks, from organization's Architecture Continuum, if available (see Re-Usable Architecture Building Blocks)
Standards Information Base (SIB) (see Book 3:, Standards Information Base)
Key activities in Step 7 include:
Ensure clear documentation of all interfaces for each building block (APIs, data formats, protocols, hardware interfaces).
Select standards for each of the Architecture Building Blocks, re-using as much as possible from the reference models selected from the Architecture Continuum.
Fully document each architecture building block.
Final cross-check of overall architecture against business requirements. Document rationale for building block decisions in the architecture document.
Document final requirements traceability reports.
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.
Document rationale for building block decisions in the architecture document.
Generate the Technology Architecture document.
Prepare the Technology Architecture Report. If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the Technology Architecture document for review by relevant stakeholders, and incorporate feedback.
Checkpoint/Impact Analysis: Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture. Conduct an Impact Analysis, to:
Identify any areas where the Business Architecture (e.g., business practices) may need to change to cater for changes in the Technology Architecture. If the impact is significant, this may warrant the Business Architecture being revisited.
Identify any areas where the Data Architecture may need to change to cater for changes in the Technology Architecture. If the impact is significant, this may warrant the Data Architecture being revisited.
Identify any areas where the Applications Architecture may need to change to cater for changes in the Technology Architecture. If the impact is significant, this may warrant the Applications Architecture being revisited.
Refine the proposed Technology Architecture only if necessary.
The outputs of Step 7 are:
Technology Architecture V0.7
Technology Architecture - architecture specification
Technology Architecture - requirements traceability
Technology Architecture - mapping of the architectures in the Architecture Continuum
Technology Architecture Report