--- title: 'The Enterprise Architecture Concept' source: 'https://academia.sh/en/courses/enterprise-context/enterprise-architecture-concept' course: 'Enterprise Context and Integration' language: en updated: '2026-08-23T07:01:06+00:00' license: 'CC BY-SA 4.0' --- # The Enterprise Architecture Concept The level that steps outside a single system: turning the enterprise's systems, owners, budgets, and business capabilities into a data structure, and tying business–IT alignment to three numbers — a capability no system covers, a capability more than one system covers, and a system that cannot be tied to any capability. The previous course turned a decision into a record and a system into a view, and measured every document by the number of questions it answered. All those records and views shared one boundary: they stood inside a single system. But a system does not stand on its own. Beside it are other systems that serve the same member on the same day; some are bought from outside, some are paid for out of another unit's budget line, and for some, no employee of that enterprise can write a line of code. This lesson moves the scale up by one step. The Architecture Levels lesson in The Architect's Role course defined the enterprise level by scope: the number of deployment units a decision binds. That lesson's count of uninformed units is not repeated here; it is taken as an input. What changes is the unit itself: it is no longer a separately released deployment unit, but **a system with its own owner and its own budget**. Enterprise architecture is the name for this scale, and its first question is this: how well do the jobs the enterprise must do and the systems it has actually match. ## The Enterprise Is a Data Structure **Business–IT alignment** is, in words, an unmeasurable claim. For it to become measurable, two lists must be placed side by side: the **business capabilities** the enterprise must cover, and the systems that claim to cover them. The capability list is not derived from the systems; it comes from the enterprise's own business (**EA1**). This distinction carries the whole measurement: if the list were derived from the systems, an uncovered capability would never appear. The model used is a regional library network. It is fictional; no real institution, vendor, product, or person is described. The network has branch systems, a catalog system bought from outside, in-house loan and billing services, a separate membership system, an identity verification service that sits with the municipality, and a management unit that wants reporting. Owners and budgets are separate. A system is software paid for out of a separate budget, with a separate owner, and released separately (**EA2**). The coverage list in a system's record is a **claim**; whether the claim holds up in code is not tested in this lesson (**EA3**). An **edge** (integration edge) is the directed pair running from the system that writes to the system that reads across the same data asset (**EA4**) — this is the course's unit of measure. ```js // enterprise/model.mjs — MODEL regional library network: systems, owners, capabilities, data. // Fictional; no real institution, vendor, product, or person is described. export const SYSTEM = { catalog: { owner: "external-provider", budget: "service-fee" }, loan: { owner: "it-department", budget: "internal-development" }, billing: { owner: "it-department", budget: "internal-development" }, membership: { owner: "member-services", budget: "member-services" }, identity: { owner: "municipal-it", budget: "municipality" }, "branch-local": { owner: "branch-management", budget: "branch" }, kiosk: { owner: "branch-management", budget: "branch" }, reporting: { owner: "management-unit", budget: "management" }, archive: { owner: "none", budget: "none" }, }; // CAPABILITY — the business capabilities the enterprise must cover (a list independent of system) export const CAPABILITY = ["material-search", "loan-issuance", "return-intake", "reservation", "membership-enrollment", "member-verification", "fee-calculation", "fee-collection", "inter-branch-transfer", "asset-count", "usage-reporting", "purchase-suggestion", "overdue-notification"]; // COVERS[s] = the capabilities system s claims to cover export const COVERS = { catalog: ["material-search", "asset-count"], loan: ["loan-issuance", "return-intake", "reservation", "overdue-notification"], billing: ["fee-calculation", "overdue-notification"], membership: ["membership-enrollment", "member-verification"], identity: ["member-verification"], "branch-local": ["return-intake", "inter-branch-transfer", "asset-count"], kiosk: ["loan-issuance", "material-search"], reporting: ["usage-reporting"], archive: [], }; // DATA[v] = data asset; which system writes it, which ones read it export const DATA = { "member-record": { writes: ["membership"], reads: ["loan", "billing", "kiosk", "reporting"] }, "identity-match": { writes: ["identity", "membership"], reads: ["loan", "kiosk"] }, "material-record": { writes: ["catalog"], reads: ["loan", "kiosk", "branch-local", "reporting"] }, "copy-status": { writes: ["catalog", "loan", "branch-local"], reads: ["kiosk", "reporting"] }, "loan-transaction": { writes: ["loan", "kiosk"], reads: ["billing", "reporting"] }, "fee-record": { writes: ["billing"], reads: ["membership", "reporting", "kiosk"] }, "penalty-rule": { writes: ["billing"], reads: ["loan", "kiosk"] }, "transfer-request": { writes: ["branch-local"], reads: ["loan", "catalog"] }, "legacy-record": { writes: [], reads: ["archive", "reporting"] }, "count-discrepancy": { writes: ["branch-local"], reads: [] }, }; export const SYSTEMS = Object.keys(SYSTEM); export const owner = (s) => SYSTEM[s].owner; // edge = the directed pair from the system that writes a data asset to the system that reads it export function edges() { const e = new Map(); for (const [v, d] of Object.entries(DATA)) for (const w of d.writes) for (const r of d.reads) if (w !== r) e.set(`${w}->${r}`, [...(e.get(`${w}->${r}`) ?? []), v]); return e; } ``` ## Measurement The second file reduces alignment to three numbers and reads the same model in two inventory formats. ```js // enterprise/alignment.mjs — gap, overlap, orphan system; what two inventory formats see import { SYSTEM, CAPABILITY, COVERS, DATA, SYSTEMS, owner, edges } from "./model.mjs"; const col = (s, n) => String(s).padEnd(n); const owners = [...new Set(SYSTEMS.map(owner))].filter((o) => o !== "none"); const covering = (y) => SYSTEMS.filter((s) => COVERS[s].includes(y)); const E = edges(); const bidirectional = [...E.keys()].filter((k) => { const [a, b] = k.split("->"); return E.has(`${b}->${a}`) && a < b; }); const crossOwner = [...E.keys()].filter((k) => { const [a, b] = k.split("->"); return owner(a) !== owner(b); }); console.log(`MODEL enterprise: ${SYSTEMS.length} systems, ${owners.length} owners, ` + `${CAPABILITY.length} business capabilities, ${Object.keys(DATA).length} data assets`); console.log(`edges: ${E.size} directed edges, ${bidirectional.length} bidirectional, ` + `${crossOwner.length} cross an ownership boundary\n`); console.log(col("business capability", 24) + col("system", 8) + col("owner", 7) + "status"); console.log("-".repeat(60)); const status = (n, os) => (n === 0 ? "gap" : n === 1 ? "single" : os > 1 ? "overlap+conflict" : "overlap"); for (const y of CAPABILITY) { const k = covering(y); const os = new Set(k.map(owner)).size; console.log(col(y, 24) + col(k.length, 8) + col(os, 7) + status(k.length, os)); } const gap = CAPABILITY.filter((y) => covering(y).length === 0); const overlap = CAPABILITY.filter((y) => covering(y).length > 1); const conflict = overlap.filter((y) => new Set(covering(y).map(owner)).size > 1); const orphan = SYSTEMS.filter((s) => COVERS[s].length === 0); const settlement = overlap.reduce((t, y) => t + new Set(covering(y).map(owner)).size - 1, 0); console.log(`\ngap=${gap.length} (${gap.join(", ")})`); console.log(`overlap=${overlap.length}, ${conflict.length} of which are ownership conflicts`); console.log(`orphan system=${orphan.length} (${orphan.join(", ")})`); console.log(`alignment ratio = ${CAPABILITY.length - gap.length}/${CAPABILITY.length} = ` + `${(((CAPABILITY.length - gap.length) / CAPABILITY.length) * 100).toFixed(1)}%`); console.log(`settlements needed for overlapping capabilities = ${settlement}`); // ---- two inventory formats are derived from the same model ---- // A: system inventory — record unit is the system; capability names appear inside the system record // B: capability inventory — record unit is the capability; system names appear inside the capability record const finding = [...gap.map((y) => ["gap", y]), ...overlap.map((y) => ["overlap", y]), ...orphan.map((s) => ["orphan", s])]; const universeA = new Set(Object.values(COVERS).flat()); // A knows only the claimed capabilities const seesA = (t) => t !== "gap"; // an orphan system sits in A as an empty record const seesB = (t) => t !== "orphan"; // a capability record never names a system const countA = finding.filter(([t]) => seesA(t)).length; const countB = finding.filter(([t]) => seesB(t)).length; console.log(`\nsystem inventory A's capability universe: ${universeA.size}/${CAPABILITY.length} capabilities`); console.log(col("format", 24) + col("findings seen", 16) + "misses"); console.log("-".repeat(64)); console.log(col("A system inventory", 24) + col(`${countA}/${finding.length}`, 16) + `${gap.length} gaps`); console.log(col("B capability inventory", 24) + col(`${countB}/${finding.length}`, 16) + `${orphan.length} orphan systems`); console.log(col("enterprise model (A+B)", 24) + col(`${finding.length}/${finding.length}`, 16) + "-"); ``` ``` MODEL enterprise: 9 systems, 6 owners, 13 business capabilities, 10 data assets edges: 23 directed edges, 4 bidirectional, 20 cross an ownership boundary business capability system owner status ------------------------------------------------------------ material-search 2 2 overlap+conflict loan-issuance 2 2 overlap+conflict return-intake 2 2 overlap+conflict reservation 1 1 single membership-enrollment 1 1 single member-verification 2 2 overlap+conflict fee-calculation 1 1 single fee-collection 0 0 gap inter-branch-transfer 1 1 single asset-count 2 2 overlap+conflict usage-reporting 1 1 single purchase-suggestion 0 0 gap overdue-notification 2 1 overlap gap=2 (fee-collection, purchase-suggestion) overlap=6, 5 of which are ownership conflicts orphan system=1 (archive) alignment ratio = 11/13 = 84.6% settlements needed for overlapping capabilities = 5 system inventory A's capability universe: 11/13 capabilities format findings seen misses ---------------------------------------------------------------- A system inventory 7/9 2 gaps B capability inventory 8/9 1 orphan systems enterprise model (A+B) 9/9 - ``` ## The Three Numbers of Alignment Alignment is not one number but three separate numbers, and each says something different. A **gap** is a business capability no system covers. There are two in the model: fee collection and purchase suggestion. Both happen — fees are taken at the counter, purchase suggestions are collected on hand-kept lists — but neither appears in any system's record. A gap does not mean the work is not done; it means **the work is done outside any system**. In this model the alignment ratio is 11/13, or 84.6%. An **overlap** is a case where more than one system covers the same capability: there are six. Overlap itself is not a flaw; it is a requirement that both the kiosk and the loan service be able to issue a loan. What matters is **how many owners** the overlap spreads across. In five of the six overlaps the covering systems have different owners; these are **ownership conflicts**. Overdue notification is covered by two systems, but both are owned by the same unit, so a rule change is settled at a single table. In the other five, a rule change requires reconciling two separate budgets, two separate schedules, and two separate priorities. The settlement count in the model is five, and this number is the lower bound on the enterprise's coordination load. An **orphan system** is a system that cannot be tied to any capability: the archive. It has no owner either. An orphan system is not automatically something to shut down — reporting still reads the archive's record — but it is a line item with no defender: in a budget discussion, who will speak for it is unclear. The edge count sits on top of these three numbers. Across ten data assets, twenty-three directed edges emerge; four are bidirectional, and twenty cross an ownership boundary. That twenty of the twenty-three edges change owner puts a number on something at enterprise scale: integration is an organizational operation, not a technical one — in 87% of the edges, a change made by one party concerns another budget's owner. ## The Inventory's Format Determines the Finding The same model can be written in two formats. In the **system inventory**, the record unit is the system; each system's record lists the capabilities it covers. In the **capability inventory**, the record unit is the capability; each capability's record lists the systems that cover it. Both are written from the same model, but the set of findings they see is not the same. There are nine findings in the model in total: two gaps, six overlaps, one orphan system. The system inventory shows seven of them. What it cannot see is the gaps, because the system inventory's capability universe is derived from system records: of the thirteen capabilities, only eleven appear in any record at all, and the two that never appear are absent from the inventory. The capability inventory shows eight findings; what it cannot see is the orphan system, because a system whose name never appears in any capability's record never enters that inventory at all. Only the two-way mapping — the enterprise model — shows all nine. Enterprise architecture's first product is therefore not a list but a **mapping**: where the two lists fail to touch carries more information than either list on its own. ## Summary - Enterprise architecture's unit is not the deployment unit but the system with its own owner and its own budget; the model enterprise has 9 systems, 6 owners, 13 business capabilities, and 10 data assets. - Business–IT alignment is not one number but three: 2 gaps, 6 overlaps, 1 orphan system; alignment ratio 11/13 (84.6%). - The number of owners determines overlap's cost: 5 of the 6 overlaps spread across two separate owners and require 5 settlements in total; an overlap under the same owner is resolved at a single table. - The model enterprise has 23 directed edges; 4 are bidirectional and 20 cross an ownership boundary. - The system inventory shows 7 of the 9 findings, the capability inventory 8; all nine are read only from the mapping of both lists. ## Next Step This lesson built the enterprise model once and produced three numbers. How the model **should be documented** was never asked: how many layers it splits into, how many separate views it is written with, who reviews it and how often, and how much upkeep the document itself will demand are all still open. Enterprise architecture frameworks claim to answer exactly this question. The next lesson documents the same enterprise model in two framework formats — detailed-layered and lightweight — and counts how many questions each answers, how many items each requires to maintain, and when a framework's own maintenance cost exceeds the value of the question it answers.