Modernisation fails before any code is written
Most legacy modernisation efforts do not fail because of technology. They fail much earlier, in the decision phase, when ownership is unclear, choices are delayed, and strategy is discussed at length but never translated into concrete priorities. By the time the technical work starts, the project has often already absorbed the cost of those unmade decisions; the engineering team simply becomes where the failure finally shows up.
This matters because the conventional wisdom points in the wrong direction. When a programme stalls, the instinct is to question the architecture, the framework, the team. Sometimes that is fair. But far more often the architecture is sound and the people are capable, and the thing that quietly broke the project happened months before anyone opened an editor. If you only ever inspect the code, you will keep treating symptoms.
The patterns we see again and again
Across the modernisation work we do for organisations in the UAE and the wider MENA region, the decision-phase failures are remarkably consistent:
- Too many stakeholders, no clear ownership. Everyone has an opinion and a veto; nobody has the authority to decide. Choices get made by whoever is most senior in the room that day, then quietly relitigated the next week.
- Technical decisions postponed until they become urgent. A deferred decision is not a neutral act. It is a decision to let the deadline choose for you, usually badly.
- Teams told to “be agile” without real authority. Agility is a way of making and revising decisions quickly. Asking a team to be agile while withholding the authority to actually decide anything produces motion without progress.
- Strategy discussed endlessly but never made concrete. A strategy that is not expressed as “this before that, and here is what we will not do” is a mood, not a plan.
None of these are technical problems. All of them surface as technical problems eventually.
How uncertainty becomes architecture
Here is the mechanism that makes decision-phase failure so expensive: when decisions are unclear, teams do not stop. They compensate. They build workarounds, add a configuration flag for every position the organisation has not committed to, keep both options alive “for now,” and route around the part of the system nobody will rule on. Architecture absorbs the uncertainty, and it does so silently. Complexity grows not because the engineers were careless but because they were being responsible in the absence of a decision.
A year later, the system carries the shape of every argument that was never settled. The cost of those non-decisions is now baked into the code, and it is far more expensive to remove than it would have been to decide in the first place. This is the same dynamic that turns a legacy estate into something nobody fully understands. Much of the accidental complexity in old systems is unmade decisions, fossilised.
What good decision-making actually looks like
Modernisation works best when decision-making is made explicit and treated as a deliverable in its own right. In practice that means agreeing, before the build, on three things:
- Who decides what. Not a committee, but named owners for named classes of decision, with the authority to make the call and the accountability for living with it. Escalation paths for the genuinely contested few, and autonomy for the rest.
- Which trade-offs are acceptable. Every modernisation involves trades: speed against completeness, cost against optionality, what to carry forward against what to retire. Naming the acceptable trades up front stops each one from becoming a fresh standoff mid-project.
- What success actually looks like. A concrete, observable definition (“the order system processes the same volume with half the manual reconciliation”), not “a modern platform.” If you cannot describe done, you cannot tell whether you are getting closer to it.
These look like governance questions, and they are. But they are also the most consequential engineering decisions on the table, because they determine whether the architecture ends up clean or ends up carrying the weight of every avoided choice.
Decide on purpose, not by default
The failure is rarely a bad decision. It is the absence of a decision: the choice made by default, by deadline, or by whoever shouted loudest, rather than on purpose. This is the discipline that European engineering practice tends to take seriously, and it is the part of modernisation we insist on getting right before any code is written, because it is the cheapest possible moment to fix.
If you are weighing a modernisation programme and the hardest questions are still “who actually decides this?” and “what are we explicitly choosing not to do?”, that is not a sign you are behind. It is a sign you are looking in the right place. Talk to TrueForge and we will work through the decisions before they harden into architecture.