Most technology decisions at a bank don’t fail because of bad engineering. They fail because Product, Risk, Operations, and IT are working from different mental models of what the bank actually runs, what’s changing, and why.

Nobody owns the shared picture. Welcome to the gap.

The Problem Nobody Talks About

There’s a particular kind of bank that falls through the cracks of enterprise architecture advice. You’re not JPMorgan with a massive EA function and an ArchiMate repository. But you’re not a two-branch community bank skating by on spreadsheets and good intentions either.

You’re somewhere in the middle—running core banking systems, managing payment rails, integrating with third-party providers across multiple channels. And increasingly, the people inside your own organization are asking each other the same questions: What do we actually run? What’s changing? Why did we build it this way? Who agreed to this? Product can’t plan a roadmap without understanding the technology landscape. Risk can’t assess exposure without knowing what’s connected to what. Engineering can’t make consistent choices without a shared frame of reference.

The regulatory dimension makes it more urgent. The FFIEC’s Architecture, Infrastructure, and Operations booklet (2021) explicitly evaluates enterprise-wide IT architectural planning. DORA requires documented ICT risk management frameworks, asset inventories, and dependency mapping. But regulators aren’t the primary reason to care—they’re just the external force that penalizes the same misalignment your teams already feel internally.

I’ve written before about the compliance tax—the accumulated friction of operating in a regulated environment. This is the architectural version of that same problem. The overhead isn’t in the doing. It’s in getting everyone to see the same picture.

Full TOGAF implementation? Multi-year, multi-million-dollar commitment. It presumes you already have the team, the tooling, the governance structures, and the organizational appetite for a comprehensive EA program. TOGAF’s content framework defines dozens of catalogs, matrices, and diagrams across every ADM phase. It’s thorough. It’s rigorous. And for a bank that needs departments aligned on technology this quarter, it’s paralyzing.

You need the outcomes of enterprise architecture without the overhead of an enterprise architecture practice.

The Pragmatic Thesis: Five Artifacts That Actually Matter

Here’s the argument: you can answer 80% of the questions that stall decisions across departments—and satisfy most of what regulators ask for as a bonus—with five well-maintained artifacts. Not fifty. Five.

These aren’t theoretical. They’re borrowed from TOGAF’s vocabulary, from the ADR community, and from the real experience of watching cross-functional conversations grind to a halt because nobody has a shared, authoritative source of truth. They’re chosen because they answer the questions that actually get asked—by your own teams first, and by examiners second:

1. Architecture Decision Records (ADRs) — Why did we build it this way?
2. Application Portfolio Catalog — What do we actually run?
3. Technology Portfolio Catalog (Tech Radar) — What’s current, what’s dying, what’s next?
4. Architecture Contracts (Lightweight) — Who agreed to what?
5. Data Entity / Data Flow Inventory — Where does sensitive data live and move?

Let me go deep on each one.

1. Architecture Decision Records: The Most Valuable Artifact You’re Not Producing

An ADR is a short document—often a single page—that captures one significant architectural decision, its context, the alternatives considered, and the consequences. Michael Nygard introduced the concept on the Cognitect blog in November 2011. Since then, ThoughtWorks placed it in the “Adopt” ring of their Technology Radar in 2018, AWS published it as prescriptive guidance, and Microsoft integrated it into the Azure Well-Architected Framework.

Why does this matter for internal alignment? Every planning conversation, every vendor evaluation, every incident retrospective eventually arrives at the same question: “Why is our system designed this way?” Without ADRs, the answer lives in someone’s head—someone who may have left the company, or whose memory of a decision made three years ago is unreliable at best. ADRs turn tribal knowledge into institutional knowledge. They also happen to answer the first question any auditor asks.

The minimum template:

# ADR-[NUMBER]: [TITLE]
## Date: [YYYY-MM-DD]
## Status: [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context
What forces are at play? What regulatory requirement, business need,
or technical constraint is driving this decision?

## Decision
We will [concrete action]. State it in active voice.

## Consequences
What happens as a result? Include positive, negative, and neutral impacts.
List any new constraints this creates for future decisions.

## Alternatives Considered
What else did we evaluate? Why did we reject each option?

What to write ADRs for in banking:

• Choice of core banking platform or major component
• Database technology selection, especially for PII or PCI-scoped data
• Authentication and authorization architecture
• Network segmentation approach
• API gateway strategy and third-party integration patterns
• Cloud vs. on-premise decisions for each workload class
• Encryption standards—at rest, in transit, key management
• Disaster recovery architecture and RPO/RTO commitments
• Any decision that a future developer, product manager, or risk analyst will ask “why?” about

What I’ve learned about making ADRs stick:

Store them in version control alongside code, or in whatever shared space your team will actually find and maintain them. Don’t retroactively write ADRs for every historical decision—start now, document forward, and backfill only the decisions actively causing confusion or cross-team friction.

Keep them short. One to two pages maximum. If you need more space, link to a design document, but the decision itself must stand alone.

One tip that accelerated adoption: call them “decisions” instead of “ADRs.” The word “architecture” intimidates people. “Record” implies bureaucracy. “Decisions” is what people actually make.

2. Application Portfolio Catalog: Know What You Run

TOGAF defines multiple catalogs across its ADM phases, but the one that pays for itself immediately is the Application Portfolio Catalog—a structured inventory of every application, system, and service your bank operates or depends on.

This matters internally because you cannot have a productive conversation about technology strategy, vendor risk, or incident impact if different departments are working from different inventories—or from no inventory at all. It also satisfies DORA Article 8 (ICT asset inventories), the FFIEC AIO booklet, and the OCC’s third-party risk management guidance. But the internal value is primary: you cannot manage what you cannot name.

For each application, you need at minimum:

• Application Name — The canonical name used internally
• Business Owner — Who is accountable (person and department)
• Technical Owner — Who maintains it (person and team)
• Description — One-sentence purpose
• Business Capability Supported — What business function this serves (e.g., “Lending Origination,” “AML Screening”)
• Deployment Model — On-premise, private cloud, SaaS, or hybrid
• Hosting Provider — If external: who and where
• Data Classification — Does it handle PII, PCI, confidential, or public data?
• Criticality Tier — Tier 1 (catastrophic if down), Tier 2 (significant), Tier 3 (tolerable)
• Recovery Targets — RPO and RTO
• Key Integrations — What does it connect to, upstream and downstream?
• Vendor / License Status — Commercial vendor and contract renewal date, open-source, or in-house
• Lifecycle Status — Active, sunset, pilot, or deprecated
• Last Security Review Date — When was it last assessed?

Where to maintain it: a spreadsheet is fine to start. Really. Don’t let tool selection become an excuse for inaction. If you later grow into LeanIX, Ardoq, or a CMDB like ServiceNow, you’ll migrate. But a well-maintained spreadsheet that everyone trusts is infinitely more valuable than an expensive tool with stale data.

The key integrations field is the most important one. It’s what tells you the blast radius when a vendor has an outage and you need to know what’s affected within minutes, not hours. It’s also what Risk needs to assess concentration exposure—and what examiners look for when evaluating systemic risk.

3. Technology Portfolio as a Tech Radar: What’s Blessed, What’s Dying, What’s Banned

TOGAF’s Technology Portfolio Catalog classifies all technology in use across the enterprise. In practice, for a bank without a formal EA function, this works best as a Tech Radar—a concept ThoughtWorks popularized that classifies technologies into rings of adoption status.

The four rings:

• Adopt — Approved and recommended. Use for new projects. No approval needed.
• Trial — Promising, approved for controlled use. Not yet proven at scale. Needs architecture review for production.
• Hold — Existing usage permitted. Don’t start new projects with this. Migrate away when opportunity arises.
• Avoid — Banned. Known security, compliance, or support risks. Active removal plans required.

The internal value is immediate: when a developer wants to introduce a new framework, the Tech Radar gives them a structured answer instead of a hallway conversation. When Product asks whether a vendor integration is feasible, Engineering can point to the radar. When Risk asks whether you’re managing end-of-life technologies, this is your evidence. And yes—when a regulator asks about technology lifecycle management, this is your answer too.

This connects directly to what I described in the reference architecture—the structural thinking about which technologies belong where. The Tech Radar adds the lifecycle dimension: not just where a technology lives in your stack, but where it is in its journey through your organization.

Your radar should cover programming languages and runtimes, databases and data stores, messaging and integration middleware, cloud services and infrastructure, operating systems and container platforms, security tools and protocols, front-end frameworks, and third-party APIs and SaaS dependencies.

Review quarterly. Technology status changes, and a quarterly cadence is enough to stay current without creating meeting fatigue. Make it visual—even a simple chart with four concentric rings communicates more effectively than a list. And tie it to your ADRs: when a technology moves from “Adopt” to “Hold,” write an ADR explaining why. The decision trail matters.

4. Architecture Contracts (Lightweight): Agreements, Not Documents

In TOGAF, an Architecture Contract is a formal agreement between a development team and the architecture governance body. For a bank without a governance board and no dedicated architecture function, this sounds impossibly bureaucratic.

But the underlying need is real: when a project team commits to building something a certain way, that commitment needs to be visible, trackable, and enforceable. Otherwise, architectural decisions erode sprint by sprint, and the system you reviewed last quarter isn’t the system running today.

I’ve watched this happen. The team that agreed to use the API gateway goes direct to the database “just for this one endpoint.” The encryption standard gets skipped because “we’ll add it in the next sprint.” That next sprint never arrives. This is the same pattern I wrote about in the privileged access paradox—governance that exists on paper but dissolves in practice.

The lightweight version is a one-page agreement, embedded in your project kickoff process, answering four questions:

1. What architectural principles and standards apply? Reference your Tech Radar and relevant ADRs.
2. What are the non-negotiable constraints? Data residency, encryption standards, network segmentation, authentication protocols.
3. What review checkpoints exist? At minimum: design review before implementation, architecture review before production.
4. Who is accountable? Name a person, not a committee.

A template:

PROJECT: [Name]
DATE: [YYYY-MM-DD]
TEAM LEAD: [Name]
ARCHITECTURE REVIEWER: [Name]

APPLICABLE STANDARDS:
- All "Adopt" technologies from Tech Radar v[X] apply
- ADRs [list numbers] are binding on this project
- [Specific constraint, e.g., "PCI DSS scope applies"]

NON-NEGOTIABLE CONSTRAINTS:
- [ ] PII encrypted at rest using [standard]
- [ ] All external APIs behind API gateway
- [ ] No direct database access from external services

REVIEW CHECKPOINTS:
- [ ] Design review completed before sprint [X]
- [ ] Security review completed before UAT
- [ ] Architecture sign-off before production deployment

SIGNATURES:
Team Lead: _____________ Date: _____
Reviewer:  _____________ Date: _____

Where this pays off:

Vendor integrations. When onboarding a third-party provider, the lightweight contract ensures integration patterns, data handling, and security standards are agreed upfront—across Engineering, Risk, and Procurement. This also satisfies DORA’s Articles 28 through 30 on third-party risk management.

Internal project delivery. The contract prevents the “we’ll fix the security later” pattern that never gets fixed. It gives every stakeholder visibility into what was agreed.

Cross-team accountability. When someone asks how you ensure new systems conform to your architectural standards, the answer is: signed contracts, review checkpoints, and evidence of reviews completed.

5. Data Entity / Data Flow Inventory: Follow the Data

This is the artifact that prevents the most confusion across departments—and the one that regulators care about most. DORA Article 9 covers network architecture documentation and data flow requirements. The FFIEC expects visibility into how data moves through your systems. PCI DSS requires data flow diagrams for cardholder data. GDPR requires records of processing activities. Every framework converges on the same demand: show us where the sensitive data lives and how it moves.

But the internal value comes first. When Product wants to launch a new feature that touches customer data, this is how they understand the constraints. When Security investigates an incident, this is how they trace the blast radius. When Compliance asks about data residency, this answers it in minutes instead of days.

The minimum viable version has two components.

Component A: Data Entity Catalog

For each sensitive data type, document:

• Entity — What is it? (Customer PII, Transaction Records, Card Numbers)
• Classification — Confidential, restricted, or public
• Primary System of Record — Which system owns it?
• Retention Policy — How long must you keep it? (e.g., 7 years post-account closure)
• Encryption at Rest — Standard in use (e.g., AES-256)
• Regulatory Coverage — Which regulations apply? (GDPR, GLBA, PCI DSS, BSA/AML)

Component B: Data Flow Map

This doesn’t need to be a formal ArchiMate diagram. A clear diagram—drawn in draw.io, Mermaid, or Lucidchart—that shows:

• Where sensitive data enters your ecosystem (customer channels, partner feeds, vendor APIs)
• Where it’s processed and stored (which systems, which databases)
• Where it exits (reporting systems, regulatory submissions, partner integrations, analytics)
• What crosses a trust boundary (internal network to DMZ, on-premise to cloud, your systems to third-party)

The trust boundary crossings are where things break. Every time data crosses a boundary, there should be a documented control: encryption in transit, API authentication, network segmentation, access logging. If you can show these controls mapped to your data flows, you’ve answered the hardest questions—from your own teams and from auditors—before they’re asked.

Putting It Together: The Operating Model

Five artifacts are useless if they’re created once and left to rot. The difference between documentation and a practice is maintenance cadence and integration into how your teams already work. This is essentially a reconciliation loop — you declare desired architectural state through your artifacts, observe drift through quarterly reviews, and close the gaps before they become incidents.

Roles (Not Positions)

You don’t need to hire an Enterprise Architect. You need to assign architecture responsibilities to people who already exist:

• Architecture Owner (likely your CTO, VP of Engineering, or Head of IT) — Accountable for the five artifacts existing and being maintained. Participates in design reviews. Signs Architecture Contracts.
• Tech Radar Custodian (likely a senior engineer or tech lead) — Maintains the Technology Portfolio. Proposes additions and removals quarterly.
• Application Catalog Owner (likely an IT operations or service management lead) — Keeps the Application Portfolio current. Validates quarterly.
• Any developer can propose and author an ADR.

Cadence

• ADR creation — Continuous, event-driven. Any team member, reviewed by Architecture Owner plus relevant team.
• Application Catalog update — Quarterly. Catalog Owner validates with system owners.
• Tech Radar review — Quarterly. Architecture Owner plus senior engineers.
• Architecture Contract creation — Per project or integration. Project lead plus Architecture Owner.
• Data Flow Map review — Semi-annually, plus after any major architectural changes. Architecture Owner, Security, and Compliance.

Integration With What You Already Have

The artifacts plug into processes that already exist. Don’t create new ones:

Change management. Before approving a significant change, reference the Tech Radar and relevant ADRs. This is your architecture governance, embedded in a process you already run.

Vendor onboarding. The Architecture Contract becomes part of your third-party risk management workflow—aligning Engineering, Risk, and Procurement before integration work begins.

Incident response. When something breaks, the Application Catalog and Data Flow Map tell you what’s affected and what data is at risk. This is operational resilience in practice.

Planning and roadmapping. When Product and Engineering sit down to prioritize, the Tech Radar and Application Catalog give them a shared view of the landscape instead of competing assumptions.

What You’re Deliberately Leaving Out

A full TOGAF implementation would include Business Footprint Diagrams, Process/Event/Control/Product Catalogs, Functional Decomposition Diagrams, Business Interaction Matrices, Application Communication Diagrams, Organization/Actor Catalogs, and more. You’re choosing not to produce these—for now.

Here’s why that’s defensible.

You’re applying TOGAF’s own principle of tailoring. TOGAF 10’s modular structure is designed for customization—its Preliminary Phase formally includes framework tailoring, and viewpoints are intended to be adapted to stakeholder concerns rather than applied rigidly. You’re not violating the framework. You’re using its built-in escape hatch.

You’re following a risk-driven approach. George Fairbanks’ Just Enough Software Architecture argues you should invest architectural effort in proportion to the risk it mitigates. The five artifacts address the highest-value areas for a bank where departments need to coordinate—decision traceability, asset visibility, technology lifecycle, delivery governance, and data protection. The remaining TOGAF catalogs address concerns that matter at scale but don’t justify the investment before you have the team to maintain them.

You can always add more. These five form a foundation. When you eventually hire a dedicated architect, or when the organization grows, you’re building on something—not starting from nothing. Adding a Business Capability Map on top of a maintained Application Catalog is straightforward. Building Functional Decomposition Diagrams is trivial when you already have ADRs documenting your key decisions.

What Questions Each Artifact Answers

When someone across the organization—or a regulator—asks a specific question, here’s where to point them:

• “What systems do we run and who owns them?” — Application Portfolio Catalog
• “Why was this system designed this way?” — ADRs
• “What technologies are we standardizing on?” — Tech Radar
• “How do we ensure new systems conform to our standards?” — Architecture Contracts plus Tech Radar
• “Where does customer data live and how does it move?” — Data Entity Catalog plus Data Flow Map
• “What are our third-party dependencies?” — Application Portfolio Catalog, specifically the integrations field
• “What’s our plan for end-of-life technologies?” — Tech Radar (Hold/Avoid items) plus ADRs
• “Show me your IT asset inventory” (DORA Art. 8, FFIEC AIO) — Application Portfolio Catalog
• “Document your network architecture and data flows” (DORA Art. 9) — Data Flow Map
• “Show evidence of architectural governance” (FFIEC AIO) — Architecture Contracts plus ADR log

Starting Tomorrow: A 30-Day Kickoff

Week 1: Start writing ADRs. Pick the three most recent significant technology decisions your team has made. Write an ADR for each. Share them. Make ADR authoring part of your team’s working agreement. This is the lowest-effort, highest-value artifact you can produce.

Week 2: Build your Application Portfolio Catalog. Start with Tier 1 systems—the ones that would make the front page if they went down. Don’t aim for completeness. Aim for accuracy on the things that matter most.

Week 3: Draft your Tech Radar. Gather your senior engineers for a two-hour session. Classify the top 30 to 40 technologies your bank uses. Publish the result. It doesn’t need to be perfect. It needs to exist.

Week 4: Create your first Architecture Contract template and your Data Flow Map for one critical data path—customer onboarding or payment processing. Iterate from there.

By the end of 30 days, you’ll have the foundation. Not a complete enterprise architecture. Not a TOGAF-compliant repository. But a set of living artifacts that give every department a shared view of your technology landscape—and that happen to answer the questions regulators ask, too.

That’s not “TOGAF-lite.” That’s architecture that earns its keep. The same principle applies whether you’re encoding prompting skills as infrastructure or governance expectations as living artifacts — the leverage comes from systematizing what would otherwise depend on individual heroics.

---

The views in this post reflect general experience in regulated financial services and do not constitute legal or compliance advice. Consult with your institution’s compliance and legal teams regarding specific regulatory requirements.