Architecture is a commercial decision

That gap is expensive, and almost nobody traces the cost back to where it starts.

If your AI initiatives are moving more slowly than expected, or stalling before they scale beyond a pilot, architecture is rarely the first explanation anyone reaches for. Yet a surprising number of problems that look like execution failures (a slow team, a crowded roadmap, a stretched budget) trace back to the way the system was designed years ago, by people who made the right call with the information they had at the time. The architecture has quietly become the ceiling.

The cost of that ceiling is rarely visible, and hard to trace back. Gartner estimates that outdated systems consume more than 75% of IT budgets at many financial institutions. That is capital that should be funding your next product capability, spent instead on standing still.

Why good teams miss targets

I have worked inside systems at both ends of this spectrum.

At one organisation, we were shipping twice a month, at best, not because the team was slow, but because the architecture made anything faster too risky. Some parts of the product were so tightly coupled that deployment was a risk, every change required a full regression, and every new feature had to be tested by hand against every existing one, because the coupling made automation impossible.

The decision to change should be viewed as an investment decision, one that needs a business case, an honest view of the effort involved, and commitment at leadership level. The cost of not making it: lost clients, or adjacent market revenue left on the table because you cannot move fast enough to capture it. That is a P&L problem, not a technical one.

The contrast at another organisation, ten thousand releases a year, fully automated. If a client calls to say something is not working, you fix it immediately, and you tell them to refresh the browser, because it is already live. That is not a technical achievement. That is how you build client advocacy. There is a risk dimension here too, and in regulated financial services it matters as much as speed. A tightly coupled system is not just slow to change, it is a bigger blast radius when something goes wrong, and "we shipped it, just refresh your browser" only reads as a virtue if change control and audit trail were designed in alongside the speed. Otherwise it reads as a compliance gap.

The gap between those two businesses was not talent or ambition. It was architecture. Not one decision, but a pattern of decisions made years earlier.

You do not need to design it. You need to challenge it intelligently.

There is a common anxiety among senior leaders when technical architecture comes up. They assume it is engineering territory, and that engaging with it requires technical depth. But what it requires is understanding the commercial impact of the choices, and knowing enough to ask the right questions. You need to understand what each choice costs the business.

A few common patterns:

None of this is really about the pattern itself. A monolith with clean internal boundaries and real test automation can scale perfectly well, plenty of very large companies run one deliberately. The failure most teams actually have is coupling and missing test discipline, and moving to microservices without fixing that just relocates the same tangled dependencies onto the network, where they are harder to see and more expensive to unpick. The pattern is not the point. The boundaries are.

The list is by no means exhaustive and there is no pattern that is simply "AI-ready." What matters is whether your architecture gives AI the three things it needs to move from demo to production: clean, accessible data that is not siloed; deployment fast enough to iterate on models without a full regression cycle; and services loosely coupled enough that a capability can be swapped without touching everything around it. Fail on any one and AI will dazzle in a pilot and stall in production. And the cost lands on everyone, faster than you expect.

Whose job is this, really?

In an ideal world everyone in the business thinks and speaks commercially, including about the architecture underneath it. The reality is messier, so someone has to make architecture legible in the language of revenue, margin and risk.

That starts with the CTO. A CTO should be able to explain an architectural choice in commercial terms: what it protects, what it puts at risk, what it costs to leave alone. A CTO who can only present architecture as diagrams and vendor analysis loses the room and the budget every time.

But it is a partnership, not a handoff. The CPO has to understand the cost and the value of these decisions well enough to stand behind the case, and is often the person best placed to make it, because turning technical capability into commercial consequence is the centre of the product job. In my experience, I was the product leader arguing to pause and break the monolith, to automate the testing and take the payback later, while the louder push in the room was to deliver, deliver, deliver! Most people assume the CTO fights for architecture and the CPO fights for features. In that room it was the other way around.

Bring architecture to the conversation by reframing it as the revenue at risk if a component fails, the hit to NPS as reliability slips, or the churn you are quietly absorbing by deferring the work.

What the CEO has to do is understand that this is a commercial decision, expect the CTO and CPO to bring it to the table that way, and weigh it as one when they do.

This conversation is yours to lead

The question is not whether you are making architectural trade-offs. You are. The question is whether you are making them consciously or accidentally.

What you should expect from the people around you is simple: a CTO who can put architecture in commercial terms, and a CPO who understands enough to challenge or back the call, and sometimes to make it for them. The two of them aligned, bringing you the trade-off as a business decision before it reaches you as a blocker.

That is the conversation to lead, while it is still a choice and not a constraint.