Term sheets

Architecture is the big-picture design of something complex: what the parts are, how they connect, and the rules that guide how it is designed and changes over time.

EA applies architecture to the whole organization (or a chosen part of it) — business, data, applications and technology together — so that change serves the strategy instead of adding more silos.

A short rule everyone agrees to follow when making architecture decisions — written down with why it matters and what it will cost to follow.

A ready-made structure — method, vocabulary, templates — that you tailor so that everyone does architecture the same way.

A domain is one “slice” of the enterprise you are designing. TOGAF's four main slices are business, data, applications and technology; topics such as security cut across all four.

A metamodel is a model of your models: it lists the kinds of things you will draw (roles, processes, applications, data…) and how they may be connected.

Anyone — a person, a team, a whole organization, or a class of them — who cares about the system.

The thing a stakeholder worries about or wants from the system.

One picture or model of the architecture, drawn for one audience's concerns.

The recipe for a type of view: who it is for, which concerns it answers, and how to draw it.

A building block described by what it must do, not by which product does it.

The actual product or component chosen to deliver an ABB.

A reusable piece of the enterprise — a process, application, data store or service — that can be combined with others.

The organized store where all architecture outputs live, split into eight sections.

A way of labelling every asset by how generic or how specific it is, so you can find and reuse the right one.

The set of architecture descriptions of what the enterprise has now and plans next, at different zoom levels.

A shelf of architectures ordered from “fits everyone” on the left to “fits only us” on the right. Look left for something reusable before designing from scratch.

The same left-to-right shelf, but for real solutions — products and built components — instead of architecture designs.

Cutting a big architecture into pieces that different teams can own and govern separately.

A formal, contracted work product that stakeholders review and sign off.

One list, grid or diagram that shows one aspect of the architecture.

A clear, checkable statement of something the solution must do or meet — if you can't test or measure it, it isn't a good requirement yet.

The one-page “elevator pitch” of where the architecture is going and why it's worth it — agreed early so everyone aims at the same outcome.

The signed “terms of engagement” for one ADM cycle: what will be done, how, by whom, by when, and how success will be judged.

The sponsor's formal “please start” note: why the work is needed, the goals, the limits and the budget — kept high level.

The main architecture “book” for a project: all the key catalogs, matrices and diagrams for every domain and every state, in one signed-off deliverable.

A signed agreement on what the architecture will deliver, to what quality, and how the parties will work together.

Checking that a project is actually building what the architecture says — and how closely.

The small group of senior people who own the architecture decisions, enforce compliance and grant exceptions.

The rules, people and processes that make sure architecture decisions are actually followed — and that exceptions are handled openly.

A formal, time-limited permission to be temporarily non-compliant, with conditions — not a permanent exemption.

The agreed description of how things are today — the starting point for change.

The agreed description of where you want to be.

A planned in-between state on the way from today to the target.

Comparing today with the target to list what must be added, what will be removed, and what stays.

A capability is something the organization can do — like “collect fees online” — regardless of which people, process or system does it.

A bundle of work that closes one or more gaps and delivers something the business wants.

The multi-year route map: which packages of work happen when, which in-between states you pass through, and what value each step brings.

How well processes, information and systems can work together and share with each other.