This chapter describes the development of a Technology Architecture.
The detailed description of the process to develop the Target Technology Architecture is given in Target Technology Architecture - Detail .
The objective of Phase D is to develop a Technology Architecture that will form the basis of the following implementation work.
Detailed guidelines for Phase D, including Inputs, Steps, and Outputs, are given in Target Technology Architecture - Detail .
As part of Phase D, the architecture team will need to consider what relevant Technology Architecture resources are available in the Architecture Continuum.
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 Integrated Information Infrastructure Reference Model) that focuses on the application-level components and underlying services necessary to provide an integrated information infrastructure.
Inputs to Phase D are:
Key steps in Phase D include:
Detailed activities for this step, including Inputs, Activities, and Outputs, are given in Target Technology Architecture - Detail .
The outputs of Phase D are:
This is the detailed description of the process to develop the Target Technology Architecture.
An organization creating or adapting a Technology Architecture may already mandate the use of a list of approved
suppliers/products for that organization. The list will be an input to the definition of the organization-specific architecture
framework. The architectures can then be used as procurement tools to govern the future growth and development of the
organization's IT infrastructure. The key steps are expanded in the following subsections.
Step 1 is to create a Baseline Description in the TOGAF format.
The objective of this step is to convert the description of the existing system into services terminology using the organization's Foundation Architecture (e.g., the TOGAF Foundation Architecture's TRM). The rationale behind this is to structure the existing system description in a way which makes it compatible with the breakdown of standards and the descriptions used within your Foundation Architecture.
This step is intended to facilitate moving from product documentation to a service-oriented description. The step will aid in specifying standards for the Target Architecture in Step 4. An additional step, Step 3, oriented to defining building blocks, provides the means to cross-check the architectural definition process in the form of implementation-related decisions.
Additionally, this step captures relevant parts of the existing architecture (using the scope definition established in Phase A) as candidates for re-usable building blocks, along with inhibitors to meeting business requirements using the existing system. The existing architecture is assessed against the Business Architecture, identifying the key inhibitors and opportunities for re-use. Finally, the existing architecture assessment ends with the capture of implied or explicit architecture principles that should be carried forward and imposed on this architecture exercise.
Begin by converting the description of the existing environment into the terms of your 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.
A key process in the creation of a broad architectural model of the target system is the conceptualization of Architecture Building Blocks (ABBs). ABBs are not intended to be solutions, but depictions of how the architecture might be looked on in implementable terms. Their functionality is clearly defined, but without the detail introduced by specific products. The method of defining ABBs, along with some general guidelines for their use in creating an architectural model, is described in Part IV: Resource Base, Building Blocks and the ADM , and illustrated in detail in Building Blocks .
It is recommended that Architecture Building Blocks be documented (e.g., with an architecture description language) and stored (e.g., in a repository or information base), in order to maximize re-use potential.
Applying the ABB method introduces application space into the architectural process. This is the means of linking services, which address functionality that must be considered on an enterprise basis, with applications, which may or may not address global functionality. The building blocks example in Part IV: Resource Base, Building Blocks , provides insight into both application-specific and more global considerations in defining building blocks in order to illustrate this.
The inputs to Step 1 are:
Key activities in Step 1 include:
These will normally form part of an overarching set of architecture principles. Guidelines for developing and applying principles, and a sample set of Technology Architecture principles, are given in Part IV: Resource Base, Architecture Principles .
The outputs of Step 1 are:
Step 2 is to consider different architecture reference models, viewpoints, and tools.
The objective of this step is to perform an analysis of the Technology Architecture from a number of different concerns (requirements) or viewpoints and to document each relevant viewpoint. The purpose of considering these viewpoints is to ensure that all relevant stakeholder concerns will have been considered in the final Technology Architecture, so ensuring that the target system will meet all the requirements put on it.
The Business Architecture is used to select the most relevant viewpoints for the project. It is important to recognize that in practice it will be rarely possible to reach 100% coverage of stakeholder concerns.
Pertinent viewpoints are created first from the existing system to identify the salient elements of the current systems requirements that the stakeholders confirm must also be satisfied in the target system. A comprehensive set of stakeholder viewpoints must also be created for the target system. The corresponding views of the existing system will be compared with the views of the target system to identify elements of the existing system that are intended for replacement or improvement.
If a set of viewpoints is carefully chosen, it will expose the most important aspects of the existing architecture and the requirements of the target system.
Several different viewpoints may be useful. Architecture viewpoints and views are described in greater detail in Part IV: Resource Base, Developing Architecture Views . The viewpoints presented there should not be considered an exhaustive set, but simply a starting point. In developing a Technology Architecture, it is very likely that some of the viewpoints given there will not be useful, while others not given there will be essential. Again, use the Business Architecture as a guide in selecting the pertinent viewpoints.
The inputs to Step 2 are:
Key activities in Step 2 include:
The outputs of Step 2 are:
Step 3 is to create an architectural model of building blocks.
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:
Key activities in Step 3 include:
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).
The outputs of Step 3 are:
Step 4 is to select the services portfolio required per building block.
The objective of this step is to select services portfolios for each building block generated in Step 3.
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 pre-requisite to the later step of defining the architecture fully.
The constraints output from Step 2 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 Architecture Building Block (ABB), 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.
The inputs to Step 4 are:
Key activities in Step 4 include:
The outputs of Step 4 are:
Step 5 is to confirm that the business goals and objectives are met.
The objective of this step is to clarify and check the business goals and other objectives of implementing the architecture. This is required as a cross-check that the Technology Architecture meets these objectives.
The key question list is used to pose questions against the architecture model and service description portfolio to test its merit and completeness.
The inputs to Step 5 are:
Key activities in Step 5 include:
The outputs of Step 5 are:
Step 6 is to determine criteria for specification selection.
The objective of this step is to develop a set of criteria for choosing specifications and portfolios of specifications.
Choosing the right criteria is vital if the final architecture is to meet its objectives. These criteria will depend on the existing system and the overall objectives for the new architecture. The overall objectives should be developed from the organization's business goals, so it is hard to give specific advice here, but some example objectives are listed in Part IV: Resource Base, Business Scenarios .
Here are some example criteria, selected by a large government organization with the intention of building a stable and widely applicable architecture:
"A standard or specification:
- Must meet the organization's requirements
- Must meet legal requirements
- Should be a publicly available specification
- Should have been developed by a process which sought a high level of consensus from a wide variety of sources
- Should be supported by a range of readily available products
- Should be complete
- Should be well understood, mature technology
- Should be testable, so that components or products can be checked for conformance
- Should support internationalization
- Should have no serious implications for ongoing support of legacy systems
- Should be stable
- Should be in wide use
- Should have few, if any problems or limitations"
A high level of consensus is often considered the most important factor by large organizations because standards and specifications chosen have to accommodate a wide range of user needs. For example, in determining the level of consensus for standards in their architecture, the Application Portability Profile (APP), the US National Institute for Standards and Technology (NIST) prefers to use international standards for the basis of specifications. The process through which these international standards have evolved requires a very high level of consensus. A number of US Federal Information Processing Standards (FIPS) specified in the APP are based on approved international standards. The use of international standards has significant benefits for any organization which works or trades with organizations in other countries.
The inputs to Step 6 are:
Key activities in Step 6 include:
The outputs of Step 6 are:
Step 7 is to complete the architecture definition.
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. See Part IV: Resource Base, 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:
A full list of standards and specifications recommended by The Open Group can be found in Part III: Enterprise Continuum, Foundation Architecture: Standards Information Base .
The inputs to Step 7 are:
Key activities in Step 7 include:
If the impact is significant, this may warrant the Business Architecture being revisited.
If the impact is significant, this may warrant the Data Architecture being revisited.
If the impact is significant, this may warrant the Applications Architecture being revisited.
The outputs of Step 7 are:
Step 8 is to conduct a gap analysis.
The objective of this step is to identify areas of the current and target system for which provision has not been made in the Technology Architecture. This is required in order to identify projects to be undertaken as part of the implementation of the target system.
A key step in validating an architecture is to consider what may have been forgotten. The architecture must support all of the essential information processing needs of the organization, as driven by the required applications. The most critical source of gaps that should be considered is stakeholder concerns that have not been addressed in subsequent architectural work.
Gap analysis highlights services and/or functions that have been accidentally left out, deliberately eliminated, or are yet to be developed or procured:
When the exercise is complete, anything under "Eliminated Services" or "New Services" is a gap, which should either be explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the function.
Gap Analysis Matrix shows an example from the Network Services category when functions from the Baseline Architecture are missing from the Target Architecture.
The inputs to Step 8 are:
Key activities in Step 8 include:
The output of Step 8 is:
The Technology Architecture development process described above includes iterations. Financial and timing constraints should explicitly limit the number of iterations within Steps 1 through 8, and drive to implementation. After that, a new cycle of architecture evolution may ensue.
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.
"How do you eat an elephant? - One bite at a time."
return to top of page
The TOGAF document set is designed for use with frames. To navigate around the document:
Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.