| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter describes the initial phase of the Architecture Development Method (ADM). It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
The objectives of Phase A are:
Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization to the architecture organization.
The issues involved in ensuring proper recognition and endorsement from corporate management, and the support and commitment of line management, are discussed in Part VII, 50.1.4 IT Governance .
Phase A also defines what is in and what is outside the scope of the architecture effort and the constraints that must be dealt with. Scoping decisions need to be made on the basis of a practical assessment of resource and competence availability, and the value that can realistically be expected to accrue to the enterprise from the chosen scope of architecture work. The issues involved in this are discussed in 5.5 Scoping the Architecture . Scoping issues addressed in the Architecture Vision phase will be restricted to the specific objectives for this ADM cycle and will be constrained within the overall scope definition for architecture activity as established within the Preliminary phase and embodied within the architecture framework.
In situations where the architecture framework in place is not appropriate to achieve the desired Architecture Vision, revisit the Preliminary phase and extend the overall architecture framework for the enterprise.
The constraints will normally be informed by the business principles and architecture principles, developed as part of the Preliminary phase (see 6. Preliminary Phase).
Normally, the business principles, business goals, and strategic drivers of the organization are already defined elsewhere in the enterprise. If so, the activity in Phase A is involved with ensuring that existing definitions are current, and clarifying any areas of ambiguity. Otherwise, it involves defining these essential items for the first time.
Similarly, the architecture principles that form part of the constraints on architecture work will normally have been defined in the Preliminary phase (see 6. Preliminary Phase). The activity in Phase A is concerned with ensuring that the existing principles definitions are current, and clarifying any areas of ambiguity. Otherwise, it entails defining the architecture principles for the first time, as explained in Part III, 23. Architecture Principles .
The Architecture Vision provides the sponsor with a key tool to sell the benefits of the proposed capability to stakeholders and decision-makers within the enterprise. Architecture Vision describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.
Clarifying and agreeing the purpose of the architecture effort is one of the key parts of this activity, and the purpose needs to be clearly reflected in the vision that is created. Architecture projects are often undertaken with a specific purpose in mind - a specific set of business drivers that represent the return on investment for the stakeholders in the architecture development. Clarifying that purpose, and demonstrating how it will be achieved by the proposed architecture development, is the whole point of the Architecture Vision.
Normally, key elements of the Architecture Vision - such as the enterprise mission, vision, strategy, and goals - have been documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise. In such cases, the activity in Phase A is concerned with verifying and understanding the documented business strategy and goals, and possibly bridging between the enterprise strategy and goals on the one hand, and the strategy and goals implicit within the current architecture reality.
In other cases, little or no Business Architecture work may have been done to date. In such cases, there will be a need for the architecture team to research, verify, and gain buy-in to the key business objectives and processes that the architecture is to support. This may be done as a free-standing exercise, either preceding architecture development, or as part of the ADM initiation phase (Preliminary phase).
The Architecture Vision provides a first-cut, high-level description of the Baseline and Target Architectures, covering the business, data, application, and technology domains. These outline descriptions are developed in subsequent phases.
Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios are described in Part III, 26. Business Scenarios .
Once an Architecture Vision is defined and documented in the Statement of Architecture Work, it is critical to use it to build a consensus, as described in Part VII, 50.1.4 IT Governance . Without this consensus it is very unlikely that the final architecture will be accepted by the organization as a whole. The consensus is represented by the sponsoring organization signing the Statement of Architecture Work.
The ADM has its own method (a "method-within-a-method") for identifying and articulating the business requirements implied in new business capability to address key business drivers, and the implied architecture requirements. This process is known as "business scenarios", and is described in Part III, 26. Business Scenarios . The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture.
This section defines the inputs to Phase A.
The level of detail addressed in Phase A will depend on the scope and goals of the Request for Architecture Work, or the subset of scope and goals associated with this iteration of architecture development.
The order of the steps in Phase A (see below) 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.
The steps in Phase A are as follows:
Execution of ADM cycles should be conducted within the project management framework of the enterprise. In some cases, architecture projects will be stand-alone. In other cases, architectural activities will be a subset of the activities within a larger project. In either case, architecture activity should be planned and managed using accepted practices for the enterprise.
Conduct the necessary (enterprise-specific) procedures to secure enterprise-wide recognition of the project, the endorsement of corporate management, and the support and commitment of the necessary line management. Include references to other management frameworks in use within the enterprise, explaining how this project relates to those frameworks.
Identify the key stakeholders and their concerns/objectives, and define the key business requirements to be addressed in the architecture engagement. Stakeholder engagement at this stage is intended to accomplish three objectives:
The major product resulting from this step is a stakeholder map for the engagement, showing which stakeholders are involved with the engagement, their level of involvement, and their key concerns (see Part III, 24.3 Steps in the Stakeholder Management Process and 24.4 Template Stakeholder Map). The stakeholder map is used to support various outputs of the Architecture Vision phase, and to identify:
Another key task will be to consider which architecture views and viewpoints need to be developed to satisfy the various stakeholder requirements. As described in Part III, 24. Stakeholder Management , understanding at this stage which stakeholders and which views need to be developed is important in setting the scope of the engagement.
Identify the business goals and strategic drivers of the organization.
If these have already been defined elsewhere within the enterprise, ensure that the existing definitions are current, and clarify any areas of ambiguity. Otherwise, go back to the originators of the Statement of Architecture Work and work with them to define these essential items and secure their endorsement by corporate management.
Define the constraints that must be dealt with, including enterprise-wide constraints and project-specific constraints (time, schedule, resources, etc.). The enterprise-wide constraints may be informed by the business and architecture principles developed in the Preliminary phase or clarified as part of Phase A.
A business capability assessment is used to define what capabilities an organization will need to fulfil its business goals and business drivers.
A business capability can be thought of as a synonym for a macro-level business function.
This step first seeks to understand the capabilities and desires of the business, then identifies options to realize those capabilities. For example, an organization may possess a finance capability and have a desire to reduce the cost of operating this capability. A suitable technique for reducing cost may be to adopt an outsourced service from a service provider. This would require the business to accept the functional limits of the packaged software, and adapt to these constraints. The business is constrained in its ability to differentiate itself in the marketplace in this functional area, should custom software be needed to support unique operations and business practices. Therefore, it is necessary for the organization to understand where it needs to differentiate itself and where a model of sufficiency at lowest cost is preferred.
Once the current and desired business capabilities are understood, their likely implications for the organization's technology capability can be assessed, creating an initial picture of new IT capability that will be required to support the Target Architecture Vision.
Showing the baseline and target capabilities within the context of the overall enterprise can be supported by creating Value Chain diagrams that show the linkage of related capabilities at the macro level, either within an individual enterprise, or across a network of related enterprises.
The results of the assessment are documented in a Capability Assessment (see Part IV, 36.2.10 Capability Assessment).
A Business Transformation Readiness Assessment can be used to evaluate and quantify the organization's readiness to undergo a change. This assessment is based upon the determination and analysis/rating of a series of readiness factors, as described in 30. Business Transformation Readiness Assessment .
The results of the readiness assessment should be added to the Capability Assessment (see Part IV, 36.2.10 Capability Assessment). These results are then used to shape the scope of the architecture, to identify activities required within the architecture project, and to identify risk areas to be addressed.
Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts, understanding that the baseline and target need not be described at the same level of detail. In many cases, the Baseline is described at a higher level of abstraction, so more time is available to specify the Target in sufficient detail. The issues involved in this are discussed in 5.5 Scoping the Architecture . In particular, define:
Review the principles under which the architecture is to be developed. Architecture principles are normally based on the principles developed as part of the Preliminary phase. They are explained, and an example set given, in Part III, 23. Architecture Principles . Ensure that the existing definitions are current, and clarify any areas of ambiguity. Otherwise, go back to the body responsible for architecture governance and work with them to define these essential items for the first time and secure their endorsement by corporate management.
Based on the stakeholder concerns, business capability requirements, scope, constraints, and principles, create a high-level view of the Baseline and Target Architectures. The Architecture Vision typically covers the breadth of scope identified for the project, at a high level. Informal techniques are often employed. A common practice is to draw a simple solution concept diagram that illustrates concisely the major components of the solution and how the solution will result in benefit for the enterprise.
Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an Architecture Vision that responds to those requirements. Business scenarios may also be used at more detailed levels of the architecture work (e.g., in Phase B) and are described in Part III, 26. Business Scenarios .
This step generates the first, very high-level definitions of the baseline and target environments, from a business, information systems, and technology perspective, as described in 7.5 Outputs .
These initial versions of the architecture should be stored in the Architecture Repository, organized according to the standards and guidelines established in the architecture framework.
The outputs from this activity should be incorporated within the Statement of Architecture Work to allow performance to be tracked accordingly.
Identify the risks associated with the Architecture Vision and assess the initial level of risk (e.g., catastrophic, critical, marginal, or negligible) and the potential frequency associated with it. Assign a mitigation strategy for each risk. A risk management framework is described in Part III, 31. Risk Management .
There are two levels of risk that should be considered, namely:
Risk mitigation activities should be considered for inclusion within the Statement of Architecture Work.
Assess the work products that are required to be produced (and by when) against the set of business performance requirements. This will involve ensuring that:
Then, activities will include:
The outputs of Phase A are:
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 book is also available (in hardcopy and pdf) from The Open Group Bookstore as document G091.