7. Complete the architecture definition
Objective Approach Inputs
Activities Outputs
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. Figure
2 shows this as two boxes, captioned as steps 7a and 7b, but in reality the process is
more complicated. See Part IV, Building Block Example,
for further details.
Completion of the architecture definition may be achieved in two steps, by defining an
intermediate Transition 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 architectural 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 architectural and related solution
oriented building blocks.
- An example of how this might be expressed can be seen in the Building Blocks Example in Part IV. 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 BBs 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. Solution
Building Blocks are a means to determining how portions of the target architecture might
be procured, developed, or reused. The Solution Building Blocks architecture should have
separate elements for developed, reused 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 Part III, Standards Information Base.
The inputs to this step are:
Key activities in this step 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, reusing 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 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 reused, and publish
via the architecture repository.
- Document rationale for building block decisions in architecture document.
- Generate the Technology Architecture document.
- Prepare 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 this step are:
- Technology Architecture Version 0.7
- Technology Architecture - Architecture Specification
- Technology Architecture - Requirements Traceability
- Technology Architecture - Mapping of the architectures in the architecture continuum.
- Technology Architecture Report
Step 8: Conduct gap analysis
Copyright © The Open Group, 1998, 1999, 2000, 2001, 2002