| You are here: | ||
| <<< Previous | Home | Next >>> |
This chapter defines the architecture scope, how to create the vision, and obtain approvals.
The objectives of Phase A are:
The phase 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 IV: Resource Base , 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 Scoping the Architecture .
The constraints will normally be informed by the business principles and architecture principles, developed as part of the Preliminary Phase (Preliminary Phase: Framework and Principles).
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 from scratch.
Similarly, the architecture principles that inform the constraints on architecture work will normally have been defined in the Preliminary Phase (Preliminary Phase: Framework and Principles). 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 from scratch, as explained in Part IV: Resource Base , Architecture Principles .
The Architecture Vision is essentially the architect's "elevator pitch" - the key opportunity to sell the benefits of the proposed development to the decision-makers within the enterprise. The goal is to articulate an Architecture Vision that enables the business goals, responds to the strategic drivers, conforms with the principles, and addresses the stakeholder concerns and objectives.
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 on the part
of the enterprise that lies within the scope of the current architecture Baseline Architecture project.
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 includes a first-cut, high-level description of the baseline ("as-is") and target ("to-be") environments, from both
a business and a technical perspective. These outline descriptions are then built on in subsequent phases.
Business scenarios are an appropriate and useful technique to discover and document business requirements, and to articulate an architectural vision that responds to those requirements. Business scenarios are described in Part IV: Resource Base , 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 IV: Resource Base , 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 inputs to Phase A are:
Key steps in Phase A include:
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 reference to the IT governance framework for the enterprise, explaining how this project relates to that framework.
Identify the business principles, business goals, 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 from scratch and secure their endorsement by corporate management.
Review the principles under which the current architecture Baseline Architecture is to be developed. Architecture principles are normally based on the business
principles developed as part of the Preliminary Phase. They are explained, and an example set given, in Part IV: Resource Base , 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 from scratch and secure their endorsement by corporate
management.
Define what is inside and what is outside the scope of the current architecture Baseline Architecture effort. The issues involved in this are discussed in Scoping the Architecture . In particular, define:
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.
Identify the key stakeholders and their concerns/objectives; define the key business requirements to be addressed in this architecture effort; and articulate an Architecture Vision that will address the requirements, within the defined scope and constraints, and conforming with the business and architecture principles.
Based on the purpose, focus, scope, and constraints, determine which architecture domains should be developed, to what level of detail, and which architecture views should be built. Estimate the resources needed, develop a roadmap and schedule for the proposed development, and document all these in the Statement of Architecture Work. Secure formal approval of the Statement of Architecture Work under the appropriate governance procedures.
A critical evaluation of the architectural starting point - the "as-is" baseline environment described in the Architecture Vision - may be a key element of such a statement of work,
especially for an incremental approach, where neither the architecture development nor the system implementation starts from
scratch.
The ADM has its own method (a "method-within-a-method") for identifying and articulating the business requirements implied in new business functionality to address key business drivers, and the implied Technology Architecture requirements. This process is known as business scenarios, and is described in detail in Part IV: Resource Base , Business Scenarios . The technique may be used iteratively, at different levels of detail in the hierarchical decomposition of the Business Architecture. The generic business scenario process is as follows:
Identify, document, and rank the problem that is driving the project.
Document, as high-level architecture models, the business and technical environment where the problem situation is occurring.
Identify and document desired objectives, the results of handling the problems successfully.
Identify human actors and their place in the business model, the human participants, and their roles.
Identify computer actors and their place in the technology model, the computing elements, and their roles.
Identify and document roles, responsibilities, and measures of success per actor, the required scripts per actor, and the desired results of handling the situation properly.
Check for fitness-for-purpose of inspiring subsequent architecture work, and refine only if necessary.
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 hardcopy book is also available from The Open Group Bookstore as document G063 .