During a technology health check there is a moment that tells the reviewer a great deal. They ask for the current architecture of the system in scope, and somebody sends a link to a shared folder. Inside are a few hundred files: slide decks, exported diagrams, a spreadsheet of applications last updated by someone who left, and several documents with "final" in the file name.
Nobody in the room is surprised, and nobody is being careless. The folder is what happens when architecture is treated as a set of documents produced for projects and governance meetings, rather than as information the organisation manages over time. Documents accumulate. Information decays. By the time an incident or an audit needs a trustworthy answer, the folder can say what someone once intended but not what is true now.
Cedarberg Logistics is fictional, and its systems and figures are illustrative. When its health check asked how the telematics platform connected to the transport management system, the architecture folder held three diagrams of that integration. They disagreed with each other, and all three disagreed with the configuration the review found running. The newest was two years old.
Why a folder fails at exactly the wrong moment
A folder has no rules. It does not say what kinds of thing should be recorded, who owns each one, when it should be reviewed or how a change is approved. So every question a reviewer, an incident manager or an investment committee asks has to be answered by finding a person who remembers.
Cedarberg's folder held 340 files. The review found no owner recorded for any of them, six documents calling themselves the final integration design, no link from any diagram to the decision that produced it, and no way to tell when anything had last been checked against reality. The folder was not wrong in any single place. It was untrustworthy as a whole, which in an audit amounts to the same thing.
What makes a repository a management system
An architecture repository earns the name when it behaves like any other management system: it has a defined scope, defined content, owners, a review cycle and a controlled way to change. The TOGAF Standard, now in its 10th Edition from The Open Group, describes an Architecture Repository in these terms, holding the architecture metamodel, descriptions of the current and target landscape, reference material, standards, requirements and governance records. You do not need to adopt TOGAF to borrow the idea, and TOGAF, CAF and WAF without the framework theatre explains how to take what is useful from a framework without the ceremony. You do need to stop treating the repository as storage.
Five properties separate the two.
1. A metamodel says what you record
The metamodel is the list of entity types the repository holds and how they relate. Without it, every architect records different things in different ways, and nothing can be queried. With it, the repository can answer questions such as "which capabilities depend on this application?" or "which interfaces expose personal information?"
A useful starting metamodel is small. Cedarberg began with nine entity types.
Capabilities are realised by business processes, which use applications. Applications store data objects, expose interfaces and run on technology. Every application has an accountable owner. Decision records justify why an application or interface exists in its current form. Standards constrain the technology choices.
That is enough to answer most audit questions. It is deliberately not everything. A metamodel that tries to describe every possible relationship on day one will never be populated, and an unpopulated metamodel is a folder with extra steps.
2. Every entry has an owner and a review date
Ownership is what keeps information alive. Each application, interface and standard needs a named owner who confirms, on a set cycle, that the entry still matches reality. Cedarberg set the cycle at six months for production systems and at every major change for anything in scope of a customer service level.
3. Decisions are linked, not filed separately
The most valuable thing in a repository is not the diagram. It is the reasoning. When Cedarberg's integration was built as a nightly file transfer, that was a reasonable decision for a vegetable distributor. Nobody recorded it, so nobody revisited it when the company started selling five-minute temperature evidence to pharmaceutical customers. A short architecture decision record, linked to the interface it governs, would have carried the assumption ("readings needed next day") that the later sales decision quietly broke. This is the argument of The architecture is not the diagram, applied to the repository.
4. Standards and building blocks are reusable
A repository should hold the organisation's approved patterns and building blocks: the standard way to integrate with a vendor platform, the standard alerting rule set, the approved hosting options. Reuse is where the repository starts paying for itself. Cedarberg's missing-data alert, once designed, became a building block applied to every vendor data feed, not a one-off fix.
5. Change goes through review
A change to a production architecture should update the repository as part of the change, not as a documentation task afterwards. The simplest workable rule: a change is not done until the affected repository entries are updated and the owner has confirmed them. That rule costs minutes per change and saves weeks per audit.
Views come out of the repository, not into it
Once the information is managed, diagrams become views generated or drawn from it for a particular audience and question, as described in architecture layers and purposeful views. A diagram drawn for a board pack and a diagram drawn for an integration engineer can then disagree in level of detail without disagreeing about the facts.
This also changes how a health check works. Instead of asking people to remember, the reviewer can test the repository against evidence: sample ten interfaces, compare the recorded configuration with the running one, and report the match rate. A repository that is 90% accurate on a sample is a far stronger control than any number of polished diagrams.
Roles and governance without bureaucracy
A repository needs three roles, which in a small organisation may be the same few people:
| Role | Responsibility | Cedarberg example |
|---|---|---|
| Repository owner | Keeps the metamodel, tooling and review cycle running | Enterprise architect, part time |
| Entry owners | Confirm their entries match reality on cycle | System owners for each application |
| Architecture review | Approves changes to standards and significant designs | Monthly forum, chaired by the CIO |
The governance should be proportionate. A weekly board that approves every diagram will be bypassed within a quarter. A monthly review of standards and significant decisions, plus the rule that changes update the repository, is enough for an organisation of Cedarberg's size.
Tooling is the last decision
Teams often start by buying an enterprise architecture tool. Some of those tools are good. None of them fixes missing ownership, an undefined metamodel or a change process that ignores the repository. Cedarberg started with a structured list in its existing collaboration platform, one page per entity, a mandatory owner field and a review-date field, plus decision records stored alongside. It will reconsider tooling once the content is being maintained, because only then will it know what it needs a tool to do.
A test for your own repository
Pick one production interface at random and try to answer four questions from the repository alone: what it connects, who owns it, why it was designed this way, and when someone last confirmed that the record matches reality. If you can answer all four, you have a management system. If you need to find a person, you have a folder.
Next: Part 4, What belongs inside an independent technology assurance review. All parts are on the series page.
How CloudNala can help
We help organisations turn an architecture folder into a working repository: a small metamodel, owners and review cycles, linked decision records and a change rule that keeps it current. We start with the systems that matter most to an audit or a customer commitment, so the repository proves its value on real questions before anyone invests in a tool.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Technology Health Check or write to us at consult@cloudnala.co.za