⏱ 24 min read
There is usually a point when an architecture team realizes it does not really have a repository problem in the abstract. It has a memory problem. And very quickly after that, a governance problem. architecture decision records
In the bank I’m using for this case, that point arrived during a fairly miserable quarter when two large initiatives collided.
One was a regulatory remediation program focused on customer data controls, consent lineage, and resilience evidence. The other was a digital onboarding initiative with aggressive time-to-market targets, heavy API integration, and a lot of pressure from product leadership to “not let architecture slow this down.”
On paper, both programs were aligned to enterprise architecture. Sparx EA performance optimization
In practice, three different “approved” customer data models were in circulation. One sat in a SharePoint site maintained by data architecture. Another lived in a PowerPoint deck from a transformation program that had ended 18 months earlier but was still being cited in design reviews. A third was buried in a Jira attachment from a customer platform squad and had somehow picked up an aura of legitimacy because a senior architect had commented on it once.
At the same time, two architecture decks contained two different security patterns for service-to-service authentication. One mandated mutual TLS end to end. The other routed everything through an API mediation layer with token exchange and centralized policy enforcement. Both had been “approved” in some fashion. No one could quickly tell you which one applied in which context, whether one had superseded the other, or what exception history sat behind them.
And then there were target architectures. They existed everywhere and nowhere at once: SharePoint libraries, Teams folders, Confluence pages, individual desktops, PDF packs attached to governance tickets, and one infamous personal folder whose owner had left six months earlier.
That sort of mess is bad in any enterprise. In banking, it gets expensive quickly.
Banks operate under a level of scrutiny that changes the meaning of architectural ambiguity. If a retailer has two inconsistent integration patterns, it may suffer delivery inefficiency. If a bank has two inconsistent control implementations across critical customer journeys, it can end up with audit findings, regulatory questions, risk committee escalations, and remediation costs that dwarf the original architecture investment.
That is why I think many organizations misunderstand the TOGAF Architecture Repository. They treat it as a documentation library, or worse, a dumping ground for architecture artifacts. It is neither. In a regulated bank, a serious repository becomes a control point: for architectural memory, for decision traceability, and for executing change without relying on whoever happens to remember last year’s review outcome.
That may sound lofty. It isn’t. It’s practical. Either your standards, patterns, target states, and exceptions connect in a dependable way, or your delivery organization starts improvising.
And banks are remarkably good at improvising themselves into trouble.
The bank in this case
The example here is a mid-to-large retail and commercial bank operating across several countries, with a mix of legacy core platforms, modern digital channels, outsourced services, and a cloud program that was far enough along to create real complexity but nowhere near far enough along to simplify anything.
Typical enough, honestly.
It served both retail and SME customers, had acquired two regional institutions over the years, and was subject to the usual stack of scrutiny: internal audit, external audit, privacy regulators, operational resilience oversight, outsourcing controls, model risk in some analytics domains, and the ever-present security and risk committees.
The architecture team was not weak. That matters. This was not a case of no standards, no methods, no governance. Quite the opposite. The bank had plenty of architecture content.
That was exactly the problem.
There were duplicate reference architectures for API exposure. Multiple standards documents existed, but people could not find the current one without asking around. Solution architects kept reinterpreting policy every quarter because the translation from policy to architecture pattern was scattered and often undocumented. Roadmaps looked tidy in strategy presentations but had very little operational connection to transition architectures that delivery teams could actually use.
Meanwhile, delivery leads were pressing hard. They wanted quick architecture decisions, especially for cloud adoption, Kafka-based eventing, IAM modernization, and customer journey redesign. Risk and compliance functions had become less patient with slideware. They wanted evidence. Show me the approved pattern. Show me the exception. Show me the review date. Show me who accepted the risk. Show me what changed.
The merger history made all of this worse. Different business units used different vocabulary for the same thing. One area called something a “customer domain service.” Another called it a “mastering hub.” A third called it “golden source API.” Those may sound like semantics. In repositories, semantics turn operational very quickly. If people cannot classify architecture content consistently, they cannot retrieve or govern it consistently either.
So before anyone formally talked about “implementing the TOGAF Architecture Repository,” the bank already had the pain repository discipline is meant to address. TOGAF training
What went wrong when there wasn’t a real repository
A few examples make this clearer than any formal definition.
Payments modernization
One payments program adopted event streaming for payment status propagation and reconciliation triggers. It used Kafka, built a sensible event taxonomy, and aligned to the architecture team’s stated preference for more decoupled integration. Good work, broadly speaking.
At the same time, another team in a related payments stream approved a batch-based reconciliation architecture because it was faster to implement against a legacy ledger platform and had precedent in an earlier program.
Both teams claimed alignment with enterprise standards.
That was not dishonesty. It was a discoverability failure. One team had found a reference pattern for event-driven integration. The other had found an older integration standard and an exception memo that had drifted away from its original context. No one had a clean way to see what was current, what was transitional, and what had been waived only for a narrow scenario.
Later, audit identified inconsistent control implementation around replay handling, monitoring, and reconciliation timing. Predictable in hindsight, if we’re being honest.
Customer identity and consent
The bank had approved a target-state set of principles for customer identity, authentication, and consent management. Central IAM and privacy teams had done thoughtful work. The issue was that implementation teams could not reliably locate the canonical patterns or the approved waivers.
So every major program repeated the same debates: where consent metadata should live, how identity federation should work with third-party channels, whether support users needed a separate zero-trust access pattern, how token claims should map to consent scopes.
Architects were re-solving problems that should have been reusable.
That is not architecture maturity. It is institutional amnesia with expensive salaries attached.
Cloud landing zone exception
A cloud landing zone exception had been approved for a legitimate business reason: one program needed a temporary deviation from the standard network segmentation model to accommodate a migration dependency and a vendor timetable. The exception had compensating controls. It had a sunset expectation. It was not crazy.
But because the exception was recorded in a way that was hard to find formally and easy to copy informally, it spread. Teams mentioned it in chats, pasted diagrams into decks, and cited it in reviews as though it were now the standard. In less than a year, a local exception had become “what we do in the cloud” by rumor.
This is exactly where the TOGAF repository matters. ArchiMate in TOGAF
Not in theory. In the very mundane, very critical work of stopping organizations from forgetting the difference between a standard, a pattern, a transition state, and a one-off waiver.
What TOGAF means by “Architecture Repository” in plain English
Strip away the jargon and the Architecture Repository is simply the organized body of architecture knowledge you use to guide and govern change.
That sounds obvious. It is not how many firms actually operate.
A real repository is where people go to answer practical questions:
- What is the approved standard here?
- What reusable pattern already exists?
- What target state are we actually moving toward?
- What exception has been granted, to whom, and until when?
- What decision was made, and why?
It is not just a CMDB. A CMDB tells you about operational configuration items and relationships in service management terms. Useful, but different.
It is not merely a document management site. SharePoint full of PDFs is not an architecture repository unless the content is curated, classified, related, governed, and trusted.
It is not the same thing as an application portfolio tool, though there may be overlap.
And it absolutely should not become a graveyard of old architecture packs.
Chief architects should care because the repository is what turns architecture from presentation into operational discipline. Decisions become reusable. Standards become enforceable rather than decorative. Target states can be linked to what delivery is actually building. And when regulators or auditors ask for lineage from policy to design to implementation choice, you have something better than reconstructed email trails.
TOGAF separates repository content areas for a reason. Standards are not the same as reference architectures. Governance records are not the same as landscapes. Methods and capability are not the same as content. In practice, that separation helps you avoid one of the most common enterprise mistakes: throwing everything into one bucket and then wondering why no one trusts it.
The repository parts, in the order the bank actually cared about them
Textbooks usually walk through repository components in a neat sequence. Real organizations rarely do. This bank started where the pain was sharpest.
Architecture Standards Information Base
This was the first area the bank tightened because it needed control quickly.
The contents were not glamorous:
- approved integration standards
- encryption and key management standards
- resilience patterns for critical services
- identity federation standards
- cloud service usage constraints by data classification
One useful example was the standard for protecting customer PII in motion and at rest. In a weak architecture function, that would just be a PDF saying “encrypt sensitive data.”
In the repository, the bank made it much more usable. The standard linked to:
- the underlying policy requirement
- the relevant control objective
- implementation patterns for APIs, Kafka topics, object stores, and databases
- approved product options, including specific KMS and HSM-aligned services
- known exceptions and their status
That last point matters. If standards have no visible relationship to exceptions, teams either assume the standard is unrealistically rigid or assume exceptions are arbitrary. Neither is healthy.
A common mistake here is publishing standards as static documents with no lifecycle state, no named owner, no review date, and no linkage to waivers. In my experience, once that happens, “approved” becomes a historical adjective rather than a current fact.
Reference Library
This became the most-used part of the repository surprisingly quickly.
Why? Because solution architects do not wake up wanting standards. They wake up wanting workable patterns.
The Reference Library held things like:
- an open banking reference architecture for partner-facing APIs
- an event-driven architecture pattern for fraud detection using Kafka
- a zero-trust access pattern for third-party support users
- a data retention reference model for customer communications
- a canonical approach for API mediation between digital channels and core platforms
This is where a lot of architecture teams either become genuinely useful or drift into abstraction.
A reference architecture is not a standard. It says, “Here is a proven way to structure this class of problem.” It provides guidance, building blocks, options, constraints, and trade-offs. Standards say what is approved or required. Reference architectures show how a solution can coherently come together within those rules.
One bank I worked with years ago made the mistake of treating vendor diagrams as enterprise reference architectures. That always ends badly. Vendor material can be helpful input, but it is not your enterprise pattern unless you have contextualized it for your controls, data classifications, operating model, and integration reality.
This bank learned that lesson fairly quickly.
Governance Log
Ignored until auditors arrive. Then suddenly everyone cares.
The Governance Log was where the bank stored architecture decisions, review outcomes, waivers, expiry dates, rationale for non-standard technology choices, and links to risk acceptance where relevant.
A very practical example: one program received temporary approval to use a managed cloud database service that did not yet meet the full cross-region failover expectation for a critical service class. The approval was not hidden in meeting minutes. It was recorded with:
- the exact scope of the exception
- the business rationale
- compensating controls
- review and retirement date
- associated risk acceptance
- the intended target-state alignment path
That kind of record becomes invaluable later. Not just for audit. For the next architect trying to work out whether the exception applies to them. Usually it doesn’t.
If exceptions are hard to find, they spread informally. I have seen that too many times. In regulated firms especially, a repository without a usable governance log is little more than a decorative archive.
Architecture Landscape
This is the hardest part to keep honest.
The landscape contains current, transition, and target views across business, data, application, and technology. In the bank’s case, it included:
- current-state payments application landscape
- transition architecture for core banking decoupling
- target-state customer master data services across retail and commercial banking
- key technology domain views for IAM, integration, and cloud foundation
The temptation is to model everything.
Don’t.
That way lies a six-month modeling exercise followed by abandonment.
The useful landscape is selective. It captures enough to inform investment, dependencies, target-state decisions, and governance. It does not attempt a full-fidelity digital twin of the enterprise unless you have extraordinary discipline and a very strong operating model.
For this bank, the transition architecture views were arguably more valuable than the pure target-state ones. Delivery teams needed to know what coexistence looked like: which legacy customer systems remained authoritative for which data sets during migration, where API mediation insulated channels from core changes, what event contracts were transitional, where temporary duplication existed by design.
That is where architecture earns its keep.
Architecture Metamodel
Most delivery teams initially thought this was abstract nonsense. Then it solved reporting chaos, and attitudes improved.
The bank used the metamodel to define what counted as:
- a business capability
- an application
- an interface
- a data entity
- a control
- a standard
- an exception
And, crucially, how those things related.
So “Customer Onboarding Capability” could be linked to:
- the applications supporting it
- the core data entities involved
- the architecture standards that applied
- specific controls for privacy and authentication
- active exceptions affecting the journey
- target and transition architecture views
Without that kind of structure, reporting becomes an argument about vocabulary every time. With it, you can answer questions like, “Which customer-facing services handling confidential data are still dependent on a legacy IAM pattern under waiver?” That is the kind of question banks increasingly need to answer.
My strong view is that if the metamodel is left to tooling teams alone, it usually becomes unusable bureaucracy. It has to be designed by people who understand architecture decisions in practice, not just schema design.
Architecture Capability
This is the bit people skip because it feels less tangible. It may be the most important part.
The repository is only as useful as the operating model around it. So the bank had to define:
- roles
- review forums
- content stewardship
- repository ownership
- quality checks
- integration points with delivery lifecycle
And it had to accept a basic truth: the central architecture office could not maintain all content on its own.
Domain ownership mattered. Security architecture owned certain standards. Data architecture stewarded canonical models and related reference content. Platform architecture owned cloud foundation patterns. Domain architects maintained specific landscapes. Governance support maintained review records and waivers with discipline.
Without that distributed stewardship model, the repository would have decayed within months.
A practical view of what lives where
How it actually got implemented
Not elegantly.
That is worth saying, because too many architecture write-ups imply there was a clean design from the beginning. There wasn’t.
Phase 1: regulatory pressure forced a start
The first usable repository was built around standards, exceptions, and target-state artifacts. That was it.
The bank kept tooling ambition deliberately modest. It needed a controlled place for approved content, review records, and basic traceability more than it needed a perfect enterprise model. In my view, that was the right call.
Phase 2: delivery friction expanded the scope
Then solution and domain architects pushed for reusable patterns because they were tired of reinventing architecture for APIs, event streams, IAM federation, and cloud deployment guardrails.
That pressure grew the Reference Library. Frankly, it made the repository more popular than governance alone ever would have.
Phase 3: rationalization
This was painful and overdue.
Duplicate content was archived. Lifecycle states were introduced: draft, candidate, approved, deprecated, retired. Ownership was made explicit. Review dates became mandatory. Old imported material was either curated or removed.
And, most importantly, architecture review processes started requiring repository references. If a solution claimed alignment to a standard, it cited the standard ID. If it used a reference pattern, it linked the pattern record. If it deviated, the deviation went into a governance record.
That was the point where the repository stopped being optional.
Phase 4: evidence-grade maturity
Later, the bank linked repository content more clearly to control frameworks, added audit-ready change history, tightened permissions for sensitive architecture content, and established review cadence by content type.
This mattered because in banking, evidence quality becomes part of architecture credibility. If your architecture content cannot survive audit scrutiny, its practical authority drops.
Honest truth: the first version was messy. Too much imported content. Not enough curation. Some landscape diagrams were too detailed to maintain. The metamodel started too broad. That is normal. Better a messy repository that is actively used and improved than a pristine one no delivery team touches.
What it looked like in one initiative: digital mortgage origination
This is where the repository moved from theory to real value.
The bank launched a digital mortgage origination program to reduce approval times, improve customer experience, and still meet conduct, affordability, and data-handling obligations. This involved digital document ingestion, OCR, underwriting workflow integration, customer status updates, and coexistence with a legacy core lending platform.
The program did not start with a blank sheet.
Architects pulled from the repository in a sequence that became fairly standard:
First, standards.
They checked the approved integration standard for event publication, the data classification rules for income and employment data, the IAM standards for customer and colleague access separation, and the encryption standard for sensitive documents and metadata.
Then, reference patterns.
They reused a document ingestion and OCR reference architecture, an API mediation pattern separating digital channels from core lending services, and an event-driven pattern for status updates to customer channels.
Then, landscape alignment.
They reviewed the transition architecture showing coexistence with the core lending platform and the target-state view for customer master data services. That mattered because mortgage origination needed customer and consent data from shared services but still depended on legacy lending records for some decisioning.
Then, governance.
A temporary exception was logged for continued use of a legacy document archive because migration of historic mortgage packs would not complete in the first release. The exception linked compensating controls, a sunset date, and a dependency on the archive retirement roadmap.
That sounds procedural. It was actually liberating.
Instead of spending architecture review meetings arguing from memory, teams could point to repository assets and focus on real trade-offs:
- Should status updates be emitted as domain events on Kafka or exposed synchronously to channels via APIs only?
- Could the OCR service process confidential income documents in a managed cloud service, given data residency constraints?
- Where should retention rules be enforced: in the document store, the content management layer, or downstream archival controls?
- How much logic should the API mediation layer absorb versus pushing into the lending orchestration service?
Those are useful debates.
The resulting architecture used event-driven status updates to customer channels, an encrypted document store with retention rules tied to mortgage case states, and an API mediation layer that insulated the digital front end from the core lending services. IAM patterns ensured internal underwriters, brokers, and customers were handled distinctly. Kafka was used where asynchronous process state changes made sense, but not forced everywhere. That last part matters. Reusable reference patterns should not become ideological weapons.
The outcome was not miraculous. But it was materially better:
- faster review cycles
- fewer repeated arguments
- cleaner traceability from design to standards and exceptions
- much stronger audit trail
That is what a good repository does. It lowers friction without lowering control.
The mistakes that almost ruined it
A few of these are painfully common.
One was treating repository population as a one-time migration project. Teams dumped content in, declared success, and moved on. Repositories die that way.
Another was allowing every architecture artifact into the repository. If everything is preserved equally, nothing is trusted equally. Quality thresholds matter.
The bank also initially failed to distinguish clearly between approved standards, candidate patterns, and historic references. That caused confusion and, in a few cases, accidental non-compliance. Lifecycle state needs to be visible at a glance.
There was too much taxonomy work before enough practical use cases were agreed. I see this a lot. Teams spend months debating classifications while solution architects still cannot answer basic questions like whether a technology is approved for confidential data.
Waivers had no reliable expiry discipline early on. Predictably, they lingered.
The repository also skewed too much toward enterprise architecture consumption at first. It made sense to the central team but was awkward for solution architects under delivery pressure. That is a fatal design flaw. If your most frequent users find the repository painful, they will route around it. Sparx EA guide
And no, a tool did not solve this. Tools helped with versioning, metadata, permissions, and relationships. But no platform creates stewardship discipline on its own.
Finally, the politics were real. Security, data, infrastructure, and business architecture each had ownership concerns. In regulated firms, there is also a subtle but important confusion between policy evidence and architecture evidence. They overlap, but they are not the same. A policy library proves intent and formal requirement. An architecture repository shows how that intent is translated into standards, patterns, target states, and governed deviations.
Mix those up and audits get messy.
How to design it so delivery teams will actually use it
Start with user journeys, not TOGAF labels.
A solution architect is usually trying to answer something immediate:
- I need the approved pattern for exposing an internal service.
- I need to know whether this cloud database is allowed for confidential data.
- I need the latest target state for payments.
- I need to see active waivers that affect my design.
Design the repository around that reality.
A few choices made a huge difference in the bank:
- strong search and tagging
- visible lifecycle status on every item
- owner and review date mandatory
- links between standards, patterns, decisions, and landscapes
- lightweight submission and update workflow
The architecture review checklist then referenced repository items directly. Project teams cited repository IDs in solution designs. Exceptions were captured once and reused in audit and reporting.
That sounds procedural again, but it reduced waste.
My opinion, bluntly: if architects have to explain where everything is every single time, the repository has already failed.
Here’s a simple view of the flow:
And the relationship model that made the repository genuinely useful looked roughly like this:
Nothing revolutionary. Just disciplined.
Tooling: what mattered and what didn’t
I would avoid turning this into a product debate because that usually misses the point.
What mattered:
- traceability
- permissions
- searchable metadata
- versioning
- relationship modeling
- integration with portfolio and change processes
- decent audit history
What mattered less than many teams assume:
- polished diagram rendering
- notation purity
- buying something marketed as “TOGAF-aligned”
Banks often end up with a hybrid: an EA tool for modeled relationships and landscapes, a document repository for controlled artifacts, and a governance workflow platform for review records and exceptions. That is completely acceptable if ownership is clear and the user experience is coherent enough.
Banking-specific needs do raise the bar a bit. Segregation of duties matters. Audit logs matter. Retention rules matter. Access controls for sensitive architecture content matter, especially for security, resilience, and outsourcing-related designs.
But still, operating discipline beats tool branding every time.
Repository versus other enterprise records
This distinction is worth making because many organizations blur it.
The architecture repository is not:
- the CMDB
- the application portfolio repository
- the control library
- the data catalog
- the policy library
- the records management system
There are overlaps and handoffs.
For example, an architecture standard may reference a control requirement, but it does not replace the formal control test procedure. A target application landscape may reference systems of record, but it does not replace the operational inventory used by IT service management. A data reference model may relate to the data catalog, but it does not replace detailed metadata stewardship.
In audits and transformation programs, this distinction matters. If you cannot explain what each repository of record is for, people start using the wrong source for the wrong question.
What good looked like after 18 months
Not perfection. Better than that: reliability.
Standards were cited consistently in solution designs. Duplicate patterns had been retired. Waivers were visible and time-bounded. Target and transition architectures were linked to funded roadmaps rather than floating separately in strategy decks. Architecture review cycle time dropped because baseline materials no longer had to be rebuilt every time.
Audit requests got answered with evidence instead of reconstruction.
The less obvious signs were just as important. There were fewer philosophical debates. Domain architects spent less time recreating standard material. Discussions shifted toward actual trade-offs: latency versus control centralization, resilience versus cost, migration speed versus target-state purity.
The bank also saw concrete benefits:
- cleaner cloud exception management
- more consistent resilience design across critical customer journeys
- stronger traceability from customer data principles to implemented services
- fewer “approved by rumor” patterns in Kafka, IAM, and API designs
That last one may be my favorite metric, unofficial though it is.
Practical guidance for chief architects setting this up now
A few lessons, hard-earned.
Decide first which decisions need to be reusable. Build repository content around those decisions, not around an abstract framework diagram.
Make standards and exceptions first-class citizens early. In regulated firms, those are where a lot of operational architecture credibility comes from.
Keep landscape detail limited to what informs investment, dependency management, and governance. Do not model for the sake of modeling.
Define ownership before selecting tools. If no one is accountable for content quality and review cadence, the platform choice is almost irrelevant.
Use transition architectures aggressively. They are the bridge between strategy and delivery, especially in banks with long-lived legacy coexistence.
Create retirement rules for stale content. Historic material has value, but only when clearly marked as historic.
And review repository usefulness with solution architects every quarter. Not just architecture purity. Actual usefulness.
In regulated settings, design for evidence and lineage from day one. But resist the temptation to turn the repository into a compliance warehouse. Its job is to support architectural decision-making and governed change, not to absorb every enterprise record.
The central lesson
Back to that opening mess: conflicting customer data models, inconsistent security patterns, target architectures scattered across folders, and too much architecture authority resting on memory and personality.
The repository did not solve architecture by itself. No repository does.
What it did do was reduce ambiguity, preserve decisions, and make governance operational. It gave the bank a place where standards, patterns, landscapes, and exceptions connected well enough that people could act with confidence instead of improvising from fragments.
That is really the point.
In a bank, the TOGAF Architecture Repository earns its keep when it stops being a library and becomes a decision system. Not perfect. Never perfect. But reliable enough that change no longer depends on who happens to remember the last approved answer.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.