Step 1 is to create a Baseline Description in the TOGAF format.
GRAPHIC HERE
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-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 Book 3: 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 Book 3: 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:
Technology Principles, if existing (see Architecture Principles)
Request for Architecture Work (see Request for Architecture Work)
Statement of Architecture Work (see Statement of Architecture Work)
Architecture Vision (see Architecture Vision)
Relevant Technical Requirements from previous phases (see Technical Requirements)
Gap Analysis (from Data Architecture) (see Gap Analysis)
Gap Analysis (from Applications Architecture)
Baseline Business Architecture V2 (detailed), if appropriate
Data Architecture Baseline Description, if appropriate
Applications Architecture Baseline Description, if appropriate
Business Architecture V2 (detailed)
Re-usable Architecture Building Blocks from organization's Enterprise Continuum (see Re-Usable Architecture Building Blocks)
Target Data Architecture
Target Applications Architecture
Re-usable Architecture Building Blocks from organization's Architecture Continuum, if available
Re-usable Solution Building Blocks, from organization's Solutions Continuum, if available
Key activities in Step 1 include:
Collect data on current system
Document all constraints
Review and validate (or generate, if necessary) 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 Architecture principles, are given in Book 3: Architecture Principles.
List distinct functionality
Produce affinity groupings of functionality using TOGAF TRM service groupings (or your business' Foundation Architecture)
Analyze relationships between groupings
Sanity check functionality to assure all of current system is considered
Identify interfaces
Produce Technology Architecture model
Verify Technology Architecture model
Document key questions to test merits of Technology Architecture
Document criteria for selection of service portfolio architecture
The outputs of Step 1 are:
Technology Principles, if not existing (see Architecture Principles)
Technology Architecture V0.1:
Technology Architecture - Constraints
Technology Architecture - Architecture Principles
Technology Architecture - Requirements traceability, key questions list
Technology Architecture - Requirements traceability, criteria for selection of service portfolio
Technology Architecture Model V0.1