IT‑IS‑Networking
Technology › Enterprise Architecture & Governance

Enterprise Architecture

The discipline of placing technology correctly in a business's data flows, risk posture and cost structure — the through-line of the last two decades.

Also known as EA

Left to right is time. Each row is one of the 14 disciplines this one worked alongside, ordered so kindred disciplines sit next to each other rather than alphabetically — a landscape only means anything if neighboring rows belong together. Height is the work running in that domain in that year, weighted by what failure would have cost — life-safety ×3, a statutory obligation ×2.2, the estate itself ×1.5, an evaluation ×1. Every project declares which of those it was, so each ridge traces to an entry you can open and disagree with. Only the work that used this technology is counted, so what shows here is the company it kept rather than the record around it. Height and color are on the record-wide scale rather than this page’s own, so a modest estate draws a modest landscape and any two of these pages can be read against each other.

The working definition used throughout this record is that the role sits on both sides of a fence: deep enough in the technology to make real decisions about it, and close enough to the business to know which decisions matter.

Nineteen years of it were practiced in an unusually hard setting — a consolidated city-county government where five constitutional officers elected independently of the Mayor (Sheriff, Clerk of the Circuit Court, Property Appraiser, Tax Collector, Supervisor of Elections), two state officers elected for the judicial circuit (State Attorney, Public Defender), a separate judicial branch, and several City departments with budgets of their own each ran technology of their own — while a charter gave the City’s technology division a governance role across all of it, the independent authorities aside, and every one of the rest had some part of its estate on shared infrastructure. Nothing published could be mandated. Every standard that took hold was adopted voluntarily by people free to decline it, which is a considerably better test of an architecture than compliance.

The program itself was built as well as practiced: creating and maintaining the enterprise architecture function, balancing business, information, technical and solution architecture viewpoints, and establishing the governing principles that guided solution decisions across it. What came out of that were repeatable technology patterns the engineering and operations groups designed and deployed against — chosen to minimize total cost of ownership rather than to be interesting.

The constant has never been a platform. Drafting and object databases, SQL, medical imaging and DOCSIS, routed networks and a CCIE, data center, cloud, and now post-quantum cryptography. What has not changed is taking something unfamiliar, working out what it does, and placing it correctly.

Also searched as

  • TOGAF
  • architecture decision record
  • ADR
  • reference architecture
  • architecture repository
  • target state
  • business architecture
  • business capability model
  • BIZBOK
  • capability-based planning
  • value stream