Phase A: Architecture Vision

Objectives    Approach     Inputs     Steps    Outputs

Objectives

• To ensure that this evolution of the architecture development cycle has proper recognition and endorsement from the corporate management of the enterprise, and the support and commitment of the necessary line management.

• To validate the business principles, business goals, and strategic business drivers of the organization.

• To define the scope of, and to identify and prioritize the components of, the current architecture effort.

• To define the relevant stakeholders, and their concerns and objectives.

• To define the key business requirements to be addressed in this architecture effort, and the constraints that must be dealt with

• To articulate an architectural vision that demonstrates a response to those requirements and constraints.

• To secure formal approval to proceed.

• To understand the impact on, and of, other enterprise architecture development cycles going on in parallel.

Approach

General

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 under IT Governance in Part IV. 

This phase 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 under Scoping the Architecture Activity in the section Introduction to the ADM.

The constraints will normally be informed by the business principles and architecture principles, developed as part of the 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 this phase 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, Framework and Principles. The activity in this phase 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, Architectural Principles.

Creating the Architecture Vision

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 RoI 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 life-cycle within the enterprise. In such cases, the activity in this phase 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 of the part of the enterprise that lies within the scope of the current 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 (Phase A).

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 of TOGAF.

Once an Architectural 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, 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.

Inputs

The inputs to this phase are:

• Request for Architecture Work
• Business Strategy, Business Principles, Business Goals and Business Drivers (when pre-existing)
• Architecture Principles (when pre-existing)
• Enterprise Continuum - existing architectural documentation (framework description, architectural descriptions, existing baseline descriptions, etc.)

Steps

Key steps in this phase include:

1. Project Establishment: 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.
2. Business Principles,Business Goals and Business Drivers: Identify the business principles, 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 from scratch and secure their endorsement by corporate management.
3. Architecture Principles. Review the principles under which the current architecture is to be developed. Architecture Principles are normally based on the business principles developed as part of this Phase. They are explained, and an example set given, in Part IV, Architectural 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.
4. Scope: Define what is inside and what is outside the scope of the current architecture effort. The issues involved in this are discussed under Scope of the Architecting Activity in the section Introduction to the ADM. In particular, define:
   • the breadth of coverage of the enterprise
   • the level of detail to be defined
   • the specific architecture domains to be covered (Business, Data, Applications, Technology)
   • the extent of the time horizon aimed at, plus the number and extent of any intermediate time horizons
   • the architectural assets to be leveraged, or considered for use, from the organization's Enterprise Architecture Continuum
     • assets created in previous iterations of the ADM cycle within the enterprise
     • assets available elsewhere in the industry (other frameworks, systems models, vertical industry models, etc.)
5. Constraints: 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 Architectural Principles developed in the preliminary phase or clarified as part of this phase.
6. Stakeholders and concerns, Business Requirements, and Architecture Vision: 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 architectural principles.
   • 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 may also be used at more detailed levels of the architecture work (e.g. in Phase B, Business Architecture), and are described in Part IV of TOGAF.
   • If the Business Scenario technique is used, this step will generate the first, very high-level, definitions of the as-is (baseline) and to-be (target) environments, from both a business and technical perspective:
     • Business Baseline Architecture Version 1
     • Technical Baseline Architecture Version 1
     • Business Target Architecture Version 1
     • Technical Target Architecture Version 1
7. Statement of Architecture Work and Approval:  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" environment described in the Architecture Vision - may be a key element of such a SoW, especially for an incremental approach, where neither the the architecture development nor the system implementation starts from scratch.

Business Scenarios

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 technical architecture requirements. This process is known as Business Scenarios, and is described in detail in Part IV. 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:

1. Problem: Identify, document and rank the problem that is driving the project.
2. Business and technical environments: Document, as high-level architecture models, the business and technical environment where the problem situation is occurring.
3. Objectives and Measures of Success: Identify and document desired objectives, the results of handling the problems successfully.
4. Human Actors: Identify human actors and their place in business model, the human participants and their roles.
5. Computer Actors: Identify computer actors and their place in technology model, the computing elements and their roles.
6. Roles and Responsibilities: 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.
7. Refine: Check for fitness for purpose of inspiring subsequent architecture work, and refine only if necessary.

Outputs

The outputs of this phase are:

• Approved Statement of Architecture Work / Project Definition, including in particular:
  • Scope and constraints
  • Plan for the architectural work
• Refined statements of Business Principles, Business Goals and Strategic Drivers
• Architecture Principles (if not previously existing)
• Architecture Vision
• Business Scenario, including:
  • Business Baseline Version 1
  • Technical Baseline Version 1
  • Business Architecture Version 1
  • Technical Architecture Version 1

Note: Multiple Business Scenarios may be used to generate a single Architecture Vision. In TOGAF terms, the Architecture Vision may also be referred to as a 'conceptual level architecture'.

Copyright © The Open Group, 2002