Enterprise Architecture and Business Capabilities

The insurer’s enterprise architecture team had been busy for two years. It had produced eighty diagrams, a hundred-and-forty-page target state, a technology reference model, and a principles document that every project was asked to sign. Then the claims modernization program started and, in its first month, discovered things the diagrams did not show: four systems that adjudicated claims, three that each believed itself to be the customer master, and two teams in different business units building the same document-intake capability at the same time. When the CIO asked the architecture team the question the program had raised, where the company should put its next twenty million, the team had a portfolio of artifacts and no answer. The artifacts described systems. The question was about capabilities, and nothing connected the two.

The company is fictional. Its problem is the missing connection between strategy, capabilities, and investment choices. This article explains enterprise architecture as decision support: how business, application, data, and technology maps can be joined, how current and target states inform a transition plan, and how a framework such as TOGAF helps organize that work.

What enterprise architecture is for

The U.S. Office of Management and Budget’s Federal Enterprise Architecture Framework, version 2 (FEAF), describes architecture as information that supports planning and decisions at different scopes. It separates strategy, business, data, applications, infrastructure, and security. Scope is a separate axis: a data decision can concern one system or an entire organization. Architecture Levels and Domains explains that distinction and the roles involved; enterprise architecture introduces the discipline. A useful artifact identifies the decision it informs, the assumptions behind it, and who can act on it.

Architecture also needs continuing business participation. Ross and Quaadgras’s 2012 MIT CISR research connects value from digitized platforms with management practices: transparent costs, discussion of exceptions, implementation reviews, and investment decisions informed by architecture. For the insurer, that means giving leaders evidence about which capabilities need attention and what alternative changes would achieve.

Four maps, and the thread through them

The following four maps are the author’s grouping for this investment discussion, not an exhaustive list of EA domains or required framework artifacts. Strategic goals connect to the capabilities and changes they require.

Security requirements cross the maps: identify sensitive activities and data, required access boundaries, and controls that proposed systems and platforms must satisfy. FEAF’s line of sight connects detailed work to organizational outcomes. Here, maintained relationships between the maps make that connection inspectable.

Map	Question it answers	Unit	Joined to the next map by	What it exposes when it is honest
Business (capability map)	What must the organization be able to do, and how well?	A capability, such as adjudicate a claim, with its scope	People, processes, information, and applications supporting it	Performance gaps and capabilities needing investigation
Application (portfolio)	Which systems exist, what does each do, who owns it, and what does it cost?	An application or service, with lifecycle and capability mappings	Data it holds or maintains authoritatively within a defined scope	Functional overlap to investigate; missing owners; support risks
Data	What do entities mean in each context, who may change each fact, and where do copies flow?	An entity or attribute set, its context, authority, consumers, and classification	Platforms and controls supporting its sources and flows	Conflicting authority over the same facts; missing ownership; unaccounted copies
Technology	Which platforms, standards, and reference designs are approved, and which are retiring?	A platform, a standard, a reference architecture, with status and owner	Back to the capabilities and applications that depend on each	Standards nobody follows; platforms whose retirement date nobody planned for

Most organizations already hold pieces of the lower three maps in operational records, and the architecture function’s first job is to join them rather than to redraw them. The application map can draw on a service catalog with application-level grouping, lifecycle, cost, and coverage checked, and for AI-based uses an AI system inventory. The data map is a data catalog read for ownership and authority, with a business glossary to say what an entity means and a bounded context to say where that meaning holds. The technology map is the standards register that A Standard Nobody Could Deviate From describes, with each technology standard and reference architecture carrying an owner and a status. The architecture function checks whether these records cover the relevant estate and connects them to capabilities and strategic goals.

Four systems supporting one capability are a reason to inspect their responsibilities, not proof of duplication. Intake, adjudication, and payment systems can perform different parts of claims handling; different jurisdictions may also require distinct implementations. Compare overlap at the same functional, population, and service scope before proposing consolidation. Data authority needs an equally explicit scope: billing and marketing can use different customer concepts, and different systems can own different attributes. Agree shared identifiers, mappings, and conflict rules where those contexts interact.

The capability map is the one that connects

A business capability map classifies the abilities an organization needs independently of its departments and systems. FEAF’s Business Reference Model similarly classifies business functions across organizational boundaries; its capability-analysis guidance helps expose requirements that could share an implementation. In the fictional insurer, mapping two document-intake proposals to the same capability prompts a comparison of their users, rules, and service needs. Shared labels identify candidates for reuse; the comparison determines whether one service would actually fit both.

Name capabilities by the work the organization must be able to perform, such as adjudicate a claim, rather than by the team currently doing it. Keep a common vocabulary and relate local detail to it. Names can remain stable across reorganizations while the business itself can still gain or lose capabilities. Use an executive summary for broad priorities and deeper views for design and analysis. Neither a page limit nor an entry count distinguishes capabilities from processes: a capability names an ability, while a process describes activities and their flow. Twenty parent capabilities with twenty subcapabilities each still describe abilities, despite having four hundred leaves. The related entry on capability explains the people, authority, procedures, and systems needed to demonstrate an ability under stated conditions.

Overlay strategic importance and current performance to identify where investigation matters most. Health evidence includes completion time, errors, staff skills and capacity, decision authority, process bottlenecks, data quality, system reliability, and support status. Catalogs supply part of this evidence; observation of the work and discussion with its owners supply the rest. An important, weak capability becomes a candidate for improvement, not an automatic allocation of twenty million. Compare training, process changes, improvements to existing systems, replacement, and external provision against expected benefit, total cost, obligations, dependencies, transition risk, and available capacity. The authorized investment owner then decides. In the fictional case, assume that analysis confirms avoidable overlap within the same claims scope and supports selective consolidation over maintaining all four implementations; that additional finding, not the heat map alone, justifies the proposal.

Current state, target state, and the plan between them

FEAF distinguishes the current state, the intended future state, and the transition plan connecting them. A target architecture describes the future capabilities, systems, data relationships, responsibilities, and constraints within a chosen scope and planning horizon. Comparing it with the current state identifies gaps; the roadmap sequences work to close them. A change list can summarize that comparison, but cannot replace the relationships and boundaries needed to judge the target. Document enough of the current state to understand relevant dependencies, obligations, and risks, including systems that will remain unchanged.

Part	What it contains	What it deliberately leaves out	Example from the insurer
Current state	Capabilities, performance, systems, data, controls, and relevant dependencies	Unrelated detail that does not inform the decision	Four claims systems and overlapping customer records, with owners, costs, support, and interfaces
Target state	Intended capabilities, components, relationships, responsibilities, principles, and constraints within a stated horizon	Implementation detail unnecessary for judging this enterprise decision	For the agreed shared claims scope: one adjudication platform and intake service, consuming a customer identity master; domain-specific customer attributes remain separately owned
Transition plan	Work, dependencies, milestones, funding, risks, and usable intermediate states	Task-level schedules maintained by delivery teams	Customer identity master enters service first, shared intake second, adjudication third. Development can overlap, but intake cutover requires the master, and adjudication cutover requires both
Decision records	Choices, alternatives, rationale, authority, assumptions, and consequences	Implementation instructions unrelated to the recorded choice	Why a particular claims platform was retained, under which requirements, and what would reopen that choice

The required degree of standardization and integration is a business choice to develop with architecture. Standardization asks which units should use common processes; integration asks where they need shared information and coordinated work. These choices can differ by capability. In the fictional insurer, leaders choose a shared customer identity and common claims processing within an agreed product and jurisdiction scope, while retaining local product design and domain-specific customer attributes. A customer identity master is justified by that agreement, not by a general rule that every customer fact belongs in one physical database. The target must show how local and shared responsibilities interact, and who settles conflicts.

Record significant target choices in an architecture decision record, with alternatives and consequences. The reversibility discussion in Architecture Decisions applies here: a platform replacement can become costly to undo as data and consumers migrate. Revisit assumptions after strategy changes, acquisitions, support changes, or repeated exceptions, and periodically check assumptions and the coverage of those signals. Exceptions may reveal a target mismatch, missing support, transition cost, or temporary constraints. Investigate before retaining or revising the target. MIT CISR describes development from business silos through technology standardization and integrated processes to reuse. A distant target can guide that journey if the plan provides feasible intermediate states and learning; higher maturity alone does not guarantee business value.

What TOGAF gives you, and what it does not

The Open Group describes TOGAF as a method and framework for developing and governing enterprise architecture. Its public overview connects the Architecture Development Method (ADM) to architecture vision, business and technical views, migration planning, implementation governance, and change management. This is a method overview, not a phase-by-phase implementation guide. A team adopting the standard should use its applicable guidance to define the work, responsibilities, and evidence needed for its own scope.

A framework gives people a shared way to organize architecture work. It still requires business leaders to make choices about outcomes, shared responsibilities, and investment. A method can help expose disagreement, but a completed artifact cannot settle it by itself. Ross and Quaadgras emphasize continuing review of costs, exceptions, and project outcomes. Applied to the insurer, that means recording why consolidation was chosen, checking whether the transition remains feasible, and measuring whether the resulting claims service improves the work. Architecture deliverables should support those decisions rather than become the sole measure of progress.

Judging an architecture function

The following are proposed measures for the architecture function. Track how much of the investment portfolio has a documented connection to capabilities and strategic goals, and whether decisions use that evidence. Examine system counts alongside confirmed functional overlap, service requirements, and transition costs; fewer systems is not automatically better. For shared data, measure whether authority is defined for the relevant context and attributes, including conflict handling. Measure how quickly owners and dependencies can be identified, with inventory coverage and freshness visible. Review whether significant target choices have reasons, alternatives, and recorded reconsiderations. Ask business leaders to explain the choices and their consequences. Artifact counts and compliance-review counts describe activity; read them with what the work verified or changed and the outcomes observed, rather than treating either a large or a small count as proof of value.

What a reviewer should ask

1. Which decision, made by whom, is each architecture artifact meant to inform, and when was it last used for one?
2. Do executive and detailed capability views share a vocabulary, and does each view contain the detail its decisions need?
3. For each strategic goal, which capabilities must change, and can that be traced down to systems and up to the goal?
4. Where do systems actually overlap within the same capability scope, and where is data authority unclear for a specific context or attribute?
5. Has the business chosen how much to standardize and how much to integrate across its units, and does the target reflect that choice or the architects’ preference?
6. Does the target describe a coherent future state, with a gap analysis and feasible transition plan linked to it?
7. What would trigger a revision of the target, and when did it last happen?
8. If the organization uses TOGAF or another framework, which parts has it configured out, and why?
9. Which investment decisions used the capability evidence, what alternatives were compared, and what outcomes followed?

In the fictional insurer, the team builds an executive view of forty-four capabilities, backed by detailed mappings where decisions need them. The business units agree the scope of shared customer identity and claims processes while retaining local product design. The target shows components, responsibilities, and interfaces; a separate gap analysis identifies eleven changes. The investment committee compares the alternatives and approves a staged consolidation on the assumptions described above. Development overlaps, but operational cutover proceeds from the customer identity master to shared intake and then adjudication. Existing diagrams are retained or updated where they explain relevant dependencies. When the CIO asks again, the team can present the target, the reasons for the investment choice, and a transition plan whose milestones can be checked. Those artifacts support the decision; delivered benefits still need measurement.

References

• U.S. Office of Management and Budget, Federal Enterprise Architecture Framework Version 2 (2013), introduction and planning guidance
• Jeanne W. Ross and Anne Quaadgras, Enterprise Architecture Is Not Just for Architects, MIT CISR (2012)
• The Open Group, How the ArchiMate Language and the TOGAF Standard Complement Each Other — public overview