When something breaks in a dramatic way, the instinctive response is often equally dramatic. Tear it all out. Start again. Order the biggest possible solution from the grandest possible vendor and hope that scale equals safety.
I understand the temptation.
After my dishwasher incident, there was a brief moment when I fantasised about ripping out the entire kitchen, moving walls and starting fresh. Then reality intervened. Budget. Time. The small matter of needing somewhere to cook for the next several months.
Banks go through the same emotional cycle after a major incident or a particularly blunt regulatory review. For a while, full core replacement sounds like the only responsible option. Everything else feels like cowardice. But as soon as people start to look at the actual complexity, doubt creeps in. You cannot shut the bank down for two years. You cannot migrate everything in one weekend. You cannot predict the world five years out with enough confidence to lock into a single design.
This is why the Blueprint phase matters. Not as a box ticking exercise. Not as a giant requirements document. But as a disciplined way of answering three hard questions before you touch anything major.
1.- Where are we going. 2.- What capabilities do we actually need. 3.- What constraints do we have to respect.
A good Blueprint is a business artefact, not an IT one. But it is supported by technology. It starts with strategy in plain language, the kind of language your executive team can argue about without hiding behind acronyms.
From there you move to Business Capabilities. Not systems. Not organisational units. The discrete things the bank must be good at to deliver the strategy.
This is where the conversation stops being philosophical and starts being practical. Because once you have a capability map, you can ask questions that have real consequences. Questions like Which capabilities are truly differentiating. Which ones are hygiene factors. Which ones are tightly coupled to the system of record. Which ones could live in specialist platforms without creating operational chaos. Which ones are partner facing by nature, meaning you will never build them alone.
Only once you have that map do you start to think about architecture. Not as a debate about tools and patterns, but as a way to create decision discipline. How do these capabilities hang together. Where do customers and partners touch the system. What principles will you use when the trade offs get hard. What are your non negotiables, and what are your preferences.
This is where Blueprint forces the bank to name the truths it usually avoids. Like the fact that customer data is not a feature of your CRM. It is a capability. And if you let five systems own customer truth, you will never get clean experiences, clean reporting, or clean compliance. Blueprint is where you decide that customer truth has a home, and everything else consumes it.
It is where you decide that product authoring will not be hard coded into the core engine, because that is how “just one more product tweak” turns into a two year release backlog.
It is where you accept that you are not modernising to rebuild yesterday’s spaghetti in tomorrow’s technology.
And yes, Blueprint is also where you face the legacy. But not in the way many banks do it.
Most banks start with legacy analysis because it feels concrete. You can point to code. You can count interfaces. You can list batch jobs. And it feels like progress.
The problem is that if you start there, the past quietly becomes your anchor. You begin designing your future around what is already there. You start protecting constraints that should be challenged. You start optimising a house layout that never made sense in the first place.
In my approach, legacy analysis belongs in Blueprint, but it does not lead Blueprint. It is a reality check applied against a destination that has already been defined. Destination first, then constraints. That ordering matters. It is the difference between renovating a kitchen to support the way you want to live, versus rebuilding the new kitchen around the location of the old dishwasher because moving pipes feels scary.
The Blueprint flow, in one picture
To make this more tangible, here is the Blueprint flow from my book. It is not meant to be a perfect process diagram. It is meant to show the sequence and the feedback loops.
Figure. Blueprint phase flow from strategy to partner shortlist and proof of concept
The key points to notice in the flow are simple. You start with business strategy and goals. You define scope and build the capability model. You set architecture principles and your build buy consume posture. You run partner discovery and analysis based on the capability needs, not based on who has the best demo. You test with a proof of concept, not because PoCs are fun, but because reality is always more educational than PowerPoint. Then, if required, you refine the business case and roadmap based on what you have learned.
That last step is important. Most banks try to lock the business case upfront, before they have validated assumptions. It is like agreeing the full renovation budget before you have even lifted a single floorboard. You can do it, but you will be lying to yourself. Either you pretend uncertainty does not exist, or you hide contingency inside the numbers and hope nobody asks why.
Blueprint is not slow. It is faster than rework. It is cheaper than a misaligned programme. It is the most effective way I know to reduce the risk of building the wrong thing very efficiently.
What happens when you skip Blueprint
The alternative is to skip Blueprint and go straight to bulldozer. Buy a core, start a programme, discover along the way that nobody agreed on scope, that your principles are vague enough to be ignored, and that half the organisation thought they were getting a sports car while the other half wanted a bus.
This is where programmes become theatre. Lots of activity, lots of workshops, lots of steering meetings, and still no shared picture. Decisions get made by momentum, not by intent. Vendor roadmaps become strategy by default. People stop asking whether the target state is right and start asking only whether the plan is on track.
If your current modernisation effort feels chaotic, or if every conversation jumps straight to products and vendors, take that as a sign that your Blueprint is missing or weak. You do not need more tools. You need a shared picture that gives you the right arguments at the right time.
And if you are about to start a new wave of change, resist the urge to grab the sledgehammer first. Spend the time at the drawing board. Your future self, standing in a kitchen that actually works, will thank you for it.
Stay tuned for more insights on this journey. In my book Rip Out the Core, A Practical Path to Coreless Banking, I dive deeper into the methods and real world examples of making this transition. Until then, keep questioning the old assumptions and imagine what your bank could do when it’s freed from the chains of a monolithic core.
