Preliminary Phase and Architecture Vision

The enterprise boundary is the set of organisations, partners, obligations, and delivery domains that a given piece of architecture work actually covers. Take a redesign of an airline loyalty programme: the boundary spans the internal product and data teams, the external card issuer that funds the points, and the data-protection duties that govern member records. None of those sit neatly inside one box on the org chart, yet all of them shape the design.

The frequent error is to treat the architecture enterprise as whatever sits inside the internal org chart, so that anything outside it is automatically out of scope. That leaves the most binding constraints invisible until late. The better test is one of influence: include an actor or an obligation in the boundary if it materially constrains the design or the governance, even when it sits outside the internal organisation. A regulatory interface that shapes the work belongs inside the effective boundary, not outside it.

A viewpoint is a deliberate choice to show the one slice of the enterprise that answers a particular stakeholder's concern, not a visual style. Consider a change to a hospital's patient-records system. The finance director, a clinician, and an integration architect are all discussing the same change, but each needs a different view of it: cost and accountability, care and failure impact, data and interface boundaries.

It is tempting to believe that one master diagram can serve every audience, so that a single all-purpose picture is enough for the whole programme. In practice that picture usually satisfies nobody, because each reader is asking a different question. The way out is to ask whose decision each artefact is meant to improve. If the honest answer is everyone, the artefact is probably too vague, and it should be split into concern-led viewpoints before the inventory grows.

A working architecture principle has three parts that earn their place: a statement, a rationale, and implications that change real trade-offs. A bank's "buy before build" principle is an example, because it decides procurement the moment a payments capability could be bought, forcing any team that wants a custom build to justify the exception. The implication is what makes it architecture rather than decoration.

Principles are often mistaken for values posters, so a slogan such as "customer first" gets logged as an architecture principle. The trouble is that a delivery team cannot comply with it or break it in any concrete way. A useful filter is exactly that operability: keep a principle only if a team could measurably comply with it or violate it. If it has no operational consequence, rewrite it until it does, or drop it.

A business scenario captures the actors, environment, pressures, constraints, and required outcomes of a real problem, so that symptom is separated from cause. "Checkout is slow" is a complaint, not a scenario. For an online retailer it becomes one when it names the peak-hour shoppers, the third-party payment latency behind the delay, and the abandoned-basket cost that makes it worth solving.

The opposite habit is to treat a broad statement such as "we need better digitalisation" as specific enough to scope architecture work. It is not, because it hides the very details a design has to respond to. Naming the actors, the trigger conditions, the constraints, and the measurable outcomes makes the architecture-relevant reality explicit before scope is set. The discipline is to earn that specificity, not to invent a tidy story, so the scenario surfaces reality rather than reading like fiction.

Scoping decides which questions get answered now, at what level of detail, over what time horizon, and across which domains. A scale-up running its first architecture cycle might cover only onboarding and billing, to system level, over a two-year horizon, while deliberately deferring its wider platform. Each of those is a separate dimension, and naming all four keeps the effort from quietly expanding.

A common plan is to start broad and narrow later, on the assumption that wide diagrams now will be refined into useful detail in time. More often the team produces broad pictures and never narrows enough to guide a single change. Better to set scope that is specific enough to direct change yet open enough to reveal dependencies, and then to write down explicitly what has been deferred. Recorded exclusions are what stop a two-year cycle from being asked to solve everything.

Sponsorship means decision backing, access, and the authority to resolve delivery conflict, not just a signed-off budget. When a university begins a student-services architecture that crosses admissions, finance, and IT, the sponsor has to name the review forums and the escalation path. Without that, each department steers its own way and the repository fragments along the same lines.

Sponsorship is easily reduced to passive endorsement, as though an executive's approval and a budget line were all the effort needed. That leaves the work advisory, with no way to settle the first real disagreement. The stronger move is to establish a governance setting in which architecture conclusions can actually influence delivery, with named decision forums and a clear escalation route, before the work begins. Authority, not permission, is what keeps the conclusions from being ignored.

Phase A also asks how ready the enterprise really is to change, scoring factors such as governance, funding, capability, and culture before the Vision is committed. When a retailer plans to move from store-led buying to a central digital model, an honest reading might show strong funding but thin delivery capability and a culture that protects regional autonomy, each a transformation risk that needs a named mitigation. Read early, readiness shapes the plan; read late, it becomes the excuse for why the plan slipped.

The Architecture Vision says where the enterprise is heading and why; the Statement of Architecture Work turns that direction into scope, approach, constraints, outputs, and a review path. A government department's vision might set a digital-first service direction, while its work statement commissions exactly what this cycle will produce and how it will be checked. The pair belongs together: one gives intent, the other makes the intent governable.

The risk is to treat a polished vision statement as the deliverable, so the work feels defined the moment leadership agrees the direction. A vision that cannot be traced to a deliverable, a constraint, and a review path leaves delivery teams guessing and weakens the whole ADM cycle. The remedy is to trace every line of the vision through a Statement of Architecture Work, because vision without a work statement is aspiration and a work statement without vision is administration.

Phase A produces more than the Vision and the work statement. A Capability Assessment sets out what the enterprise can actually do today against what the change will demand, so a bank promising real-time fraud screening admits whether its teams and platforms can run it yet. A Communications Plan names who must be kept informed and through which routine, so stakeholders are not surprised mid-cycle. Together they back the Vision with an honest capability picture and a steady flow of news, not just a diagram.