Enterprise Architecture in Banks: Layers, TOGAF and Modernisation (CAIIB ITDB)

If you are preparing for the CAIIB ITDB elective, you need a working command of enterprise architecture in banks — not just as an exam topic but as the discipline that keeps a bank's technology decisions aligned with its board-approved strategy. Enterprise architecture in banks maps how business processes, applications, data and technology infrastructure fit together, and gives leadership a documented way to move from today's tangled systems to a target state without breaking operations mid-flight. This article walks through the four architecture layers, the TOGAF Architecture Development Method banks use to plan change, the monolith-to-microservices modernisation path, and the governance mechanisms — architecture review boards and technical debt registers — that keep the whole exercise honest.

🏛️ The Four Layers of Enterprise Architecture

Every enterprise architecture in banks framework — TOGAF included — is organised into four layers, often called the BDAT stack. The business layer captures strategy, organisation structure, processes and the products a bank sells: current accounts, trade finance, retail loans and so on. It answers the question of what the bank does and why.

The data layer defines the entities a bank must manage consistently — customer, account, collateral, transaction — independent of which system stores them. A bank running a dozen product systems still needs one authoritative definition of "customer", which is why data architecture sits above any single database. The Database Management Systems chapter is worth revisiting here, since data-layer decisions rest on the same normalisation and referential-integrity concepts.

The application layer is the inventory of systems — core banking, CRM, loan origination, payment gateways — and how they exchange data. The technology layer covers the infrastructure these applications run on: servers, storage, networks and cloud platforms. The Networking Systems chapter maps directly onto this layer.

An architecture review that only looks at applications and ignores data lineage, or documents infrastructure without linking it back to a business process, will not survive an internal audit. The layers exist precisely so that a change in one — say, retiring a legacy core banking module — can be traced up to the business capability it serves and down to the servers it occupies.

🧭 The TOGAF Architecture Development Method in Banking

Most Indian banks that run a formal EA function anchor it to TOGAF's Architecture Development Method (ADM), an eight-plus-phase cycle. The Preliminary Phase sets up the architecture capability and principles; Phase A defines architecture vision and scope for a given initiative, say a digital lending platform.

Phases B, C and D then develop the Business, Information Systems (data and application) and Technology architectures in turn — each phase documents a baseline, a target, and the gap between them. Phase E identifies opportunities and groups changes into workable projects; Phase F produces the migration plan with sequencing and dependencies; Phase G governs implementation so delivered systems actually match the target architecture; and Phase H manages change requests once the new state is live.

The ADM is a cycle, not a one-time exercise — a bank revisits the Preliminary Phase whenever business strategy shifts, such as a new digital-only vertical or an acquisition that brings in a second core banking platform.

💡 Exam Tip: Remember ADM phase order as Preliminary → A → B → C → D → E → F → G → H; CAIIB questions often test which phase a described activity belongs to.

Applying the ADM to something concrete makes it stick. Once you have been through the Introduction to Computing chapter, treat each of your bank's major systems as a candidate for a mini gap analysis: what does it do today, what should it do under the target state, and which ADM phase would you use to close that gap.

🔄 Monolith to Microservices: The Modernisation Roadmap

Most Indian banks still run a monolithic core banking system: one large, tightly coupled application handling accounts, deposits and general ledger together. A monolith is simple to operate at small scale but becomes a bottleneck as transaction volumes and the number of digital channels grow — a single bug fix can require testing and redeploying the entire system.

Microservices architecture breaks that monolith into smaller, independently deployable services — say, a separate service for account opening and another for interest calculation — each owning its own data and exposed through APIs. This lets a bank update its mobile-banking-facing services weekly without touching the general ledger engine underneath.

The transition rarely happens in one shot. Banks commonly use the strangler fig pattern: new functionality is built as microservices around the edges of the monolith, traffic is gradually routed to the new services, and the legacy core is strangled down to only the functions that are genuinely hard to decompose, such as core ledger posting.

⚠️ Common Mistake: Treating modernisation as a single big-bang cutover. A phased transition state — running monolith and microservices side by side with clear data-ownership boundaries — is what a transition roadmap in the target-state EA document should show.

This transition state is exactly what a target-state architecture and transition roadmap are meant to capture: not just the end picture, but the intermediate states a bank will pass through, each with its own risk profile and rollback plan.

🛡️ Architecture Review Board and Technical Debt

An Architecture Review Board (ARB) is the governance body that approves whether a proposed system design complies with the bank's target-state architecture and principles before it goes into build. It typically includes the Chief Technology Officer or Enterprise Architect, along with representatives from information security, data governance and the sponsoring business unit. No major system change should bypass this review, because that is how architectural drift — and technical debt — accumulates unnoticed.

Technical debt is the accumulated cost of shortcuts: a point-to-point integration built instead of using the standard integration layer, a database schema patched instead of redesigned, a legacy language nobody can maintain any longer. Left untracked, technical debt slows every future project down, because new work has to route around it. A disciplined ARB keeps a technical debt register alongside the architecture roadmap so that debt is paid down deliberately, not discovered during an outage.

This is also where enterprise architecture in banks connects back to board oversight. Under RBI's IT governance guidance, the board and IT Strategy Committee are expected to see that technology decisions trace back to an approved strategy — an ARB with a working technical debt register is the operational evidence of that link.

🚀 Bringing It Together for Your CAIIB Exam

For CAIIB ITDB, examiners expect you to connect enterprise architecture in banks to real governance: the four BDAT layers, the TOGAF ADM phase sequence, a transition roadmap for monolith-to-microservices modernisation, and an Architecture Review Board that keeps technical debt visible instead of hidden. Treat each concept as part of one story — strategy down to servers — rather than isolated definitions. Reinforce this with practice sets in our CAIIB course before attempting the MCQs below.

Once you have covered the Introduction to Software chapter, pair it with our related reads on IT service management in banks for how change requests are actually executed, and data governance in banks for how the data layer is kept trustworthy. If you also cover network security in banking IT infrastructure, you will have the technology-layer risk picture as well. And because architecture decisions ultimately shape a bank's risk profile, it is worth comparing this with how credit risk models in banks depend on the same clean, well-governed data architecture.

Browse more ITDB coverage on the Information Technology and Digital Banking tag hub, then test yourself below.

🧠 Practice MCQs: Enterprise Architecture in Banks

Want chapter-wise mock tests with 100+ MCQs? Start practising free →