Phase A: Architecture Vision — Purpose and Principal Activities

Welcome back. The Preliminary Phase established the organization’s ability to do architecture work: its people, principles, governance, and tailored method. Phase A: Architecture Vision puts that capability to work on a particular proposed change.

Phase A has two closely related purposes: develop a high-level vision of the capabilities and business value the change could deliver, and obtain approval for the architecture work needed to investigate and develop that vision. In this lesson, you will follow a proposed initiative from an initial request to an agreed scope, a credible vision, and authorization to proceed. The distinction matters for Foundation study: Phase A sets direction; it does not finish the target architecture.

From a request to a shared understanding

Imagine a service organization whose customers sometimes have to explain the same issue again when moving between its contact center, digital channel, and field teams. A sponsor asks for “a better customer service system.” That request signals a problem, but it does not yet define a sound architecture initiative. Is the main concern repeated work, slow resolution, inconsistent information, or all three? Which teams are affected? What improvement would justify the effort?

Phase A begins by establishing the business context behind the request. Architects identify the drivers for change, confirm the relevant business goals and principles, and clarify constraints such as available funding, existing commitments, or architecture decisions that already apply. They also identify stakeholders and learn their concerns: the matters each stakeholder needs the architecture to address. A service manager may care about resolution time; a field team may care about receiving accurate case details; an information-governance lead may care about appropriate access to customer information.

Watch the first part of Introduction to TOGAF ADM: Phase A Architecture Vision from VisualParadigm. It shows how stakeholder discovery, business goals, and communication fit into setting expectations for the initiative.

Identifying stakeholders is more than compiling names. Their concerns help reveal high-level requirements and expose competing priorities early enough to shape the initiative. Phase A can record who needs to be consulted, who makes decisions, and how each group will receive information. A stakeholder map and a communications plan are useful results of this work; later lessons will examine stakeholder analysis in more detail.

Notice, too, the connection to Preliminary without treating the phases as duplicates. Preliminary may have established organization-wide Architecture Principles and an architecture governance process. Phase A reviews and applies that foundation to this initiative, confirming which goals, principles, and constraints matter here. If the proposed change conflicts with an existing architecture decision, discovering that now is preferable to discovering it after detailed design.

Set boundaries before drawing the future

Once the problem is clearer, architects define the scope of the architecture work. For our example, a useful scope might include how the contact center, digital channel, and field teams handle a customer case from first contact to resolution. It might exclude unrelated product development. The scope should also say which architecture domains require attention, how much detail is needed at this stage, and what time horizon the work addresses.

This is different from the organizational scope discussed in Preliminary. Preliminary asked, in effect, where must the enterprise architecture capability operate? Phase A asks, what will this particular architecture engagement address? A prepared architecture team may serve an entire enterprise while a given Phase A initiative covers only a few related functions.

Scope is a decision informed by evidence, not merely a boundary drawn around the sponsor’s first suggestion. If a handoff problem crosses three teams, restricting the work to a contact-center application could prevent the architecture from addressing its cause. Conversely, expanding the initiative to redesign every customer-facing function could make it too large to approve or complete. Phase A seeks a defensible boundary that matches the business problem and the decisions the architecture must support.

A short practitioner-oriented account reinforces this point. Read the indicated portions of Conexiam’s TOGAF ADM Phase A – Start at the Beginning with an Architecture Vision for its framing of Phase A as a way to clarify the problem and earn permission to continue.

The article calls the vision a potential answer to the problem. Keep the word potential in mind: Phase A should give stakeholders enough direction to judge whether further work is worthwhile, while leaving detailed investigation to subsequent phases.

Develop a credible, high-level vision

The Architecture Vision describes a plausible future direction and why it matters. In the service example, the vision might propose an organizational capability to manage a customer case consistently across channels, so that the next team can see the information it needs without asking the customer to start again. It could describe the present difficulty, the desired improvement, the affected business functions, and the expected value.

At this point, it would be premature to specify every application, data structure, or technology product. Those decisions require further architecture work. A good vision is nevertheless more substantial than “improve service”: it connects a proposed change to recognizable business outcomes. For example, the initiative might aim to reduce repeated requests for information and shorten the time needed to resolve cases. Proposed measures give stakeholders a way to test whether the anticipated value is meaningful.

Architects also consider whether the direction is feasible enough to investigate. They may examine relevant existing capabilities and architecture assets, identify capabilities that need strengthening, consider the organization’s readiness for change, and note significant risks and assumptions. A vision dependent on coordinated work across three teams should acknowledge that coordination, rather than presenting the change as a simple software replacement. An initial business case can bring together expected benefits, broad costs or effort, and major uncertainties.

Continue the VisualParadigm video for the move from business capabilities and a proposed vision to a defined architecture engagement.

There are two different uses of capability here. Preliminary established the enterprise architecture capability—the people and arrangements needed to carry out architecture work. Phase A may assess business capabilities relevant to the proposed change—for instance, the ability to track and resolve a customer case across teams. Keeping those meanings separate prevents confusion between preparing an architecture practice and describing what the enterprise needs to be able to do.

The vision may include an outline of the current situation and a high-level candidate target. Subsequent Business, Data, Application, and Technology Architecture work tests and develops that candidate. Agreement on the Architecture Vision is not approval of a finished solution.

Secure agreement on the work to be done

A promising vision still leaves a practical question: What architecture work is being commissioned? Phase A answers it in the Statement of Architecture Work. This sets out the engagement’s scope, objectives, approach, constraints, expected outputs, and arrangements for carrying out the work. The organization seeks approval of this statement so that the architecture team has an agreed mandate to proceed.

Three items are easy to confuse:

• A Request for Architecture Work expresses the need that initiates an architecture engagement. “Investigate repeated customer-service handoffs” could be such a request.
• The Architecture Vision communicates a high-level candidate direction and the value it is expected to provide.
• The Statement of Architecture Work defines and, when approved, authorizes the architecture development work that will examine and elaborate that direction.

These items answer different questions: Why are we being asked to act? What direction seems worth pursuing? What work have we agreed to do? Phase A can also produce or update supporting material such as a stakeholder map, communications plan, initial requirements, risk information, and business case. Their purpose is to make the decision to proceed informed and accountable, not to generate paperwork for its own sake.

For Foundation questions, look for the level of commitment implied by an activity. In Phase A, stakeholders can endorse a vision and approve the architecture engagement. They are not yet signing off every detailed design choice or the final implementation plan. If the proposed value is insufficient, the scope cannot be agreed, or a major constraint makes the direction untenable, Phase A can also expose that problem before more work is commissioned.

Key takeaways

Phase A turns a proposed change into an agreed architecture initiative. Its principal activities are to clarify the business problem and drivers; identify stakeholders, concerns, and high-level requirements; confirm relevant principles and constraints; define scope; develop a high-level, value-focused Architecture Vision; consider capabilities, readiness, risks, and the initial business case; and obtain approval for the Statement of Architecture Work.

The boundary is worth remembering: Preliminary establishes the ability to do architecture work; Phase A agrees the direction and mandate for this initiative; later phases develop the architecture in depth. Next, you will look at Requirements Management, which keeps requirements visible and controlled as that work continues across the ADM.