| 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:
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 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, 18. Applying Iteration to the ADM .
All activities that have been initiated in these steps should be closed during the Finalize the Technology Architecture step
(see 11.3.8 Finalize the Technology Architecture). The documentation generated from these steps must
be formally published in the Create the Architecture Definition Document step (see 11.3.9 Create the
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, 20. Architecture Principles .
Select relevant Technology Architecture resources (reference models, patterns, etc.) from the Architecture Repository (see Part V, 37. 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 technology service. The areas where the Technology Architecture may be impacted will include the following:
Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
So high communication availability is an important consideration during service decomposition and defining service granularity
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., technology 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 managing the 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, 30. 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, 30. 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 16.5.2 Requirements Development).
The services portfolios are combinations of basic services from the service categories in the defined taxonomy 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 the TOGAF standard, 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 11.5 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, 30. Content Metamodel).
Begin by converting the description of the existing environment into the terms of the organization's taxonomy of technology services and technology components (e.g., the TOGAF TRM). This will allow the team developing the architecture to gain experience and understanding of the taxonomy. 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, 37. 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, 33.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, 23. Gap Analysis .
Following the 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:
The evolution of new technologies is a major driver for change in enterprises looking for new innovative ways of operating and improving their business. The Technology Architecture needs to capture the transformation opportunities available to the enterprise through the adoption of new technology.
While the Enterprise Architecture is led by the business concerns, drivers for change are often found within evolving technology capabilities. As more digital innovations reach the market, stakeholders need to both anticipate and be open to technology-driven change. Part of Digital Transformation has arisen due to the convergence of telecommunications and computer capabilities which have opened up new ways of implementing infrastructures.
Solution development methods are also evolving to challenge traditional development methods and putting pressure on the shared
services and common use benefits of the traditional Enterprise Architecture approach. Yet without a strong Enterprise Architecture
approach, the rapid adoption of changing technologies will cause discontinuities across the enterprise.
The flexibility of the TOGAF ADM enables technology change to become a driver and strategic resource rather than a recipient of Change Requests. As a result, the Technology Architecture may both drive business capabilities and respond to information system requirements at the same time.
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, 37. Architecture Repository ).
In particular:
return to top of page