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.

6.1 Objectives

The objectives of Phase A are to:

• Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture
• Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision

6.2 Inputs

This section defines the inputs to Phase A.

6.2.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 32.2.5 Architecture Repository)

6.2.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 32.2.17 Request for Architecture Work)
• Business principles, business goals, and business drivers (see Part IV, 32.2.9 Business Principles, Business Goals, and Business Drivers)

6.2.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 32.2.16 Organizational Model for Enterprise Architecture), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Re-use requirements
  • Budget requirements
  • Requests for change
  • Governance and support strategy
• Tailored Architecture Framework (see Part IV, 32.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Architecture Principles (see Part IV, 32.2.4 Architecture Principles), including business principles, when pre-existing
  • Configured and deployed tools
• Populated Architecture Repository (see Part IV, 32.2.5 Architecture Repository) - existing architectural documentation (framework description, architectural descriptions, baseline descriptions, ABBs, etc.)

6.3 Steps

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 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:

• 6.3.1 Establish the Architecture Project
• 6.3.2 Identify Stakeholders, Concerns, and Business Requirements
• 6.3.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints
• 6.3.4 Evaluate Capabilities
• 6.3.5 Assess Readiness for Business Transformation
• 6.3.6 Define Scope
• 6.3.7 Confirm and Elaborate Architecture Principles, including Business Principles
• 6.3.8 Develop Architecture Vision
• 6.3.9 Define the Target Architecture Value Propositions and KPIs
• 6.3.10 Identify the Business Transformation Risks and Mitigation Activities
• 6.3.11 Develop Statement of Architecture Work; Secure Approval

6.3.1 Establish the Architecture Project

Enterprise Architecture is a business capability; each cycle of the ADM should normally be handled as a project using 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 procedures to secure 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.

6.3.2 Identify Stakeholders, Concerns, and Business Requirements

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:

• To identify candidate vision components and requirements to be tested as the Architecture Vision is developed
• To identify candidate scope boundaries for the engagement to limit the extent of architectural investigation required
• To identify stakeholder concerns, issues, and cultural factors that will shape how the architecture is presented and communicated

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, 21.3 Steps in the Stakeholder Management Process and 21.4 Template Stakeholder Map). The stakeholder map is used to support various outputs of the Architecture Vision phase, and to identify:

• The concerns and viewpoints that are relevant to this project; this is captured in the Architecture Vision (see Part IV, 32.2.8 Architecture Vision)
• The stakeholders that are involved with the project and as a result form the starting point for a Communications Plan (see Part IV, 32.2.12 Communications Plan)
• The key roles and responsibilities within the project, which should be included within the Statement of Architecture Work (see Part VI, 32.2.20 Statement of Architecture Work)

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, 21. Stakeholder Management , understanding at this stage which stakeholders and which views need to be developed is important in setting the scope of the engagement.

During the Architecture Vision phase, new requirements generated for future architecture work within the scope of the selected requirements need to be documented within the Architecture Requirements Specification, and new requirements which are beyond the scope of the selected requirements must be input to the Requirements Repository for management through the Requirements Management process.

6.3.3 Confirm and Elaborate Business Goals, Business Drivers, and Constraints

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.

6.3.4 Evaluate Capabilities

It is valuable to understand a collection of capabilities within the enterprise. One part refers to the capability of the enterprise to develop and consume the architecture. The second part refers to the baseline and target capability level of the enterprise. Gaps identified in the Architecture Capability require iteration between Architecture Vision and Preliminary Phase to ensure that the Architecture Capability is suitable to address the scope of the architecture project (see Part III, 18. Applying Iteration to the ADM).

A key step following from evaluation of business models, or artifacts that clarify priorities of a business strategy, is to identify the required business capabilities the enterprise must possess to act on the strategic priorities.

The detailed assessment of business capability gaps belongs in Phase B as a core aspect of the Business Architecture, where the architect can help the enterprise understand gaps throughout the business, of many types, that need to be addressed in later phases of the architecture.

In the Architecture Vision phase, however, the architect should consider the capability of the enterprise to develop the Enterprise Architecture itself, as required in the specific initiative or project underway. Gaps in the ability to progress through the ADM, whether deriving from skill shortages, information required, process weakness, or systems and tools, are a serious consideration in the vision of whether the architecture effort should continue. The architect can find guidance in 6.5 Approach to gather existing business capability frameworks for the enterprise in this early assessment.

Gaps, or limitations, identified in the enterprise's capability to execute on change will inform the architect on the description of the Target Architecture and on the Implementation and Migration Plan (see Part IV, 32.2.14 Implementation and Migration Plan) created in Phase E and Phase F. This step seeks to understand the capabilities and desires of the enterprise at an appropriate level of abstraction (see 19. Applying the ADM Across the Architecture Landscape). Consideration of the gap between the baseline and target capability of the enterprise is critical. 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. The results of the assessment are documented in a Capability Assessment (see (see Part IV, 32.2.10 Capability Assessment).

6.3.5 Assess Readiness for Business Transformation

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 26. Business Transformation Readiness Assessment .

The results of the readiness assessment should be added to the Capability Assessment (see Part IV, 32.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.

6.3.6 Define Scope

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 4.5 Scoping the Architecture . In particular, define:

• The breadth of coverage of the enterprise
• The level of detail required
• The partitioning characteristics of the architecture (see Part V, 36. Architecture Partitioning for more details)
• The specific architecture domains to be covered (business, data, application, technology)
• The extent of the time period aimed at, plus the number and extent of any intermediate time period
• 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.)

6.3.7 Confirm and Elaborate Architecture Principles, including Business Principles

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, 20. 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.

6.3.8 Develop Architecture Vision

An understanding of the required artifacts will enable the stakeholders to start to scope out their decision-making which will guide subsequent phases. These decisions need to be reflected in the stakeholder map.

Policy development and strategic decisions need to be captured in this phase to enable the subsequent work to be quantified; for example, rationalization decisions and metrics, revenue generation, and targets which meet the business strategy. There are also other areas which need to be addressed; for example, Digital Transformation and IT strategy where decisions on the Architecture Vision will provide leadership and direction for the organization in subsequent phases.

For the Architecture Vision it is recommended that first an overall architecture be decided upon showing how all of the various architecture domain deliverables will fit together (based upon the selected course of action).

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 the TOGAF® Series Guide: 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 6.4 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.

6.3.9 Define the Target Architecture Value Propositions and KPIs

• Develop the business case for the architectures and changes required
• Produce the value proposition for each of the stakeholder groupings
• Assess and define the procurement requirements
• Review and agree the value propositions with the sponsors and stakeholders concerned
• Define the performance metrics and measures to be built into the Enterprise Architecture to meet the business needs
• Assess the business risk (see Part III, 27. Risk Management )

The outputs from this activity should be incorporated within the Statement of Architecture Work to allow performance to be tracked accordingly.

6.3.10 Identify the Business Transformation Risks and Mitigation Activities

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, 27. Risk Management .

There are two levels of risk that should be considered, namely:

• Initial Level of Risk: risk categorization prior to determining and implementing mitigating actions
• Residual Level of Risk: risk categorization after implementation of mitigating actions (if any)

Risk mitigation activities should be considered for inclusion within the Statement of Architecture Work.

6.3.11 Develop Statement of Architecture Work; Secure Approval

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:

• Performance metrics are built into the work products
• Specific performance-related work products are available

Then, activities will include:

• Identify new work products that will need to be changed
• Provide direction on which existing work products, including building blocks, will need to be changed and ensure that all activities and dependencies on these are co-ordinated
• Identify the impact of change on other work products and dependence on their activities
• 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
• Assess the resource requirements and availability to perform the work in the timescale required; this will include adhering to the organization's planning methods and work products to produce the plans for performing a cycle of the ADM
• Estimate the resources needed, develop a roadmap and schedule for the proposed development, and document all these in the Statement of Architecture Work
• Define the performance metrics to be met during this cycle of the ADM by the Enterprise Architecture team
• Develop the specific Enterprise Architecture Communications Plan and show where, how, and when the Enterprise Architects will communicate with the stakeholders, including affinity groupings and communities, about the progress of the Enterprise Architecture developments
• Review and agree the plans with the sponsors, and secure formal approval of the Statement of Architecture Work under the appropriate governance procedures
• Gain sponsor's sign-off to proceed

6.4 Outputs

The outputs of Phase A may include, but are not restricted to:

• Approved Statement of Architecture Work (see Part IV, 32.2.20 Statement of Architecture Work), including in particular:
  • Architecture project description and scope
  • Overview of Architecture Vision
  • Architecture project plan and schedule
• Refined statements of business principles, business goals, and business drivers (see Part IV, 32.2.9 Business Principles, Business Goals, and Business Drivers)
• Architecture Principles (see Part IV, 20. Architecture Principles)
• Capability Assessment (see Part IV, 32.2.10 Capability Assessment)
• Tailored Architecture Framework (see Part IV, 32.2.21 Tailored Architecture Framework) (for the engagement), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Architecture Vision (see Part IV, 32.2.8 Architecture Vision), including:
  • Problem description
  • Objective of the Statement of Architecture Work
  • Summary views
  • Business Scenario (optional)
  • Refined key high-level stakeholder requirements
• Draft Architecture Definition Document, including (when in scope):
  • Baseline Business Architecture, Version 0.1
  • Baseline Technology Architecture, Version 0.1
  • Baseline Data Architecture, Version 0.1
  • Baseline Application Architecture, Version 0.1
  • Target Business Architecture, Version 0.1
  • Target Technology Architecture, Version 0.1
  • Target Data Architecture, Version 0.1
  • Target Application Architecture, Version 0.1
• Communications Plan (see Part IV, 32.2.12 Communications Plan)
• Additional content populating the Architecture Repository (see Part IV, 32.2.5 Architecture Repository)

Note:

Multiple business scenarios may be used to generate a single Architecture Vision.

The outputs may include some or all of the following:

• Matrices:
  • Stakeholder Map matrix
• Diagrams:
  • Business Model diagram
  • Business Capability Map
  • Value Stream Map
  • Value Chain diagram
  • Solution Concept diagram

6.5 Approach

6.5.1 General

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 VI, 44.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 4.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 5. 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 5. Preliminary Phase). The activity in Phase A is concerned with ensuring that the existing principle 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, 20. Architecture Principles .

6.5.2 Creating the Architecture Vision

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.

Integral to the Architecture Vision is an understanding of emerging technologies and their potential impact on industries and enterprises, without which many business opportunities may be missed.

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.

Business models are key strategy artifacts that can provide such a perspective, by showing how the organization intends to deliver value to its customers and stakeholders. 6.3.4 Evaluate Capabilities introduces the application of business models as a step in developing the Architecture Vision.

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).

This exercise should examine and search for existing materials on fundamental Business Architecture concepts such as:

• Business Capabilities, which represent a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome

  In this phase, the architect should determine whether a framework exists in the organization to represent business capabilities. If one does not exist, the architect should consider whether developing a framework is within the scope of the project. For an introduction to business capabilities, see The Open Group Guide to Business Capabilities.

• Value Streams, which represent an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user

  For an introduction to value streams, see the TOGAF® Series Guide: Value Streams.

• Organization Maps, which depict the relationships between the primary entities that make up the enterprise, its partners, and stakeholders

  As traditional organizational charts often lack the necessary detail to reflect the full scope of the enterprise's activities, the architect can help identify and understand the complex web of relationships between business entities as well as where business capabilities are used and connection to value stream stages. These are refined and extended in subsequent phases.

In addition, the Architecture Vision explores other domains which are appropriate for the Enterprise Architecture in hand. These domains may include elements of the basic domains, yet serve an additional purpose for the stakeholders. Example domains may include:

• Information
• Security
• Digital
• Network Management
• Knowledge
• Industry-specific
• Services
• Partnership
• Cybersecurity

These domains may be free-standing or linked with other domains to provide enterprise-wide views of the organization vision and structure.

The Architecture Vision phase includes the conduct of a business assessment (using, for example, business scenarios) where critical factors are documented and various courses of action are assessed. High-level advantages and disadvantages, including risks and opportunities, are documented and the best course of action selected to serve as the basis for the Architecture Vision.

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.

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 VI, 44.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.
return to top of page