Buy a house and you read the survey before you sign. Software is no different: the costliest mistakes are made not in the code but in the layout, what connects to what, where the load-bearing walls are, and what you can never move later without tearing the place apart. Architecture is the discipline of deciding that layout on purpose, before it sets.

The quick version

  • Solution architecture is the design of one system or product, its parts, how they connect, and the technology choices behind it. Think the blueprint for a single building.
  • Enterprise architecture is the design of the whole estate, every system, how they fit the business strategy, and the standards they share. Think the city plan the buildings must respect.
  • Leaders hear the same few framework names: TOGAF and Zachman (enterprise-level), and the C4 model (a plain way to draw a single system). They are maps, not magic.
  • The most useful idea here is Conway's Law: your systems end up shaped like your org chart. Reorganise the teams and you reorganise the software, for better or worse.

The idea in depth: two zoom levels of the same craft

The clearest way to hold the two terms apart is altitude. Solution architecture works at ground level: it answers "how do we build this thing?", the new billing system, the customer app, the data pipeline. It picks the components, decides how they communicate, names the databases and services, and weighs the trade-offs (faster now versus cheaper to change later). Enterprise architecture flies higher: it answers "how should all our systems fit together to serve where the business is going?", which capabilities we need, which we duplicate by accident, and which standards keep the estate from becoming a hundred incompatible islands.

So the move for a leader is to know which question you are actually asking. Building one product? You want a solution architect who will commit to a design and its trade-offs. Untangling a sprawl of overlapping tools across departments? That is an enterprise-architecture problem, and a single project team cannot solve it, it needs a view across the whole map. Asking a solution architect to fix enterprise sprawl, or an enterprise architect to ship one feature, is a common and expensive category error.

flowchart TD
  EA(["Enterprise architecture
the whole estate + strategy"]) --> S1(["Solution: billing system"])
  EA --> S2(["Solution: customer app"])
  EA --> S3(["Solution: data platform"])
  EA -.sets shared standards.-> R(["Security · data · integration rules"])
  R -.-> S1
  R -.-> S2
  R -.-> S3
Enterprise architecture sets the rules every solution must respect; each solution is one building inside the plan. Leaders Loop

At the enterprise level, the field has two foundational reference points worth knowing by name. The first is John Zachman's framework, published as "A Framework for Information Systems Architecture" in the IBM Systems Journal in 1987, a grid that crosses six questions (what, how, where, who, when, why) with the perspectives of different stakeholders, from the executive's view down to the engineer's. The second is TOGAF (The Open Group Architecture Framework), first released in 1995 and now in its 10th edition, whose centrepiece is the Architecture Development Method (ADM): a repeatable cycle that moves from a preliminary phase and an architecture vision through business, information-systems and technology architectures, and on to implementation governance. TOGAF organises an enterprise's design into four standard domains, business, data, application and technology.

So the move is to treat these frameworks as a shared vocabulary, not a recipe. When an architect says "we're in Phase B" or "that's a technology-architecture decision," they are pointing at a place on a well-known map; knowing the map lets you follow the conversation and ask where the business value lands. What you should resist is the idea that adopting TOGAF wholesale will fix things on its own.

An honest limitation. These frameworks are heavyweight, and applied dogmatically they generate documentation faster than working software, an "ivory tower" failure mode the architecture community openly criticises. TOGAF is explicitly meant to be tailored, not followed page by page, and Zachman is an ontology for classifying artefacts rather than a method for producing them. A framework can document a bad design just as neatly as a good one.

Why your software ends up shaped like your org chart

The single most durable idea in this field is older than most of the frameworks. In 1968 the programmer Melvin Conway published "How Do Committees Invent?", arguing that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations." Restated plainly: if three teams build a compiler, you get a three-pass compiler. The boundaries between your people become the boundaries inside your software, because the parts that need to talk are built by people who need to talk.

"Organizations … are constrained to produce designs which are copies of the communication structures of these organizations.", Melvin Conway, 1968

This is not a curiosity; it is a lever. If you accept that structure follows org design, then the architecture you want should inform the teams you build, the practice now called the "inverse Conway manoeuvre," where you arrange teams deliberately to produce the system shape you're after. So the move for a leader is to stop treating reorganisations and architecture decisions as separate conversations. When you split a team, you are quietly drawing a new line in the software; when you want two systems to integrate cleanly, check whether the two teams who own them actually talk. The org chart is a design document whether you intended it to be one or not.

An honest limitation. Conway's Law is an observed tendency with strong intuitive and case-study support, not a measured constant, it tells you which way the wind blows, not how hard. Teams can deliberately resist it (a single team can build modular software; distributed teams can build a tangled monolith). Use it as a prompt, "does our team structure match the system we want?", rather than a guarantee that redrawing the org chart fixes the code.

Drawing the thing so everyone sees the same picture

Most architecture failures are really communication failures: the whiteboard box labelled "the system" means something different to every person staring at it. Simon Brown's C4 model is the most approachable fix, a way to draw software at four zoom levels so a diagram says what it means. Context shows your system as one box among its users and neighbours; Containers zoom in to the runnable pieces (the web app, the mobile app, the database, the API); Components open one container to show its major parts; Code goes deeper still, rarely needed. The discipline is that each diagram has one zoom level and a legend, so nobody confuses a database with a department.

flowchart TD
  L1(["1 · Context
system + its users & neighbours"]) --> L2(["2 · Containers
web app, API, database"])
  L2 --> L3(["3 · Components
parts inside one container"])
  L3 --> L4(["4 · Code
classes, rarely drawn"])
The C4 model: four zoom levels, each its own diagram, so a picture means the same thing to everyone in the room. Leaders Loop

So the move, even if you never draw one yourself, is to ask for the Context and Container views when an architect presents. They are readable without a technical background, they reveal the dependencies (and the single points of failure), and they expose hand-waving, if nobody can draw the system at the container level, nobody yet agrees on what it is. A clear diagram is the cheapest risk control in the building.

A worked example

Take a mid-sized insurer, call it Meridian. (Illustrative throughout; not a real company.) Over a decade it grew by acquisition, and each business unit brought its own customer system. The same policyholder now exists three times, with three addresses, in three databases that don't talk. Every "single view of the customer" project has stalled, and leadership keeps asking for one dashboard that nobody can build.

The instinct is to commission a solution, a shiny new dashboard. But the dashboard is the symptom. The root problem is enterprise-level: three overlapping customer systems and no shared standard for what a "customer record" is. Notice the Conway signature, too, three customer systems because three acquired teams never merged. A solution architect scoped to "build the dashboard" would wire it on top of the mess and harden the mess in place.

flowchart TD
  P(["Ask: 'build one
customer dashboard'"]) --> Q{"Is this one system,
or the whole estate?"}
  Q -->|"Symptom, solution scope"| W(["Dashboard on top of
3 silos: mess hardened"])
  Q -->|"Root cause, enterprise scope"| E(["Define one shared
'customer' standard + owner"])
  E --> F(["Then: build the dashboard
on a single source of truth"])
The dashboard is the symptom; three siloed systems with no shared standard is the disease. Architecture means naming which one you're treating. Leaders Loop

The architecture move is to separate the two questions. First, an enterprise-level decision: agree one definition of a customer record and one system that owns it, and make every unit's data reconcile to it. Only then does the dashboard sit on a single source of truth instead of papering over three. The order is everything. Treating a structural problem as a feature request is how organisations spend a year and a budget to make the underlying tangle permanent.

Frequently asked questions

What's the difference between enterprise and solution architecture, in one line?

Solution architecture designs one system; enterprise architecture designs how all your systems fit the business strategy. One is the building, the other is the city plan. The two need each other, a brilliant solution that ignores the estate's standards becomes next year's island.

Do we need an enterprise architect, or is this big-company stuff?

The role scales with the estate. A startup with three systems doesn't need a dedicated enterprise architect, but it still makes enterprise decisions, what data is the source of truth, which standards everything obeys. As systems and teams multiply, those decisions stop happening by themselves and start needing an owner. The work exists before the job title does.

Is TOGAF something I have to adopt?

No. TOGAF is a large, detailed framework many big organisations use as a common method and vocabulary, and it is explicitly designed to be tailored. Smaller organisations often borrow its ideas, the four domains, the develop-then-govern cycle, without the full apparatus. Adopting the binder is not the goal; making sound, documented decisions is.

How does Conway's Law affect a decision I'd actually make?

Any time you reorganise teams, you are also reshaping the software those teams produce. If you want two systems to integrate tightly, the teams that own them need to communicate tightly; if you want a clean separation, separate the teams. Treat team design and system design as the same decision viewed twice.

I'm not technical, how do I sanity-check an architecture proposal?

Ask for a Context and a Container diagram (C4) and have someone walk you through them in plain English. Ask what becomes hard to change later, where the single points of failure are, and which business capability each piece serves. If those questions can't be answered simply, the design isn't ready, and that's the cheapest moment to find out.

Related in the Toolkit

Architecture is the layer above the nuts and bolts: it decides how the server-side pieces and hosting choices fit together, and it only pays off when the systems it designs are actually delivered well, which is what delivery metrics measure.

Where to go next