Application Architecture — How Silos Dissolve

Section 4 of Agentic Banking Architecture: A Practitioner's Guide

The Current State: Vertical Silos

A typical large bank runs hundreds of applications. Lending has its own system with its own database, its own business rules engine, its own reporting. Payments has another. Treasury another. CRM another. Each is a vertical silo — self-contained, independently maintained, and connected to everything else through integration layers.

This isn't an accident or a failure of architecture. It's the result of two reinforcing forces. First, banks build systems product by product: the bank launches a new product, builds or buys a system for it, and connects it to everything else. Repeat a few hundred times and you have the modern bank's technology estate. Second, Conway's Law — the architecture mirrors the organisation. The lending team builds and owns the lending system. The payments team builds and owns the payments system. Each team optimises for its own domain, its own release cycle, its own data model. The silos in the technology reflect the silos in the organisation.

This matters because it explains why previous integration efforts — SOA, APIs, microservices — typically haven't broken the pattern. They addressed the technical interfaces between silos without changing the organisational boundaries that created them. A microservice architecture built by the same product-aligned teams produces the same silos, just smaller ones.

The integration between these silos is where most of the cost and complexity lives. ETL pipelines extract data from one silo and load it into another. Operational data stores aggregate data from multiple sources so that downstream systems have a consolidated view. Reconciliation processes verify that data is consistent across silos. API layers provide controlled access points. Data warehouses store historical copies for analytics and reporting.

Every one of these integration components exists because data is duplicated across silos and needs to be kept in sync. The integration layer doesn't add business value — it compensates for a structural problem.

The Target State: Horizontal Processes on Shared Ledgers

In the target agentic architecture, business logic lives in agents. Data lives in shared ledgers — golden source, immutable, auditable data stores that multiple agents read from and write to. There are no application databases because there are no applications in the traditional sense. There are no ODS because there's no need to aggregate data that's already shared. There are no ETL pipelines because data doesn't need to be copied between systems.

A lending process in this architecture looks fundamentally different. A lending agent receives a goal: "assess this loan application." It calls shared data services to retrieve customer data, credit bureau data, and product terms. It applies credit policies — expressed as prompts and guardrails, managed through the policy codification pipeline described in Section 3. It calculates pricing, generates documents, records the decision to the shared ledger, and routes the outcome. No lending application was involved.

Agentic architecture challenges the bank's siloed architecture in a way previous waves didn't, because business logic migrating into agents means the organisational boundary shifts too. The lending team no longer owns a lending system — they own lending policies and lending agent configurations. The platform team owns the shared services and data layer. The question of who owns what changes fundamentally, which is why the people transformation in Section 8 is inseparable from the technical architecture.

Vertical silos become horizontal processes on shared ledgers.

What Disappears

The implications compound. No applications means no application databases. No application databases means no ODS to aggregate them. No ODS means no ETL to populate it. No data duplication means no reconciliation. The engineering capacity currently spent on integrations, ETL, ODS, and reconciliation can be redirected to building products and experiences that customers actually care about.

This isn't incremental cost savings. It's a structural elimination of complexity that exists only because of the silo model.

What Makes Systems Easier or Harder to Wrap

Not all legacy systems are equally ready for Phase 1. Two factors dominate:

Source code ownership. Systems where the bank owns and controls the source code are fundamentally easier to expose as agent tools. The team can define whatever interface the agents need — fine-grained access to specific functions, custom data views, purpose-built endpoints. They can refactor where needed to make the wrapping clean. Systems running vendor packages with limited configurability and no source access are harder: you're constrained to whatever interfaces the vendor chose to expose, which were designed for human users or batch integration, not for agents.

Existing service exposure. Systems that have already been wrapped in APIs or microservices — regardless of whether they run on mainframes, distributed platforms, or cloud — are already partially ready. The service layer is the tool interface, or close to it. An MCP adapter over an existing REST API is a thin piece of work. The systems that are hardest to wrap are those with no service layer at all: monolithic applications where functionality is only accessible through a UI or through tightly coupled batch interfaces.

These two factors are independent. A bank-built mainframe system with well-defined transaction interfaces can be easier to wrap than a modern cloud-native vendor package with a locked-down API. A legacy system that was already exposed as microservices during a previous modernisation effort has a head start, even if the modernisation programme didn't achieve its broader goals.

This matters for migration sequencing. Banks should prioritise wrapping systems where they own the source and where service interfaces already exist — these deliver agent value fastest with lowest effort. Vendor-packaged systems with limited APIs come later, and may require vendor cooperation or replacement to fully integrate into the agentic architecture.

The Transformation Programmes

If this is where the architecture is heading — and the migration path in Section 5 argues it is — then banks need to ask whether the multi-year programmes currently replacing one silo with another are still worth finishing. Not because the replacement system is bad, but because it may be the last generation of something that's about to become structurally obsolete.

This is especially pointed when the replacement is a vendor package: the bank trades source code ownership for a modern UI and cloud hosting, but ends up with a system that's harder to wrap as an agent tool than the legacy it replaced. The modernisation may have moved backwards on the axis that matters most.

This isn't a call to stop everything. It's a call to evaluate current programmes against the emerging architectural reality and redirect investment where the long-term return is highest.

This section expands on ideas first published in Part 4 of the LinkedIn series. The closing question about silo-replacement programmes generated strong discussion, with perspectives from both bank technology leaders and vendor practitioners.