An enterprise is a system of moving parts, and when it changes those parts without a shared plan they stop fitting together and the cost of every later change rises.
Pre-ADM foundations, the on-ramp to the TOGAF method
Enterprise architecture is the description of how the parts of an organisation fit together and change as one, across the business it runs, the data it holds, the applications that process that data, and the technology beneath them. It is the shared plan that keeps an enterprise coherent while it grows.
It matters because an enterprise is a system of moving parts, and when those parts are changed without a shared plan they stop fitting together and the cost of every later change rises. A clear architecture means change is chosen on purpose rather than accumulated by accident.
This opening stage builds the ground the method stands on. It first treats the enterprise as one end-to-end system, then shows that the system spans four domains and not only its software, and finally explains how a light architecture keeps that whole from sliding into tangle.
The word architecture carries two senses, and a learner has to hold both. ISO/IEC/IEEE 42010 uses it descriptively, as the fundamental concepts or properties of a system in its environment, so a bank already has an architecture whether or not anyone wrote it down. TOGAF adds a prescriptive sense: a formal description of a system, or a plan of its components, used to guide implementation. One names what is true now; the other is the plan you build from, and confusing them means describing the bank you have when you meant to design the one you want.
The stage builds up in this order. Read it straight through on the first pass, or jump to any concept.
An enterprise is a chain of connected stages that together turn inputs into something a customer values. When an online retailer takes an order, payment, inventory, picking, and delivery are one flow, so a change to any single stage ripples into the others. This end-to-end view is where the stage starts.
It is tempting to see an enterprise as a set of independent departments or systems that can each be changed in isolation, but that view hides the ripples and the cost lands later. The sounder habit is to map how value flows from end to end first, so any proposed change is judged by its effect on the whole chain rather than only the part being touched.
A complex operation is described across four layers: the business it runs, the data it holds, the applications that process that data, and the technology that hosts them. A hospital is not only its patient-records system; it is also its clinical processes, its information, and its infrastructure together.
The frequent error is to reduce the enterprise to its software, so changing the systems is treated as the same as changing the enterprise itself. The better practice is to describe any change across all four domains, so business intent, information, applications, and technology stay aligned instead of one layer quietly drifting away from the others.
Architecture is a shared plan for how the parts of an enterprise fit and change together, so growth does not turn into tangle. A scale-up that wires every new tool directly to every other ends up with dozens of point integrations that no one can safely change, and the knot tightens with each release.
A common belief is that architecture is heavyweight documentation, or that a team is too small or too fast-moving to need any shared plan. In truth it is a light set of agreed decisions that constrain how change happens, applied from the start so that complexity is chosen on purpose rather than left to pile up by accident.
Printable, fillable artefacts for putting this stage to work. Each cites its source, opens in the diagram workspace, and downloads as it stands.
Five voltage tiers form a step-down ladder from 400/275 kV transmission at the top to the 230 V customer outlet at the bottom. A downward axis tracks the falling voltage and a red bracket marks the DNO licence boundary over the lower tiers.
Preliminary
Three lanes read left to right: the external input the operator receives, the DNO function held accountable for it in the middle, and the public output that function produces. Flow arrows make the input-to-output trace explicit.
Preliminary
Four outcomes a sponsor cares about, read as columns: cost, delivery speed, risk and change. The upper state is each outcome with enterprise architecture in place; the lower state is the failure mode without it.
Preliminary
Check what has landed. The practice set gives instant feedback as you go; the timed assessment mirrors a real sitting, with a pass record and a breakdown by domain.
