How a Simple Conceptual Misunderstanding Can Ruin a whole application portfolio
In 2021 major Canadian bank’s personal banking technology division had a problem that was consuming developer capacity, inflating project costs, and frustrating the business teams that depended on it.
The Digital Card team — responsible for the applications customers used to apply for banking products — was always late. Always over budget. Always short of developers. Every business request seemed to spawn multiple projects. Changes that should have been simple took months. Bugs fixed in one place reappeared elsewhere.
A new Digital Banking director was appointed and told the Digital Card organization was the main problem. PwC was brought in to diagnose it.
I had already figured out what was wrong.
What I Found
When I joined the Digital Card team, there were two core applications — one for deposit accounts, one for credit cards — plus two or three legacy applications needing migration to the current architecture.
Within months I watched the portfolio grow. Every new product variation, every new customer segment, every new business request generated a new application. By the time I documented the problem there were seven applications in production or development. The number continued to grow after I left.
The six other teams in personal banking technology maintained a single application together — the online banking app. One application. Six teams. Shared codebase, shared ownership, shared maintenance.
The Digital Card team had one team and nine applications — and the number was accelerating.
I was the only person in personal banking who had a complete map of all Digital Card applications in production or development. Every other architect and developer knew their own application. Nobody above me had the full picture. The business certainly did not. PwC did not — they could not have, because getting the full picture required doing what nobody else had done, which was looking across every team boundary simultaneously.
The Root Cause
The problem was not process. It was not resourcing. It was not the framework or the technology stack.
It was a conceptual misunderstanding of the domain — specifically, a misunderstanding of what the word “flow” meant and where flow logic belonged in the architecture.
The Digital Card team had built their entire architecture around the concept of a “flow” — the sequence of screens a customer moves through when applying for a banking product. Each product variation had a slightly different screen sequence. The team treated each different screen sequence as a fundamentally different application. When a new product variation needed a different flow, they copied the entire existing application to a new codebase and modified it.
This seemed reasonable on the surface. The flows were genuinely different. The copy-paste approach was fast. It avoided the regression errors that came from modifying existing production applications.
But it was built on a misunderstanding.
The visual screen flow is not a business workflow. It is a UX decision.
The actual business process in Digital Card is a single step: a customer supplies information and the bank either grants the product or declines. The screens that break this into stages exist to make the process feel manageable to the customer. The number of screens, their sequence, the data fields they contain — these are presentation decisions, not business logic decisions.
The real business workflow lived elsewhere entirely — in Compass, the back-end engine that adjudicates and fulfills product applications. eBanking DC was not the business logic layer. It was middleware. A routing layer between the UI and Compass. An API gateway in practical terms, repackaging UI requests and forwarding them to the correct Compass endpoint.
The team had built nine separate applications to manage something that was not fundamentally different across any of them.
The eCommerce parallel makes this concrete. Amazon does not have a separate shopping cart application for books, electronics, and clothing. The products are different. The cart is the same. CIBC’s Digital Card team had built a separate cart for every product type — and was building more with every new business request.
Why The Regression Problem Was A Symptom, Not A Cause
The original justification for creating new applications instead of extending existing ones was the regression problem. Modifying a production application introduced bugs. The copy-paste approach avoided that risk.
This was true. But it was treating a symptom as a constraint rather than diagnosing its cause.
Regression errors cascading through a production application are a symptom of tight coupling — specifically, of a design that fuses the front end and back end so completely that a change in one layer propagates unpredictably through the other. The Digital Card architecture had done exactly this. The back end controlled the front-end screen flow, making the two layers inseparable.
The solution to tight coupling is not to copy the coupled system into new spaces. It is to decouple the layers. The regression problem was telling the team that the architecture needed to be fixed. They responded by replicating the broken architecture nine times.
What PwC Missed
PwC conducted their assessment through interviews. Two young consultants called me. I had formed my diagnosis by then and told them directly: the performance difference between Digital Card and the rest of personal banking technology was simple. Six teams maintained one application together. Digital Card had one team maintaining nine applications — and the count was growing with every business request.
They did not engage with this. The report they produced recommended appointing a new architecture director. The director appointed had strong business understanding and limited architecture understanding.
The root cause — the domain modeling mistake, the misunderstanding of flow, the compounding cost of nine separate codebases for one business process — was never named, never addressed, never fixed.
The business continued to experience the consequence. Every change request touched multiple applications. Projects that looked simple in scope expanded when additional applications were discovered midway through delivery. Timelines grew. Costs grew. Developer capacity was consumed maintaining nine codebases instead of one.
The Solution
The fix required moving the flow orchestration where it actually belonged — to the UI layer — and converting eBanking DC from an application layer into a true service layer.
In the correct architecture, the UI is not a collection of dumb screens controlled by the back end. It is a collection of full applications that manage their own screen flow. eBanking DC stops being the orchestrator of the UI and becomes a service layer — a collection of true REST API endpoints based on real business resources like applicant, product, and application, rather than endpoints mapped to specific UI screens.
This decouples the layers completely. Each layer manages its own concerns. Changes to the UI screen flow do not touch the service layer. Changes to the service layer do not cascade into the UI. The regression problem disappears because the tight coupling that caused it no longer exists.
One configurable application replaces nine. The same team. Lower maintenance cost. Faster delivery. No more project sprawl when the business requests a new product variation.
What Remained
The document I produced was the only complete picture of the Digital Card portfolio that existed anywhere in the organization. It named the root cause, quantified the cost trajectory, and proposed a complete architectural solution.
It was circulated. The business did not understand why new applications kept appearing. The development team did not understand why the proliferation was unsustainable. The architecture director appointed after the PwC review was not equipped to evaluate it.
The document exists. The diagnosis was correct. The organization was not structured to receive it.
The number of applications continued to grow.
Russ Profant is a solutions architect and independent consultant with 30 years of experience across financial services, investment banking, healthcare, and government. He runs PC4IT, offering cloud cost diagnostics and architecture advisory to mid-market organizations. pc4it.com
