The purpose of Phase A-A is to develop an Architecture Vision.
The objectives of Phase A-A are:
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 ongoing in parallel
Phase A-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 Book 3: IT Governance.
Phase A-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-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 Arinciples 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-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 Book 3: 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-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 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 Architecture Vision that responds to those requirements. Business Scenarios are described in Book 3: 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 Book 3: 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.
INSERT NEW GRAPHIC HERE
The process steps for Phase A-A are:
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.
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.
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 the Preliminary Phase. They are explained, and an example set given, in Book 3: 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.
Scope: Define what is inside and what is outside the scope of the current architecture effort. The issues involved in this are discussed in Scoping the Architecture. 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 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.)
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 Architecture Principles developed in the Preliminary Phase or clarified as part of Phase A-A.
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 Architecture Principles.
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 A-B, and are described in Book 3: Business Scenarios.
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:
Baseline Business Architecture V1
Baseline Technology Architecture V1
Target Business Architecture V1
Target Technology Architecture V1
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 Statement of Architecture Work, especially for an incremental approach, where neither the architecture development nor the system implementation starts from scratch.
Add vision process steps model here - new material.