Preliminary Phase and the enterprise boundary

The Preliminary Phase is often taught as "setup work" or "housekeeping." That description is dangerously weak. In practice, the Preliminary Phase determines whether the architecture effort will start with a controlled enterprise definition or with a vague brief that expands every week until no one can agree what is in scope.

Think of it this way. If you were building a house, you would not start pouring concrete before deciding where the property boundary sits, which local planning rules apply, and who has the authority to approve the design. The Preliminary Phase does the same job for enterprise architecture. It answers the questions that must be settled before anyone starts drawing target-state diagrams.

At this point the team is not trying to solve the full architecture. It is deciding where the architecture authority begins, which actors and obligations materially shape the work, and what sort of capability has to exist for the work to remain governable. That is why boundary work belongs here. If the team cannot say what enterprise it is working within, every later discussion about baseline, target, or requirements will be unstable.

TOGAF C220 Part 2 sets out a series of objectives for the Preliminary Phase. Each one addresses a specific risk that will undermine the ADM cycle if it is left unresolved. Here is the complete set, with a plain-language explanation of what each objective is really asking the team to do.

1. Determine the enterprise organisations impacted. Before any architecture work begins, the team must identify which parts of the organisation (and which external bodies) will be affected by the architecture effort. This is not a quick org-chart exercise. It means understanding which business units, subsidiaries, regulators, partners, and operational bodies have a material stake in the outcome.

2. Confirm governance and support frameworks. Architecture work needs a governance path. Without one, architecture conclusions become advisory opinions that delivery teams can ignore. This objective asks the team to confirm how architecture decisions will be reviewed, approved, and enforced. It also means identifying what existing governance structures (such as programme boards or risk committees) the architecture effort needs to connect with.

3. Define and establish the architecture team and organisation. Who will do the work? What roles are needed? Where does the architecture team sit in relation to delivery, strategy, and operations? This objective forces the organisation to stand up an actual team with named roles rather than assuming that architecture will happen as a side activity.

4. Identify and establish architecture principles. Architecture principles are the rules that will govern trade-off decisions throughout the ADM cycle. This objective asks the team to define them early so that later design choices have a consistent basis. You will study principles in depth in Module 10.

5. Tailor the TOGAF framework and, if any, other selected architecture frameworks. No organisation should adopt TOGAF as a rigid recipe. This objective asks the team to decide which parts of TOGAF they will use, how they will adapt the ADM phases, what notations they will employ, and how TOGAF will integrate with other frameworks the organisation already uses (such as ITIL for service management or SABSA for security architecture).

6. Implement architecture tools. Architecture work produces models, diagrams, repositories, and evidence trails. This objective asks the team to decide what tooling will support that work. Tooling might be as simple as a shared document repository or as sophisticated as a dedicated architecture modelling platform.

The common thread across all six objectives is readiness. The Preliminary Phase is the organisation's answer to the question: "Are we actually ready to begin a disciplined architecture cycle, or are we just about to produce diagrams without a foundation?"

Tailoring is one of the most misunderstood parts of TOGAF. Many teams treat the framework as an all-or-nothing prescription: either you follow every phase, every deliverable, and every technique exactly as written, or you abandon the framework entirely. Neither approach is correct.

TOGAF is designed to be adapted. The standard itself says so. Tailoring means looking at the full set of ADM phases, techniques, and artefacts and making conscious decisions about which ones you will use, which ones you will modify, and which ones you will defer. The key word is "conscious." Tailoring is not the same as ignoring. When a team skips a phase without recording why, that is not tailoring. That is uncontrolled omission.

Good tailoring decisions consider several factors:

• Organisational maturity. A team doing architecture for the first time will need a simpler process than a team with ten years of architecture practice. The depth and formality of each phase should match the organisation's ability to use the outputs.
• Existing frameworks. If the organisation already uses ITIL, SABSA, or another framework, the tailored ADM should explain how TOGAF integrates with those practices rather than competing with them.
• Scope and complexity. A small architecture effort covering one business unit might use a lightweight version of the ADM. An enterprise-wide transformation across multiple regulated domains will need more ceremony.
• Regulatory context. In regulated industries, certain artefacts and governance steps may be non-negotiable because they produce evidence that the regulator expects to see.

The Preliminary Phase is where tailoring decisions are recorded. The output should be a clear statement of how the organisation has adapted TOGAF, what it has kept, what it has changed, and why. That statement becomes a reference point for every later phase.

The word "enterprise" in enterprise architecture does not automatically mean the whole company. TOGAF uses the term to describe the scope of the architecture effort: the set of actors, obligations, interfaces, and decision rights that materially shape the work. That scope could be a single business unit, a programme that spans several departments, or the entire organisation including its external partners.

Getting the enterprise scope right is one of the most important decisions the team makes in the Preliminary Phase. If the scope is too narrow, the architecture will miss dependencies that later break the design. If the scope is too wide, the team will spread its effort so thin that nothing reaches decision-grade depth.

The enterprise scope is defined by asking a series of practical questions:

• Which internal functions are materially affected by the change?
• Which external actors constrain architecture choices through regulation, system operation, licences, data obligations, or delivery dependence?
• What decisions must this first architecture cycle support, and who is entitled to accept or reject those decisions?
• Which obligations are current and non-negotiable, and which ambitions belong to later cycles?

The answers to those questions produce the enterprise boundary for the architecture effort. That boundary is not a fixed property of the organisation. It is a design decision that reflects the specific architecture work being undertaken.

Most architecture scope arguments stem from conflating four distinct boundaries. Getting them straight early prevents weeks of circular debate later. Let us walk through each one carefully, because the distinctions matter enormously in practice.

Enterprise boundary. The set of actors, obligations, interfaces, and decision rights that materially shape the architecture effort. This is wider than any single org chart and narrower than "everything the company touches." The enterprise boundary is an architecture concept. It is defined by what shapes design and governance decisions, not by reporting lines. An external regulator that constrains your data model sits inside the enterprise boundary even though it sits outside your company.

Organisational boundary. The internal reporting structure, legal entities, or operating units visible on the organisation chart. This is the boundary most people think of first, and it is almost never the right one for architecture work. The org chart shows who reports to whom. It does not show which external forces shape your architecture choices.

Programme boundary. The funded change initiative, its formal remit, and the pieces of work leadership has chosen to control together. A programme boundary is a management construct, not an architecture construct. The programme may fund part of the architecture work, but the architecture may need to consider actors and dependencies that sit outside the programme's funding envelope.

Solution boundary. The specific system, platform, data product, or delivery package that a solution team will eventually implement. This is the narrowest boundary and the one that delivery teams default to. A solution architect working on one application may care about its APIs and data feeds. An enterprise architect needs to understand how that application fits into the broader enterprise context.

The practical danger is that teams pick the wrong boundary and treat it as the architecture boundary. If you use the programme boundary, you will miss dependencies that sit outside the programme's funding. If you use the organisational boundary, you will miss regulated interfaces. If you use the solution boundary, you will lose the enterprise perspective entirely.

In a regulated enterprise the effective boundary is rarely identical to the internal company perimeter. The architecture may have to answer to regulators, system operators, code bodies, assurance schemes, and public reporting duties that sit outside internal management lines.

Consider an electricity distributor. The company has an org chart with departments for planning, operations, customer services, and technology. But the architecture also has to account for Ofgem (the energy regulator), the National Energy System Operator (NESO), the Energy Networks Association (which maintains industry codes), and public data-publication expectations. Those bodies are not on the org chart, but they directly shape data models, process designs, evidence requirements, and compliance obligations.

The disciplined move is to treat those interfaces as part of the architecture context and, where they shape design and governance decisions directly, part of the effective enterprise boundary for the work. Ignoring them does not make them go away. It simply means the architecture will be forced to accommodate them later, at higher cost and with less coherence.

This principle applies beyond energy. In financial services, the regulator's reporting requirements shape data architecture. In healthcare, patient safety standards shape every application design. In transport, safety certification bodies constrain technology choices. In every regulated sector, the effective enterprise boundary extends beyond the company perimeter.

The Preliminary Phase hands off to Phase A: Architecture Vision. Before that handoff happens, the team should be able to answer the following questions clearly:

1. Enterprise boundary. Which internal functions are materially affected by the change, and which are only interested observers? Which external actors constrain architecture choices?
2. Governance and capability. Who sponsors the architecture work? How will architecture decisions be reviewed and enforced? What roles exist and where does the team sit?
3. Principles. What rules will govern design trade-offs? Are those rules specific enough to change real decisions?
4. Tailoring. How has the organisation adapted TOGAF? What has been kept, modified, or deferred, and why?
5. Tooling and repository. Where will architecture evidence live? Who is responsible for maintaining it?

If any of those questions cannot be answered clearly, the Preliminary Phase is not complete. The team may feel pressure to move on, but starting Phase A with unresolved foundation questions is the fastest route to the kind of scope arguments that opened this module.

From the three primer modules you already know that London Grid Distribution is a fictional but realistic electricity distributor operating across London. It faces the same pressures as real DNOs: connections reform, net zero transition, ageing infrastructure, and increasing regulatory expectations for data quality and transparency.

The question for the Preliminary Phase is: what does "the enterprise" mean for London Grid's first architecture cycle? The answer is not "the whole company." Nor is it "the IT department." The enterprise boundary must be defined by what materially shapes the architecture decisions the team is about to make.

Inside the effective enterprise boundary:

• Internal functions: Planning, connections, operations, digital and data services, cyber security, telecoms, regulatory affairs, and data-governance functions. These departments directly produce, consume, or govern the data and processes the architecture must address.
• Ofgem obligations: The energy regulator sets performance standards, reporting requirements, and data-publication expectations that directly constrain London Grid's data architecture and process design. Ofgem is not on London Grid's org chart, but its requirements shape almost every design decision.
• NESO planning interfaces: The National Energy System Operator coordinates planning data that London Grid both consumes and publishes. The interface specifications, data formats, and timing requirements are architecture constraints, not optional extras.
• Public data-publication expectations: London Grid publishes network data to developers, generators, and the general public. The quality and consistency of that publication is both a regulatory requirement and a reputational concern.
• External delivery partners: Contractors and service providers whose work can change the evidence base. If a contractor installs network equipment and the data about that installation enters London Grid's systems, the contractor is inside the effective enterprise boundary for data quality purposes.

Outside the first cycle but still visible:

• Commercial and retail functions that do not directly shape the connections, resilience, or data-publication decisions the first cycle must support.
• Long-term DSO transition ambitions that will require architecture attention in later cycles but do not materially change the current decision set.
• Innovation and research projects that are exploratory rather than operational.

The first cycle therefore cannot be scoped as an IT improvement programme. It has to be framed as an enterprise change effort with regulated interfaces at the edge of the boundary and explicit decisions about what will be tackled now versus what will be deferred to later cycles.

Tailoring for London Grid. London Grid would tailor TOGAF by keeping the full ADM phase structure (because the regulated context demands traceable governance) but adapting the artefact set to prioritise data-authority maps, evidence trails, and integration specifications over generic capability models. The tailoring decision would also integrate TOGAF with the organisation's existing OT security framework, since cyber resilience across SCADA, IT, and telecoms cannot be handled as a separate workstream.

Understanding what good Preliminary Phase work looks like also means recognising the most common failures. These failures are not theoretical. They appear in real programmes, and each one makes later ADM phases harder.

Skipping the Preliminary Phase entirely. Some organisations jump straight to Phase A because they feel pressure to start producing architecture outputs. The usual result is a Phase A that has to do the Preliminary Phase work anyway, but with less time, less discipline, and less stakeholder attention. The scope arguments, governance gaps, and principle vacuums that should have been resolved early instead surface as crises in later phases.

Treating the enterprise boundary as the org chart. This is the most common boundary error. The team draws the boundary around the departments they know and excludes everything else. External regulators, system operators, and delivery partners that materially shape architecture decisions are left out. The result is an architecture that looks internally coherent but breaks when it meets external reality.

Producing principles without implications. Many teams write principles that sound impressive but create no design consequences. Module 10 will cover this in depth, but the root cause often starts here: the Preliminary Phase produces principles as a box-ticking exercise rather than as governance instruments that will shape real trade-offs.

Tailoring by omission rather than by design. The team does not record its tailoring decisions. It simply skips the parts of TOGAF that seem difficult or unfamiliar. Later, when governance gaps appear, nobody can explain whether the omission was deliberate or accidental. Tailoring by design means recording what was changed and why.

Setting up governance that is too heavy or too light. Some organisations create elaborate governance structures before a single artefact exists, burning goodwill and making architecture look like overhead. Others create no governance at all, making architecture advisory by default. The right answer is proportionate governance: enough structure to survive the first contested decision, with room to mature as the capability grows. Module 13 will cover this in detail.