Purpose and Key Activities of the Preliminary Phase

Welcome back. In the previous lesson, you learned the shape of the Architecture Development Method (ADM): the Preliminary Phase prepares the way, Phases A through H address an architecture initiative through change, and Requirements Management continues throughout. This lesson looks closely at what “prepares the way” means.

The key distinction is between establishing the ability to do architecture work and developing an architecture for a particular change. By the end, you should be able to explain the Preliminary Phase’s purpose, describe its principal activities, and recognize when an activity belongs in Preliminary rather than Phase A.

Establish the ability to do architecture work

An organization could begin drawing a future-state architecture immediately. But without agreement on who can make architecture decisions, what rules guide those decisions, and how the work fits existing management processes, even a sound design may struggle to gain approval or be used consistently.

The Preliminary Phase addresses that underlying problem. Its purpose is to determine the architecture capability the organization needs and establish it. An architecture capability is the practical combination of people, responsibilities, processes, governance, methods, and tools that enables an organization to carry out enterprise architecture work over time. It is not the target Business, Data, Application, or Technology Architecture for one initiative.

Watch this overview before we unpack the activities. Concentrate on the two-part purpose and the six steps; treat predictions about particular exam questions as the presenter’s study advice, not as a guarantee about your exam.

Think of the two objectives as answers to different questions:

• Determine the desired capability: Where will enterprise architecture operate? What already exists? What level of architecture practice is useful and realistic?
• Establish the capability: Who will do the work and govern it? Which principles, tailored methods, processes, and tools will they use?

“Determine” matters because the organization should not assume that every architecture practice needs the same size team or degree of formality. “Establish” matters because an aspiration to “use TOGAF” does not, by itself, assign decision rights or make architecture work repeatable.

Determine the desired capability

Start with the organization’s context. Suppose a service organization has a contact center, field operations, and a digital team. It expects to undertake several changes involving all three. Before selecting a target system for any one change, it needs to decide whether architecture work will serve all three areas, how they will participate, and who will sponsor the capability.

That is scoping the enterprise organizations impacted by the architecture capability. It is broader than asking which application is in scope for the first initiative. Some units may do the core architecture work; others may supply expertise, approve decisions, or be affected by its results. Defining that boundary helps the organization assign responsibilities and avoid treating enterprise architecture as the concern of one isolated team.

The organization also needs to examine its existing arrangements. It may already have project approval processes, technology policies, security oversight, or established ways of managing change. Preliminary work confirms the governance and support frameworks that architecture must work with. The aim is not to duplicate every existing review, but to make clear how architecture decisions will fit alongside them.

Finally, the organization can assess its present architecture capability and the maturity it wants to reach. A small, newly formed practice might initially need clear responsibilities, a modest set of principles, and a place to retain its work. A more established practice might need stronger coordination across multiple architecture teams. A maturity assessment informs a realistic improvement plan; it is not a requirement to reach a particular score before architecture work can begin.

The following guide adds useful context to these choices. Its “Seven-Step Approach” is an explanatory way of discussing preparation; do not confuse its seven headings with the six principal ADM activities introduced in the video.

The guide’s examples illustrate possible organizational choices, not mandatory TOGAF designs. An enterprise might choose centralized data management, for instance, but the Preliminary Phase does not require every enterprise to adopt that specific principle.

Establish the capability

Once the organization understands its context and desired capability, it makes the working arrangements concrete. For Foundation study, keep the six principal activities together:

1. Scope the enterprise organizations impacted.
2. Confirm governance and support frameworks.
3. Define and establish the enterprise architecture team and organization.
4. Identify and establish Architecture Principles.
5. Tailor the TOGAF framework and other selected architecture frameworks.
6. Develop a strategy and implementation plans for tools and techniques.

The first two establish the boundary and surrounding rules. The remaining activities make architecture work operable within that boundary.

Define the team and organization. This means deciding who performs architecture work, who sponsors it, who participates from affected areas, and who has authority over architecture decisions. An organizational model can record responsibilities, reporting relationships, constraints, and the resources the capability needs. In our service-organization example, the digital team alone might not have authority to set rules affecting field operations. The Preliminary Phase is where that accountability problem should be recognized and addressed.

Establish Architecture Principles. These are durable guidelines for architecture decisions, grounded in the organization’s business direction. For example, a principle might require information shared across service teams to have clearly assigned ownership. The point is not to design a database now. It is to establish a rule that later designs can be assessed against. Principles should be stated clearly enough to guide a decision and understood in terms of their consequences; a later module will examine how to formulate them well.

Tailor the framework. TOGAF supplies a method and supporting guidance, but the organization must decide how to use them in its own setting. It may agree on terminology, modeling conventions, expected architecture outputs, review points, and relationships with existing project or delivery methods. Tailoring should make the method workable without discarding the architecture questions the organization still needs to answer. You will examine tailoring decisions in greater depth later in the course.

Plan the tools and techniques. People need a practical way to create, maintain, find, and reuse architecture work. That may involve selecting modeling tools and setting up an initial Architecture Repository for architecture assets. The concern is the capability those tools support, not a particular software product.

Governance runs through several of these activities. In Preliminary, the organization establishes how architecture will be governed: decision rights, oversight arrangements, and review processes. Later, when an initiative is being implemented, Phase G uses governance to oversee that implementation. Setting up the review process and conducting a review of a particular implementation are different activities.

What is ready when Preliminary work is done?

The phase’s results should make subsequent architecture work possible and accountable. Typical outputs include an organizational model for enterprise architecture, an Architecture Governance Framework, a tailored architecture framework, and an initial Architecture Repository. The organization may also restate the business principles, goals, and drivers that its architecture work must serve. If useful, a Request for Architecture Work can initiate a particular architecture cycle; it is not necessary to treat that request as a mandatory output of every Preliminary Phase effort.

These are not just documents to collect. In the service-organization example, the organizational model answers who can approve a cross-team architecture decision. The governance framework says how such a decision will be reviewed. The principles provide grounds for making it. The tailored method says what work and outputs are expected, while the repository makes earlier decisions available to the next initiative.

This also marks the boundary with the next phase. Preliminary prepares the organization to undertake architecture work; Phase A — Architecture Vision — sets direction for a particular architecture initiative. Preliminary may identify the broad business drivers and organizational boundaries relevant to the capability. Phase A then examines a specific proposed change, its stakeholders and scope, and the high-level vision for that work. Do not mistake “scope the organizations affected by the architecture capability” for “define the detailed scope of this initiative.”

Key takeaways

The Preliminary Phase has a two-part purpose: determine the architecture capability the organization wants, then establish that capability. Its principal activities cover organizational scope, existing governance and support frameworks, the architecture team, Architecture Principles, framework tailoring, and tools and techniques. Its outputs provide a workable foundation for architecture work—not a finished target architecture for a particular change.

Next, you will move into Phase A: Architecture Vision, where that prepared capability is used to establish direction and authorization for a specific architecture initiative.