Enterprise Architecture

Enterprise architecture operates above any single system, aligning IT and business strategy across the whole organization. It maps how business capabilities, processes, data, applications, and technology fit together, and provides a target state plus a roadmap to get there. The goal is coherence and reduced duplication at scale — ensuring individual project decisions serve the broader strategy. EA is concerned with standards, reference architectures, and governance, deliberately taking a wider and longer view than solution or software architecture.

The ADM is the heart of TOGAF (The Open Group Architecture Framework) — a cyclical method for producing enterprise architecture. Its phases move from an Architecture Vision, through Business Architecture, Information Systems Architecture (data and application), and Technology Architecture, into Opportunities & Solutions, Migration Planning, Implementation Governance, and Architecture Change Management — with Requirements Management at the center. It is deliberately iterative: organizations adapt and repeat phases rather than executing once. The ADM gives EA teams a repeatable, governed process rather than ad hoc design.

A capability map (or business capability model) decomposes an organization into the stable building blocks of what it does — "Customer Management," "Order Fulfillment," "Risk Assessment" — deliberately abstracting away how (processes) and who (org structure), which change frequently. Because capabilities are stable, they make an excellent anchor for analysis: you can heat-map which capabilities are strategically important vs. well-supported, spot duplicated systems serving the same capability, and align technology investment to business priorities rather than to org-chart politics.

An ADR is a lightweight, immutable record of one important architectural decision. A typical ADR states the context (the forces and constraints), the decision (what was chosen), the status (proposed/accepted/superseded), and the consequences (trade-offs and follow-on effects). Stored alongside code in version control, ADRs create a durable, searchable history that answers the question future teams always ask: "why was it built this way?" When a decision is later reversed, a new ADR supersedes the old one rather than editing history.

A Wardley map (Simon Wardley) plots the components needed to serve a user need along two axes: the value chain (visibility to the user, vertical) and evolution (genesis → custom-built → product → commodity, horizontal). Positioning components by evolutionary maturity reveals strategy: build the novel, differentiating components yourself; buy or use commodity utilities (like cloud compute) rather than reinventing them. It makes situational awareness explicit, helping architects avoid custom-building what is already a commodity, and focus scarce engineering effort where it differentiates.