IT solutions analysis

The Open Group Architecture Framework (TOGAF) is an integrated set of solutions and tools that support the development of corporate architecture.
Supports four sectors of the architecture:

1. Business Architecture – defines the business strategy, supervision methods, organizational model and main business processes.
2. Data Architecture – describes the physical and logical structure of data stored and processed by the organization.
3. Applications Architecture – provides a road map of IT systems, their interactions and connections to main business processes.
4. Technology Architecture – which describes the infrastructure in terms of software and hardware to support IT services and other processes.

TOGAF ADM (Architecture Development Method) conceptualizes the architecture development process in a few phases and each of them analyses a selected aspect of the whole issue. Below you will find a description of the TOGAF phases. The depicted approach is characteristic for SOA oriented solutions.

Diagram that illustrates the ADM cycle (courtesy of The Open Group)

A TOGAF scoping diagram

This phase focuses on the vision, scope, business drivers and readiness assessment. A document describing the vision of architecture is created, and its role is to list the formally agreed project expected results and architectural solutions.
The description of strategic architecture is of key importance for phase A. It includes a formal description that creates an organizational framework for operational activities, transformations and provides a long term perspective and to define goals at the management level. It also allows defining separate segments in SOA, before their architecture is decided and described.

Beginning from phase A, for the next three phases the meta model is constantly actualized. Also the documentation is expanded and updated.

The elements of the business domain are:

• a description of business architecture and processes,
• the model and description of sample business uses,
• the specification of the realisation of business use,
• business objects model,
• business rules definitions.

It is assumed that between phase A and phase B, as part of the architecture solutions management process, a proper specification document for architecture requirements is created (Architecture Requirements Specification). This document provides a quantitative representation of the expected results and measurement criteria for the implementation of the new architecture. This specification is constantly updated and expanded up to phase F.

A recommended content of a specification document for architecture requirements include:

• success measures,
• architecture requirements,
• business service contracts,
• application service contracts,
• implementation guidelines,
• implementation specifications,
• implementation standards,
• interoperability requirements,
• IT service management requirements,
• constraints,
• assumptions.

An Architecture Definition Document is a complementary document for the Architecture Requirements Specification. It is a container for artefacts that appear during the process of creation of the new architecture. It provides a qualitative status of the results and depicts the intentions of the architects.

During phase D implementation models are created, with a goal to describe the base technical architecture from the logical point of view and to create the target technical architecture in whole service context. The compliance with the SOA Reference Architecture and the SOA Reference Model is checked.
Also in phase D the application components map defined during the design phase is translated into a set of technical components, which will become the elements of the final product.

During the phase E new possibilities and key solutions are identified, as well as the means to implement them in the organization (as intermediate architectures), with a goal to obtain the final desirable architecture. Intermediate architectures are a base for the migration roadman.
In this phase the implementation planning begins, then necessary tools are identified for a give architecture. The expected outcome of this phase is a complete set of documentation (roadmaps, solution matrixes and diagrams) that describe the chosen solutions, integration and management patterns, as well as both internal and external service providers.

This stage aims to create in cooperation with the client a detailed architecture implementation roadmap. It is in same time the verification phase of the model, before the implementation takes place. The main target is to prioritize the projects and estimate their correlations, costs and benefits of distinct migration projects. A prioritized project list is a base for the migration roadmap.

This phase focuses on the creation of principles of managing the implementation of the system. The implementation process is monitored to assure the best quality possible and compliance with the architecture overall. The implementation process should be adherent to the managing models and strategies of SOA and TOGAF, which were defined in previous phases. When all tasks are completed, a post-implementation review is performed. During this stage a revision of two documents can be necessary: Architecture Definition Document and the Architecture Requirements Specification. After the review, the project is closed.