Enterprise Architecture Health Checklist

Organisation / domain: _______________ Date: _______

The test running through this list is not whether artefacts exist. It is whether anything would be decided differently without them.

1. Is the function affecting decisions?#

• [ ] Name three decisions in the last quarter that changed because of architecture input
• [ ] Architecture is consulted before a supplier is selected, not after
• [ ] Someone can say what the function is accountable for
• [ ] It has a route to say no, and has used it
• [ ] It has approved things quickly — a function that only says no is routed around

If the three decisions cannot be named, the function is producing documentation. That may be useful and it is not architecture.

2. Capabilities#

• [ ] A capability map exists — what the organisation does, not how it is organised
• [ ] Capabilities are stable across reorganisations
• [ ] Each capability maps to the applications supporting it
• [ ] Gaps identified: capabilities with no system, and capabilities with five
• [ ] Business owners recognise their own work in it

3. Application portfolio#

• [ ] A complete list exists, including what teams bought without telling anyone
• [ ] Each application has a named business owner and a technical owner
• [ ] Each is classified: invest / maintain / replace / retire
• [ ] Annual cost known per application
• [ ] Duplicates identified — the same capability in more than one system
• [ ] End-of-support dates recorded and monitored
• [ ] Anything unsupported is on a plan, not on a list

4. Data#

• [ ] One system of record per data domain — customer, product, order, employee
• [ ] Where copies exist, the direction of flow is documented
• [ ] Definitions agreed where they cross boundaries, with a named owner per definition
• [ ] Personal data mapped: where it is, where it goes, how long it stays
• [ ] Retention and deletion actually happen, including in copies and backups

Two dashboards disagreeing is nearly always two definitions, not two defects.

5. Integration#

• [ ] Integrations counted — most organisations underestimate by a wide margin
• [ ] Point-to-point links counted separately; they grow with the square of the systems
• [ ] Each integration has an owner
• [ ] Failure behaviour known: what happens when each link is down for an hour
• [ ] Undocumented links found — the file drop, the shared folder, the scheduled export

6. Standards#

• [ ] Standards exist and are short enough to be read
• [ ] Each says what problem it prevents
• [ ] Compliance measured, not assumed
• [ ] Exceptions recorded with an expiry date, not granted permanently
• [ ] Standards nobody follows are removed or enforced — never left in place ignored

7. Technology inventory#

• [ ] Languages, frameworks, databases and platforms in use, listed
• [ ] Versions recorded against their support dates
• [ ] Anything with one person who understands it — named as a risk
• [ ] New technology has a route in, so it arrives deliberately rather than accidentally
• [ ] Retirement happens — the inventory shrinks sometimes

8. Supplier and concentration risk#

• [ ] Critical suppliers identified
• [ ] For each: what happens if they fail, are acquired, or change their pricing
• [ ] Exit cost and exit time estimated for the top three
• [ ] Contractual notice periods known and diarised
• [ ] Concentration understood — how much rests on one supplier

9. Change#

• [ ] The roadmap shows what is being retired, not only what is being built
• [ ] Dependencies between programmes visible
• [ ] Sequencing accounts for shared systems
• [ ] Someone is accountable for the whole, not only for each part

10. The honest questions#

• [ ] Could a new engineer find out how something works without asking a specific person?
• [ ] Is the architecture documentation current, or current as of a project that ended?
• [ ] What is the oldest thing in production and who can still change it?
• [ ] What would a competitor's engineer say after two weeks here?

Sign-off#

Back to Enterprise Architecture