The integration problem: why digital transformation stalls in frontier markets
Most transformation programmes fail at the seams, not the strategy. A view from inside multi-year modernisation work with regulated institutions.
K. Mensah
Group Chief Technology Officer
There is a well-worn narrative that digital transformation in frontier markets fails because of ambition — that institutions attempt too much, too quickly, with too little capability. In our experience running multi-year modernisation programmes for banks, regulators and industrial operators, that diagnosis is wrong. Programmes rarely fail on ambition. They fail at the seams.
The seam is the interface between the new system and everything the institution already runs: a core banking platform from 2004, a regulatory reporting process that lives in spreadsheets, a branch network with intermittent connectivity, and a set of undocumented operational conventions that no architecture diagram captures. New systems are designed against the documented state. They are then deployed into the actual state.
Our approach inverts the sequence. Before any target architecture is drawn, we instrument the existing estate and observe it for a full reporting cycle. What emerges is invariably different from what was described — reconciliation processes that exist only in one person's routine, data flows that bypass the systems of record entirely, tolerances that have quietly become policy.
Only then do we design. And the design constraint we apply most aggressively is degradation behaviour: what happens when connectivity drops, when a dependency is unavailable, when the queue backs up. In markets where those conditions are normal rather than exceptional, a system that assumes availability is a system that will fail in production and be blamed on the market.
The second constraint is capability transfer. A transformation programme that leaves behind a system the institution cannot operate has not transformed anything — it has created a dependency. We contract explicitly for handover: paired delivery teams, documented runbooks, and a defined period during which the client's engineers own production with our support rather than the reverse.
None of this is novel engineering practice. It is simply the practice applied honestly to conditions as they are. The institutions that succeed are not the ones with the largest budgets. They are the ones that permitted an accurate description of their own systems before committing capital to replacing them.