The Enterprise Architecture Concept

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.

// 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.

// 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.