Series: Rethinking
“No plan of operations extends with any certainty beyond the first contact with the main hostile force.”
— Helmuth von Moltke the Elder
Moltke was talking about armies, but the observation applies with uncomfortable precision to enterprise technology programmes. Headquarters designs the system. Headquarters approves the budget. Headquarters rolls it out. And then the system meets the operational reality at the edges of the organisation, and the reality does not comply.
There’s an even punchier quote from Mike Tyson: “Everyone has a plan ’till they get punched in the mouth.”
The pun(ch) was intentional.
In 1994, the CEO of Lloyd’s of London addressed the market on his annual business plan. Among the priorities: “accelerate to full electronic processing” and “streamline Lloyd’s business processes.” The language was confident and mandate was clear. The three-hundred-year-old insurance market was going to modernise its operations.
Three decades later, it has not happened.
We cannot fault them for not trying hard. In the early 2000s, Lloyd’s built Kinnect: an internet-based risk data platform designed to digitise how brokers and underwriters exchanged information. Kinnect attracted just 22 customers across brokers and insurers, never delivered its promised two-way data exchange capability, and was shut down in 2006 when Lloyd’s own Franchise Board concluded that the platform was “not optimal in ensuring more efficient business processes.” In the 2010s, the Target Operating Model consumed an estimated £70 million with little to show for the outlay. In 2018, Lloyd’s embraced blockchain as the next transformative force; multiple proofs of concept and at least one high-profile joint venture later, the blockchain commitments quietly faded; the flagship platform itself eventually abandoned the technology and pivoted to cloud.
Then came their most ambitious attempt: Blueprint Two. Launched in 2020, it set out to replace core processing infrastructure dating back four decades. It was a multi-year, multi-hundred-million-pound programme with full institutional backing. The original target was full digital adoption by mid-2024. That deadline slipped repeatedly, with completion pushed out to 2028. By early 2026, the programme had reportedly been paused, with trade press reporting that the market engagement team had been disbanded.
The most telling response came from outside the programme. One industry observer noted that most firms would barely notice, because the market had moved on a while ago.
This is not a story about Lloyd’s specifically. Lloyd’s is simply a public, expensive, and thoroughly documented example of a pattern that repeats inside every large enterprise I have worked with, across insurance, banking, and logistics over multiple decades. Headquarters designs a system for the centre. The periphery, the regional offices, the local operations, and the counterparty-facing teams, adapts around it. The adaptation layer grows back every time: reconciliation spreadsheets, local applications, additional staff whose sole function is to synchronise data between what the global platform expects and what the local market demands. Different decade, different system, same outcome.
A caveat is necessary here. This pattern does not apply to every industry equally. It is most acute in industries where business is conducted at a granular level across regions, geographies, and countries, where operations must interact with prevailing local ecosystems rather than simply executing a centrally defined process. Insurance is a prime example: underwriting practices, regulatory regimes, broker relationships, and settlement conventions vary materially by jurisdiction. Banking, logistics, and financial intermediation share similar characteristics. In these industries, the periphery is not a simplified version of the centre; it is a different operating environment entirely, shaped by local regulation, local counterparties, and local market conventions that evolved independently.
There are industries where a central system genuinely can control end-to-end operations, where the local dimension imposes little variation and the periphery’s role is to execute rather than adapt. The argument that follows is not about those industries. It is about the substantial number of global enterprises where local operational reality is diverse, and where the assumption that a single platform can absorb that diversity has been tested repeatedly and found wanting.
I have never, not once, seen a headquarters-driven system propagate successfully through all the regional and territorial nodes of a global organisation without generating a layer of local workarounds. The pattern is not an anomaly. It is the default outcome.
The Organisational Alibi
When a B2B integration problem is raised with a large global organisation, the kind of problem where transactions between the organisation and its counterparties are still flowing through documents, manual processes, and human intermediaries, the most common institutional response is a deferral:
- “Our digital transformation team is already engaged.”
- “Once our internal systems are sorted out, we’ll address the B2B layer.”
- “We can’t think about external integration until the internal platform is stable.“
The transformation programme becomes an organisational alibi: a way to defer decisions about the integration problem that actually matters by pointing to a programme that will never reach it. This is not because the people involved are dishonest or incompetent. The deferral is structurally sincere: the programme genuinely is underway, it genuinely is consuming enormous resources, and it genuinely does represent the organisation’s best current effort to modernise its operations.
I have encountered this firsthand. In conversations with Lloyd’s market insurers about B2B transaction flow, specifically about how brokers, insurers, and reinsurers exchange data across organisational boundaries, the response was precisely this deferral: we can’t engage with this right now; we’re waiting for HQ’s digital transformation. They were pointing to a programme that would never reach the B2B layer, and that has reportedly been shelved after seven years.
But it will not reach B2B; it never does. Digital transformation, as practised by large organisations, is overwhelmingly internal. It optimises processes within the organisation: claims handling, policy administration, settlement workflows, regulatory reporting. The transactions that flow between organisations, such as broker to insurer, forwarder to carrier, and bank to counterparty, sit outside the programme’s scope, outside its budget, and outside the CIO’s mandate. The promise that “once internal systems are sorted, we’ll address B2B” is structurally false: the internal programme’s completion date recedes as fast as the organisation pursues it, and the B2B problem is not sequential to the internal one. It is orthogonal. Solving one does not advance the other.
There is a second layer to the deferral, and it is more revealing than the first. Press the transformation leaders on integration specifically and you will hear: “Yes, we are working on the integration aspects as well, so until that’s done, we can’t take on something new.” It sounds reasonable. But look at what they actually do. They re-engineer or hard-integrate their most valuable few integration points: the SAP-to-Salesforce connection, the core banking link to the payments gateway, the three or four bilateral flows that justify the engineering cost. Twelve months pass. Twenty-four months. Sometimes longer. And what emerges is a handful of high-value integrations that were already the best-served connections in the enterprise, while the hundreds of smaller integration cases that generate the real operational burden remain completely untouched.
This is the long tail of integration resurfacing inside the transformation programme itself. The long tail, the vast number of small, infrequent integration cases, each individually too expensive to justify a custom build but collectively worth more than the headline integrations combined, is precisely the terrain that the transformation programme cannot reach, because its economics and its architecture are designed for the left side of the curve. The programme invests heavily in the integrations that were already closest to being solved, and the long tail persists exactly as it was before the programme began.
The pattern should sound familiar. It is the same structural failure that Robotic Process Automation was supposed to address a decade ago. RPA’s original promise was that it would handle the long tail: all the small, awkward, low-volume integrations that conventional middleware could never justify. Instead, RPA was redirected toward automating the human workaround rather than closing the integration gap, and the long tail remained (see “How RPA Lost Its Way” for the full trajectory of that misdirection). Now the digital transformation programme repeats the same pattern from a different starting point: invest in the headline cases, defer the long tail, and declare progress. After all these years, following the middleware era, the RPA wave, and the current transformation cycle, the long tail is still there, still generating the same operational burden, still being deferred to the next programme. We are, structurally, on square one.
This matters because the integration gap that generates the most software-driven labour, the manual operation of software interfaces to bridge gaps between systems that should be exchanging data directly, is overwhelmingly in the long tail and at the B2B boundary. Inside an enterprise, at least the high-value system pairs tend to be connected: those are the headline integrations the transformation programme addresses. Between organisations, only the highest-volume bilateral interactions have entrenched interoperability. Everything else is left to humans and documents. The organisational alibi points inward while the problem compounds outward.
The Centripetal Fallacy
The deeper structural issue is not the deferral itself but the architectural assumption that produces it. Headquarters-driven digital transformation is inherently centripetal; it pulls everything toward the centre. A central team designs the system. A central mandate drives adoption. A central budget funds the implementation. The implicit architectural belief is that a single system, designed centrally, can accommodate the full diversity of local operational reality across a global organisation.
Having worked with global enterprises across insurance, banking, and logistics, I have watched this belief collide with reality in every single deployment. The collision always follows the same sequence.
Regulatory diversity. Each country, each territory, each regulatory jurisdiction has requirements that the global system was not designed for. The system handles the common denominator: the subset of regulatory obligations that are similar enough across markets to be standardised. The local specifics, such as the filing formats, the disclosure requirements, and the compliance obligations that are unique to a particular regulator in a particular territory, fall outside the system’s design. They are the long tail of regulatory variation, and a centrally designed platform cannot absorb them without becoming so configurable that it ceases to function as a coherent system.
Market conventions. B2B relationships in different markets follow different conventions. The way brokers submit risks to insurers in London is not the way it happens in Singapore, which is not the way it happens in São Paulo. Document flows, endorsement structures, counterparty expectations, payment cycles, dispute resolution processes: these are not configuration settings that can be toggled in a global platform. They are cultural, contractual, and historical realities that have evolved over decades of local practice. A central system can ignore them, but it cannot accommodate them.
The adaptation cascade. When the headquarters system cannot accommodate local reality, the local office does not push back. That fight was lost years ago, during the steering committee meetings that the local operations head was not invited to, or during the vendor selection process that optimised for the centre’s requirements. Instead, the local office adapts. It builds a shadow system: a local application, a reconciliation spreadsheet, a manual process that bridges the gap between what the headquarters system expects and what the local market demands. It hires additional people to synchronise the local system with whatever can be extracted from or fed into the global platform. The digital transformation has not reduced manual work. It has relocated it: from the centre, where it was visible and budgeted, to the periphery, where it is invisible to the people who approved the programme.
This is the centripetal fallacy: the belief that a function which is inherently centrifugal, such as local market operations, local B2B relationships, and local regulatory compliance, can be served by a centripetal architecture. The result is predictable. The centre sees one licence, one implementation, one support contract. It sees cost advantage in centralisation. What it does not see is the distributed cost at every local node: additional staff, parallel software licences, reconciliation hours, compliance risk from manual processes, and the quiet attrition of experienced operations people who grow tired of serving as living middleware between a system designed in another country and a market that operates by different rules.
The digital transformation did not eliminate the workaround layer. It relocated it: from the centre, where it was visible, to the periphery, where it was not.
Why This Keeps Happening
This is not a failure specific to any particular technology generation. The Lloyd’s story makes that clear: Kinnect, Target Operating Model, blockchain, Blueprint Two, each a decade apart, each failing for structurally identical reasons. I have watched the same cycle across ERP rollouts in the early 2000s, core platform replacements in the 2010s, cloud-native deployments, and now the current wave of AI-augmented enterprise systems. Each generation promises that this time the technology is flexible enough, configurable enough, intelligent enough to accommodate local variation. Each generation discovers the same structural limit.
The pattern persists because the decision-makers, such as the group CIO, the global CTO, and the transformation programme director, are evaluated on consolidation, standardisation, and cost reduction at the centre. These are legitimate objectives. Consolidated reporting, unified compliance oversight, standardised risk management: these functions genuinely benefit from centralisation. The problem is not that the centre wants these things. The problem is that the same architectural vehicle, the single global platform, is expected to deliver both the centripetal functions (which it can serve well) and the centrifugal functions (which it structurally cannot).
A system designed to serve the centre’s view of the world will always be surprised by the periphery’s reality.
The metric rewards the architecture that fails. A CIO who consolidates twelve regional platforms onto one global system can report reduced licence costs, simplified vendor management, and a unified data model. The distributed cost of local workarounds, such as the spreadsheets, the additional staff, and the reconciliation processes, does not appear on the CIO’s scorecard. It appears on the regional operations budget, where it is categorised as “local operational expense” rather than what it actually is: the cost of an architectural assumption that did not survive contact with local reality.
This is where the current AI cycle risks repeating the pattern at an even larger scale. The promise is that AI will make the global platform adaptive: that machine learning will enable the system to accommodate local variation without requiring manual configuration. It is a compelling vision. But the structural challenge is not configuration. It is the diversity itself: the fact that local markets, local regulators, and local counterparties operate differently not because the global platform lacks a toggle, but because the world is genuinely heterogeneous, and a system designed to serve the centre’s view of the world will always be surprised by the periphery’s reality (see “Rethinking AI for Automation” for a deeper examination of where AI is currently being aimed in enterprise operations, and why the target matters more than the technology).
The B2B Blind Spot
Even if the internal transformation succeeded perfectly, with every internal process digitised, every regional node running the same system, and every compliance obligation met within the platform, it would not solve the B2B integration problem. Transactions between organisations cross boundaries that no internal system can bridge: the broker’s submission to the insurer, the forwarder’s booking with the carrier, the bank’s settlement instruction to the counterparty. These flows involve different organisations with different systems, different data models, different process conventions, and, critically, different incentives. No internal platform, however well implemented, can dictate how an external counterparty structures its data or conducts its operations.
Consider the mechanics. A global insurer completes its internal transformation. Its claims system, policy administration, and reinsurance management all run on a unified platform. But the brokers who submit risks still send bordereau files in formats that vary by market. The reinsurers who accept those risks have their own systems, their own data structures, their own settlement conventions. The regulators who oversee the process have jurisdiction-specific filing requirements that change on their own timeline, not the insurer’s. The internal transformation has made the insurer’s internal processes more efficient. It has not changed a single thing about how the insurer transacts with the world outside its walls.
The internal transformation programme is, by definition, inward-facing. The integration gap that matters most, the one between organisations, is architecturally outside its scope. “We can’t think about B2B until internal is sorted” is not a sequencing decision. It is a category error. The internal programme addresses process efficiency within the organisation. The B2B problem addresses transaction flow between organisations. They are different problems, operating at different architectural layers, requiring different solutions.
This is where the deferral collapses. The transformation programme that was supposed to be the precondition for addressing B2B turns out to be irrelevant to it. The organisation that waits for internal modernisation to be “complete” before addressing inter-organisational integration will wait indefinitely, because internal modernisation is never complete, and the B2B problem is not downstream of it. The long tail of integration, the vast number of small, infrequent transaction flows that are individually too expensive to automate but collectively enormous, lives overwhelmingly at the inter-organisational boundary. No amount of internal platform consolidation shortens it (for where the real competitive assets live in this landscape, see “Rethinking the Data Moat”).
The Separation That Works
The answer is not to abandon central systems. It is to stop asking them to do something they structurally cannot.
What the centre is good at is genuinely valuable: group-level reporting, consolidated analytics, compliance roll-up across jurisdictions, regulatory aggregation, risk oversight, capital allocation visibility. These are inherently centripetal functions; they benefit from a single view across the organisation. A global insurance group needs to see its aggregate exposure. A multinational bank needs consolidated risk reporting. A logistics operator needs end-to-end shipment visibility. Central systems serve these needs well, and should continue to.
What the periphery needs is fundamentally different: systems designed for local market reality. Local regulatory requirements. Local counterparty conventions. Local document flows. Local B2B relationships with brokers, reinsurers, agents, regulators, and counterparties who operate according to local practice. These are inherently centrifugal functions; they must accommodate diversity, not standardise it away.
The architectural insight is that these two sets of requirements can be separated, and must be. The centre runs what it is good at: reporting, compliance, risk, analytics. The periphery runs what the local market demands. And between them sits an intelligent mediation layer that reconciles the two: rolling up what headquarters legitimately needs without requiring every local operation to run on headquarters’ system. The mediation layer absorbs the translation burden: converting local data into the formats the centre requires for reporting, and converting central mandates into the operational reality the local market can execute.
This is architecturally the same principle as the onus to comply in integration design: the question of who bears the burden of making integration work. In the centripetal model, the onus falls on every local office to comply with the global platform’s design constraints. In the separated model, the onus falls on the mediation layer, which adapts, translates, and reconciles so that neither the centre nor the periphery must abandon what it does well. The centre gets its consolidated view. The local operation gets systems that fit its market. The mediation layer handles the structural tension between them.
With AI, this mediation layer becomes significantly more capable. It can interpret local data structures and translate them into the centre’s reporting formats without requiring manual mapping. It can adapt to regulatory changes in individual jurisdictions without requiring a global platform upgrade. It can mediate between the local office’s counterparty conventions and the centre’s compliance requirements, maintaining governance without enforcing uniformity. The same semantic understanding that AI currently applies to extracting data from documents could be applied to mediating between systems that serve different masters within the same organisation, and between organisations whose transaction flows have resisted standardisation for decades (see “Rethinking the Transaction” for a concrete picture of what this mediation looks like when it works).
The Pattern, Revisited
Lloyd’s has spent thirty years and hundreds of millions of pounds attempting to digitise its market from the centre. Four major programmes. None delivered what was promised. And after each one, the market adapted: brokers and underwriters building their own tools, their own workarounds, their own ways of getting transactions done despite the centre’s system rather than through it. The periphery moved on. The centre started again.
The question is not whether the next generation of technology will finally be configurable enough. The question is whether the assumption itself will be examined: that one system, designed at the centre, can serve both the centre’s needs and every periphery’s reality simultaneously. Thirty years of evidence, at Lloyd’s and at every global enterprise that has attempted the same thing, says it cannot.
The organisations that separate what must be central from what must be local, and build an intelligent layer to reconcile the two, will stop repeating the pattern. They will let the centre do what it does well, let the periphery operate in its market reality, and invest in the mediation layer that makes both possible without requiring either to compromise.
The rest will be on their fourth round in a decade. At Lloyd’s, they already are.
