| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes the development of a Technology Architecture for an architecture project.
The objectives of Phase D are to:
As part of Phase D, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Repository (see Part V, 41. Architecture Repository).
In particular:
For example, the TeleManagement Forum (TMF) - www.tmforum.org - has developed detailed technology models relevant to the Telecommunications industry.
For example, The Open Group has a Reference Model for Integrated Information Infrastructure (III-RM) - see Part VI, 44. Integrated Information Infrastructure Reference Model - that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure.
This section defines the inputs to Phase D.
The level of detail addressed in Phase D will depend on the scope and goals of the overall architecture effort.
New technology building blocks being introduced as part of this effort will need to be defined in detail during Phase D. Existing technology building blocks to be supported in the target environment may need to be redefined in Phase D to ensure interoperability and fit-for-purpose within this specific Technology Architecture.
The order of the steps in Phase D (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance. In particular, determine whether in this situation it is appropriate to conduct Baseline Description or Target Architecture development first, as described in Part III, 19. Applying Iteration to the ADM.
All activities that have been initiated in these steps must be closed during the Finalize the Technology Architecture step (see 12.4.8 Finalize the Technology Architecture). The documentation generated from these steps must be formally published in the Create Architecture Definition Document step (see 12.4.9 Create Architecture Definition Document).
The steps in Phase D are as follows:
Review and validate the set of technology principles. These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of technology principles, are given in Part III, 23. Architecture Principles.
Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository (see Part V, 41. Architecture Repository), on the basis of the business drivers, stakeholders, and their concerns.
Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture.
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 required, these may comprise simple documents and spreadsheets, or more sophisticated modeling tools and techniques.
For each viewpoint, select the models needed to support the specific view required, using the selected tool or method. Ensure that all stakeholder concerns are covered. If they are not, create new models to address them, or augment existing models (see above).
The process to develop a Technology Architecture incorporates the following steps:
In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the platform service. The areas where the Technology Architecture may be impacted will include the following:
Product selection processes may occur within the Technology Architecture phase where existing products are re-used, incremental capacity is being added, or product selection decisions are a constraint during project initiation.
Where product selection deviates from existing standards, involves significant effort, or has wide-ranging impact, this activity should be flagged as an opportunity and addressed through the Opportunities & Solutions phase.
Catalogs are inventories of the core assets of the business. Catalogs are hierarchical in nature and capture a decomposition of a metamodel entity and also decompositions across related model entities (e.g., platform service -> logical technology component ->] physical technology component).
Catalogs form the raw material for development of matrices and diagrams and also act as a key resource for portfolio managing business and IT capability.
The Technology Architecture should create technology catalogs as follows:
The following catalogs should be considered for development within a Technology Architecture:
The structure of catalogs is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.
Matrices show the core relationships between related model entities.
Matrices form the raw material for development of diagrams and also act as a key resource for impact assessment.
The following matrix should be considered for development within a Technology Architecture:
Diagrams present the Technology Architecture information from a set of different perspectives (viewpoints) according to the requirements of the stakeholders.
This activity provides a link between platform requirements and hosting requirements, as a single application may need to be physically located in several environments to support local access, development lifecycles, and hosting requirements.
For major baseline applications or application platforms (where multiple applications are hosted on the same infrastructure stack), produce a stack diagram showing how hardware, operating system, software infrastructure, and packaged applications combine.
If appropriate, extend the Application Architecture diagrams of software distribution to show how applications map onto the technology platform.
For each environment, produce a logical diagram of hardware and software infrastructure showing the contents of the environment and logical communications between components. Where available, collect capacity information on the deployed infrastructure.
For each environment, produce a physical diagram of communications infrastructure, such as routers, switches, firewalls, and network links. Where available, collect capacity information on the communications infrastructure.
The following diagrams should be considered for development within a Technology Architecture:
The structure of diagrams is based on the attributes of metamodel entities, as defined in Part IV, 34. Content Metamodel.
Once the Technology Architecture catalogs, matrices, and diagrams have been developed, architecture modeling is completed by formalizing the technology-focused requirements for implementing the Target Architecture.
These requirements may:
Within this step, the architect should identify requirements that should be met by the architecture (see 17.2.2 Requirements Development).
The services portfolios are combinations of basic services from the service categories in the TOGAF TRM that do not conflict. The combination of services are again tested to ensure support for the applications. This is a prerequisite to the later step of defining the architecture fully.
The previously identified requirements can provide more detailed information about:
Where requirements demand definition of specialized services that are not identified in TOGAF, consideration should be given to how these might be replaced if standardized services become available in the future.
For each building block, build up a service description portfolio as a set of non-conflicting services. The set of services must be tested to ensure that the functionality provided meets application requirements.
Develop a Baseline Description of the existing Technology Architecture, to support the Target Technology Architecture. The scope and level of detail to be defined will depend on the extent to which existing technology components are likely to be carried over into the Target Technology Architecture, and on whether architectural descriptions exist, as described in 12.2 Approach.
Identify the relevant Technology Architecture building blocks, drawing on any artifacts held in the Architecture Repository. If nothing exists within the Architecture Repository, define each application in line with the Technology Portfolio catalog (see Part IV, 34. Content Metamodel).
Begin by converting the description of the existing environment into the terms of the organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). This will allow the team developing the architecture to gain experience with the model and to understand its component parts. The team may be able to take advantage of a previous architectural definition, but it is assumed that some adaptation may be required to match the architectural definition techniques described as part of this process. Another important task is to set down a list of key questions which can be used later in the development process to measure the effectiveness of the new architecture.
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Baseline Architecture.
Develop a Target Description for the Technology Architecture, to the extent necessary to support the Architecture Vision, Target Business Architecture, and Target Information Systems Architecture. The scope and level of detail to be defined will depend on the relevance of the technology elements to attaining the Target Architecture, and on whether architectural descriptions exist. To the extent possible, identify the relevant Technology Architecture building blocks, drawing on the Architecture Repository (see Part V, 41. Architecture Repository).
A key process in the creation of a broad architectural model of the target system is the conceptualization of building blocks. Architecture Building Blocks (ABBs) describe the functionality and how they may be implemented without the detail introduced by configuration or detailed design. The method of defining building blocks, along with some general guidelines for their use in creating an architectural model, is described in Part IV, 37.3 Building Blocks and the ADM.
Where new architecture models need to be developed to satisfy stakeholder concerns, use the models identified within Step 1 as a guideline for creating new architecture content to describe the Target Architecture.
Verify the architecture models for internal consistency and accuracy:
Identify gaps between the baseline and target, using the Gap Analysis technique as described in Part III, 27. Gap Analysis.
Following creation of a Baseline Architecture, Target Architecture, and gap analysis, a Technology Roadmap is required to prioritize activities over the coming phases.
This initial Technology Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.
Once the Technology Architecture is finalized, it is necessary to understand any wider impacts or implications.
At this stage, other architecture artifacts in the Architecture Landscape should be examined to identify:
Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Technology Architecture, asking if it is fit for the purpose of supporting subsequent work in the other architecture domains. Refine the proposed Technology Architecture only if necessary.
Document the rationale for building block decisions in the Architecture Definition Document.
Prepare the technology sections of the Architecture Definition Document, comprising some or all of:
If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.
The outputs of Phase D may include, but are not restricted to:
The outputs may include some or all of the following:
Choosing the scope of an architecture development cycle carefully will accelerate the pay-back. In contrast, an excessively large scope is unlikely to lead to successful implementation.
return to top of page
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of TOGAF®, an Open Group Standard, are available under license from the TOGAF information web site. The license is free to any organization wishing to use the TOGAF standard entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G116.