Complexity has to be managed, not eliminated
Bank systems appear unified externally but are deeply fragmented internally—layered mosaics of decades-old technology decisions creating redundancy and organizational silos. Teams operating isolated system segments lack visibility into cross-functional impacts, limiting transformation project effectiveness and increasing unpredictability in technological change.
- Bank systems are layered mosaics of decades-old technology decisions, each representing a different computing era
- Teams operating isolated system segments lack visibility into cross-functional impacts, limiting transformation effectiveness
- Understanding system history and creating end-to-end vision through cross-functional communities converts inevitable complexity into manageable complexity
Portuguese banking expert argues that fragmented legacy systems require proactive complexity management through end-to-end vision, cross-functional teams, and historical system understanding rather than elimination attempts.
Walk into any major bank and ask someone from the payments team what the credit division is doing, and you'll get a polite shrug. Ask the cards department how their work intersects with accounts, and the answer will be vague. From the outside, a bank looks like a single organism—one system handling deposits, transfers, loans, and plastic cards all at once. Step inside, and you find something closer to an archaeological dig: layers of technology stacked on top of each other, each one representing a different era of computing, each one built by people who are no longer there, each one speaking a language the next layer doesn't quite understand.
This fragmentation isn't a bug in banking systems. It's the inevitable result of decades of accumulated decisions, each one rational at the time it was made. A bank that started with mainframe-based accounting in the 1980s, bolted on distributed systems in the 1990s, added web services in the 2000s, and is now trying to integrate cloud infrastructure in the 2020s doesn't have a system. It has a palimpsest—a document where old text has been scraped away and written over so many times that the original meaning is buried but never quite gone.
The problem this creates is deceptively simple to state and brutally hard to solve. When each team knows only its own corner of the operation, when the accounts group doesn't speak the same language as the transfers group, when a change to one system's logic can ripple through five others in ways nobody predicted, the organization becomes trapped. Projects take longer. Costs balloon. Risks hide in the gaps between departments. And the bank, under constant pressure to launch new products, comply with regulations, and implement new controls all simultaneously, finds itself unable to move as fast as the market demands.
The traditional response has been to try to eliminate the complexity—to rip out the old systems and replace them with something clean and unified. But this approach misses something fundamental: the complexity won't go away. It will simply transform. A bank's systems are complex because banking is complex, because regulatory requirements are complex, because the history of the organization is embedded in every line of code. Trying to eliminate complexity is like trying to eliminate gravity. The only viable strategy is to understand it, manage it, and make it work for you instead of against you.
Building that understanding starts with history. Not the sanitized version in the annual report, but the real story: why was this decision made in 1995? What problem was it solving? What constraints existed then that don't exist now? What assumptions were baked in that are no longer valid? A team that understands this context can anticipate what will break when they change something. A team that doesn't understand it will keep repeating the same mistakes, wondering why the same problems keep surfacing.
Equally important is developing what might be called an end-to-end vision of the system—not from the perspective of any single team, but from the perspective of the actual work that flows through the bank. A customer's deposit, for instance, doesn't care about organizational boundaries. It flows through accounts, then through settlement, then through risk management, then through compliance. If each of those teams has a different mental model of what a deposit is, if they use different terminology, if they don't understand how their decisions affect the next team downstream, the system becomes brittle. The solution is to create cross-functional communities—groups of people from different departments who work together to build a shared understanding of how the work actually flows.
This isn't about eliminating silos through organizational restructuring or motivational posters. It's about building genuine shared knowledge. It's about having the accounts team and the transfers team sit down and agree on what they mean by "settlement." It's about creating architectural tools that let people see how their piece of the system connects to everyone else's. It's about recognizing that the person who understands the credit card system deeply is a valuable teacher, not a threat to be managed.
When a bank can combine these approaches—historical understanding, end-to-end vision, cross-functional knowledge sharing—something shifts. The complexity doesn't disappear, but it becomes manageable. It becomes something the organization can work with instead of something that works against it. And that's when real innovation becomes possible. That's when a bank can actually simplify its processes, move faster, and grow. The fragmentation remains, but it's no longer a prison. It's a landscape the organization has learned to navigate.
Notable Quotes
The system, viewed from outside, appears unified, but looking inside reveals profound fragmentation— Banking systems expert
Complexity must be understood and managed proactively rather than bypassed or eliminated— Banking systems expert
The Hearth Conversation Another angle on the story
Why does this matter now? Banks have been dealing with legacy systems for decades.
Because the pace of change has accelerated. Regulators are demanding new controls faster. Customers expect new products constantly. The old approach—just patch it and move on—doesn't work anymore. You need to actually understand what you're managing.
But understanding takes time. Doesn't that slow things down even more?
The opposite. A team that understands the system's history can make changes confidently. A team that doesn't understand it will make changes blindly, hit unexpected problems, and have to redo the work. Understanding is what actually saves time.
You mention cross-functional teams. But banks are organized by product—cards, loans, deposits. How do you break that down?
You don't break it down. You build bridges across it. You create communities where people from different products work together on shared problems. They keep their expertise, but they gain visibility into how their work affects others.
What happens if you don't do this? What's the worst case?
You get stuck. Projects take twice as long as they should. Costs spiral. And you can't innovate because you're too busy managing crises in the gaps between systems. You become a bank that can't move.
Is this a technology problem or an organizational problem?
It's both, but it's fundamentally an organizational problem wearing a technology costume. The systems are complex because the organization is complex. You can't fix one without addressing the other.