An enterprise architecture group publishes a 60-page reference model describing the target-state application landscape, with a conformance checklist. Two years on, four of nineteen teams have adopted it, the checklist is answered by copying last year's answers, and two teams built the same integration pattern independently. Review the artefact. What would you remove, what would you change, and what would you leave alone?
Show the full answer Hide the answer
What is actually required
Work backwards from the two failures. Teams built the same integration twice, which is a reuse failure: the model did not reach the moment a team was choosing. And conformance is answered by copy-paste, which means the checklist is measuring compliance paperwork rather than structure. A reference model exists to make the second team's decision cheaper than the first team's. Any part of it that does not serve that is overhead.
What I would remove
The target-state landscape. A 60-page description of where the estate should be in three years is a forecast, and the forecast is wrong from the month it is published. It is also the part that makes the document unreadable, which is why it is not read at the moment of choosing.
The conformance checklist in its current form. A questionnaire answered annually by the team being assessed produces the answer the team wants, costs real hours, and gives the architecture group false confidence. A control that nobody can fail is not a control. Two of nineteen teams adopting the model while every checklist comes back green is the measurement proving itself useless.
Every page that restates current structure. It decays fastest and has the least value, because anyone who needs it can read the code or the dependency graph.
The one change that matters
Replace the model with a short catalogue of agreed shapes, each with the conditions under which it applies and a working reference implementation. One page per shape: the problem it solves, the two or three decisions it has already made for you, when it does not apply, and a repository you can copy. "Synchronous request/reply over HTTP with this error contract" is a shape. "File-based batch intake with this manifest format" is a shape. Six shapes that teams actually copy beat nineteen chapters nobody opens.
Then move the conformance question from an annual form to the pipeline: a build check that the error contract is emitted, that the manifest validates, that the service registers in the catalogue. A rule that runs on every commit is answered by the code rather than by the team.
What I would leave alone, even though it looks odd
The vocabulary sections. The part of a reference model that reliably survives is the agreed names — what "tenant", "account", "entitlement" and "settlement" mean in this company. It looks like the least technical content in the document and it is the most durable, because it is what makes two teams' designs comparable at all. Keep it, and keep it short.
The existence of a central group that owns the shapes. The instinct after this review is to decentralise entirely. Teams will not maintain a shared catalogue as a side activity; somebody has to own it, write the reference implementations and retire shapes that stop being used. The failure here was the artefact's form, not the fact that it was owned.
How I would argue this in the review
Not as a criticism of the document. Bring the two duplicated integrations and ask one question: at the moment each team chose, what would they have had to read, and how long would it have taken? The answer is "60 pages, half a day", and the honest comparison is "one page and a repository to clone". Then commit to a number: 3 shapes published within a quarter, adoption measured by the pipeline check rather than by a survey, and the target-state chapter deleted.
When not to touch the model at all
If the model is an input to an external obligation, the critique above breaks something. A certification scope statement or a regulator's filing that cites the document by name makes it load-bearing for a reader who is not an engineer, and deleting chapters fails the next audit rather than improving delivery. Keep the cited sections, in a separate short document the audit reader owns, and rebuild the engineering artefact beside it.
Leave it alone too when the estate is genuinely uniform and small — under about 5 teams building the same kind of service, where the shapes are already obvious and the duplication you are trying to prevent costs 2 or 3 engineer-days a year. Industry reference models such as TOGAF's content framework or BIAN's service landscape have the same property: they pay when 20 teams need a shared vocabulary and cost more than they return when 4 do.