Enterprise Architecture

Enterprise architecture. This lesson is about the map that keeps I-T aligned with the business as both of them change, and why the exam treats it as a governance control rather than a technical drawing.

Picture a company with a beautiful enterprise architecture. Layered diagrams, a target-state model, principles on every page. It also has three separate systems doing customer onboarding, two overlapping data warehouses, and a new tool just approved that duplicates a capability it already owns. The architecture is excellent. It is also being ignored, and that is the finding.

Because the exam does not treat enterprise architecture as a technical drawing. It treats it as a governance instrument, a structured view of the business and its I-T that keeps investment and systems aligned with business direction as the organisation changes over time.

The problem it solves is drift. Organisations wander. New systems get bought to solve today’s problem, duplicating capabilities that already exist, adding dependencies nobody tracks, slowly turning the estate into something no one understands. Enterprise architecture is the control against that drift. It gives decision-makers a map, so each new investment is judged against where the organisation is trying to go.

And this is why it helps the auditor directly: a good architecture reveals dependencies and single points of failure. When you can see that six systems rely on one shared component, you can see where risk is concentrated. A device list or an asset register never shows you that.

Used properly, enterprise architecture controls three things the exam cares about. First, alignment. New systems are assessed against the target architecture, so investment moves the estate toward business direction rather than away from it.

Second, redundancy. Duplicate capabilities become visible and avoidable, so the organisation stops paying twice for the same function.

And third, risk. Dependencies and single points of failure become visible, so you can see how risk is spread or concentrated across the whole estate. Alignment, redundancy, risk.

Now the common failure, an architecture that exists but decides nothing. If new systems are approved without reference to the enterprise architecture, and duplication keeps appearing, the architecture is a document, not a control. Its detail and its elegance are irrelevant. What matters is whether investment decisions actually pass through it.

So the auditor’s real test is not, is there an architecture. It is, is it used. Ask to see recent investment decisions and look for the architecture in them. If it is absent, the governance gap is the finding, and consolidating the duplicate systems only treats the symptom that gap produced.

Which is the trap. The instinct is to grade the architecture as a technical deliverable, to admire the diagrams. The exam asks a governance question: does this architecture govern how I-T investment is directed. A plain architecture that every decision consults beats a magnificent one that sits on a shelf.

So carry this away. Do not ask whether an architecture exists. Ask whether it governs how I-T investment is directed. That is the difference between a drawing and a control.