ObjectiveObjective Approach Inputs Activities Outputs
ObjectiveThe 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 Technical Reference Model). 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 Technical Reference Model). 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 architectural 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 under Building Blocks and the ADM, and is illustrated in detail in the Building Blocks Example in Part IV.
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 reuse 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 provides insight into both application specific and more global considerations in defining building blocks in order to illustrate this.
The inputs to this step are:
Key activities in this step include:
The outputs of this step are:
Copyright © The Open Group, 1998, 1999, 2000, 2001