Enterprise architecture: capabilities, portfolios and governance without bureaucracy

The problem: many good solutions that do not fit together

An organization has grown by acquisition and by independent teams. It runs four customer databases, three identity providers, two billing systems and a dozen integrations nobody can fully draw. Each project was reasonable on its own. Together, they make every change slow: a new product needs data from five places, a security fix must be applied in seven, and nobody can say which systems are safe to retire. No single solution architect can fix this, because the problem lies between solutions.

Enterprise architecture (EA) is the discipline of managing that "between": aligning the structure of business capabilities, applications, data and technology with the organization's strategy, so that individual projects add up to a coherent whole. The Open Group's TOGAF is one well-known framework for it. You do not need to adopt a whole framework to use the ideas.

EA versus solution architecture

They depend on each other. Enterprise architects set direction and guardrails; solution architects apply them, and report back where reality does not fit. See the solution architect role.

Core building blocks

Business capabilities

A capability is what the business can do, independent of how it is organized or which system supports it: "manage customer identity", "price a product", "settle a payment". A capability map lists them in a hierarchy and is stable over years, while org charts and applications change. Mark each capability with strategic importance and with the health of its supporting systems. Capabilities are also a useful starting point for service boundaries, a topic covered in microservices boundaries.

Application portfolio

An inventory of applications with a small, honest set of attributes: owner, supported capabilities, lifecycle stage (planned, active, contained, retiring), technology, criticality and cost where known. Use it to find duplicates (four customer databases), gaps (no system for a capability) and risks (critical systems on unsupported platforms). A portfolio that is not maintained quickly becomes fiction, so link it to existing processes such as change management.

Principles and standards

Principles are short statements with a rationale and implications, for example: "Systems of record own their data; others read through APIs or events." Standards are more specific: approved identity provider, API style, logging format, supported databases. Keep standards few, explain why they exist and include a clear path to request an exception.

Target and transition architectures

The baseline is where you are, the target is where strategy needs you in a few years, and transition architectures are the intermediate steps that deliver value on the way. A roadmap states what changes when. Example sequence for the identity problem above:

Baseline:   3 identity providers, each app has own login
Transition: new apps must use provider A; legacy apps get
            an adapter (federation) in front
Target:     one identity provider for staff, one for customers;
            legacy providers retired

Without transitions, a target is a wish; with them, every project knows its small contribution.

Governance without bureaucracy

Governance is about making decisions consistent and visible, not about gatekeeping. Practices that tend to work:

• Guardrails over gates. Publish principles and paved paths; teams that follow them need no approval.
• Review by risk. Only decisions that cross domains, introduce new technology classes, affect security or carry significant cost need architecture review.
• Lightweight records. Use ADRs and short one-page proposals rather than long documents.
• Fast turnaround. A review process that takes weeks teaches teams to avoid it. Agree on a response time and meet it.
• Visible decisions. Publish outcomes so other teams can learn from them.
• Exceptions as data. Track exceptions; repeated exceptions to one standard mean the standard is wrong.
• Shared ownership. Include delivery engineers in forums that set standards.

The smallest useful start

You do not need a large programme to begin. A practical first step is three things: inventory the thirty or forty most important applications with their owners, draw a one-page capability map with business owners, and write four or five principles after discussing them with the teams. Subsequent projects are then checked against these three artefacts, and gaps are filled based on real need.

Using diagrams at enterprise scale

At this level the C4 model context view becomes a landscape: systems as boxes, grouped by capability, with integrations between them. Resist drawing every interface; show the important flows and the systems that carry many of them.

Common mistakes

1. Ivory tower. Principles written without involving the people who must follow them are ignored.
2. Frameworks as goals. Completing every artifact of a framework is not the objective; reducing cost and risk of change is.
3. Stale inventories. An out-of-date portfolio is worse than none because people trust it.
4. Standards without rationale. Rules that cannot be explained invite workarounds.
5. Big-bang target states. Plans that need everything to change at once do not survive reality.
6. Governance as a bottleneck. If review is the slowest step, teams will route around it.
7. Ignoring people and funding. Architecture without budget and ownership stays on slides.

Trade-offs

Standardization lowers cost and risk but limits local optimization; a team may have a better tool for its own problem. Centralized control gives consistency at the price of speed; federated models give speed at the price of duplication. Most organizations choose a middle path: strong principles in a few critical areas (security, identity, data ownership) and freedom elsewhere. Small companies often need only a one-page principles list and an application inventory, not a dedicated EA function.

Checklist

• Capability map agreed with business owners
• Application portfolio with owners and lifecycle stages
• A short list of principles with rationale
• A few standards with an exception process
• Baseline, transition and target described for key areas
• Review criteria based on risk, with a response-time target
• Decisions published and exceptions tracked

Where to go next

Compare scopes in the solution architect role, practise lightweight decision records in ADR writing, or follow the Enterprise Architect roadmap.