A reference for the frameworks, terms, and concepts used across this blog. Terms coined or defined by the author are marked with ★.
The Author’s Frameworks
★ Box A
The core enterprise software layer — ERP, CRM, billing, compliance, claims management, trade execution, and the integration infrastructure that connects them. Box A is where data processing happens, where business logic lives, and where transactions get authorised. Box A is where value gets created. The term refers not just to individual applications but to the architectural layer as a whole — including the integration between those applications.
★ Box B
The workaround layer. Humans, back offices, BPO centres, RPA bots, and AI agents that exist because Box A’s systems cannot interoperate. Box B bridges the gaps between applications that were never taught to talk to each other. Every generation of technology deployed in Box B — from BPO staff in the 2000s to copilots in the 2020s — has made the workaround more capable without addressing the integration failure that created the need for it.
★ Software-driven labour
The manual or semi-automated operation of software user interfaces to move data between systems that should be exchanging it directly. People and bots working as living middleware, carrying data between screens. The global economy spends upward of $400 billion a year on this. Software-driven labour has two dimensions: integration labour (moving data between systems that cannot interoperate) and logic labour (executing business rules that have never been codified into software).
★ The long tail of integration
The vast number of small, infrequent integration cases that are individually too expensive to justify a custom build but collectively worth more than the headline integrations combined. The long tail is where Box B lives. Conventional integration (middleware, APIs, EDI) handles the high-value head of the curve. The tail — hundreds of smaller connections — is left to humans. This is the terrain that AI should be making economically viable for the first time.
★ The onus to comply
The architectural principle of who bears the burden of enabling integration. Conventional integration places this onus on every participating application — each system must expose an API, adopt a standard, and allow itself to be modified. This is why the long tail never shrinks: the onus is too expensive to carry at scale. UI integration (the technology that became RPA) is the only integration method that removes this onus entirely — the component application does not need to know it is being integrated.
★ The archipelago
A metaphor for the enterprise software landscape: islands of capability (individual applications) with water (integration gaps) between them. Each island works well on its own. The costly problem is what happens in the water.
★ Fork and staircase
How a business process degrades from automated to manual at each point where systems are not integrated. The process runs as a “staircase” (automated, step by step) until it hits a gap between two systems. At the gap, the process “forks” — it drops out of automation and into manual handling. Someone sits at a screen and carries the data across. The process may re-enter automation on the other side, or it may stay manual. Each fork is an integration failure wearing a human costume.
★ Centripetal / centrifugal
A framework for understanding why headquarters-driven digital transformation fails at the edges. Centripetal functions — reporting, compliance, risk aggregation — naturally belong at the centre and benefit from centralised systems. Centrifugal functions — local operations, B2B transactions, regulatory specifics, counterparty-facing workflows — naturally belong at the periphery and resist centralisation. The centripetal fallacy is the assumption that a single centrally designed system can accommodate the full diversity of local operational reality. Introduced in Rethinking Digital Transformation.
★ The missing application
The business logic that resides in the heads of human operators but has never been written into software. Operators who apply rules, spot patterns, pre-emptively restructure data, and handle exceptions are performing the function of an application that was never built. Their rules are its business rules. Their exception-handling is its error-handling logic. AI should be used to build this application — not to mimic the human who is performing its function manually. Introduced in The $400 Billion Workaround.
★ The organisational alibi
When a digital transformation programme becomes a reason to defer action on the integration problem. “Once our internal systems are sorted out, we will address B2B” — but the internal programme never reaches B2B, and its completion date recedes as fast as the organisation pursues it. The programme’s existence creates the appearance of progress while the actual problem compounds. Introduced in Rethinking Digital Transformation.
★ The composite integration stack
The architectural vision of Box A when it contains all available integration methods working as complementary layers: conventional integration (APIs, middleware, EDI) for the high-volume, stable exchanges; UI integration with AI (the promoted RPA capability) for the long tail; and semantic mediation (LLM-powered understanding of what each system means) translating between applications in real time. These are not competing methods — they are layers of a single integration architecture. Introduced in Rethinking AI for Automation: Copilot Is Not the Architecture.
★ Flywheel moat vs execution moat
Two fundamentally different types of competitive advantage. A flywheel moat compounds automatically — the product improves as more data is added, that improvement is visible to users, and users’ engagement generates more data. Search engines and recommendation platforms work this way. An execution moat requires continuous reinvestment of analytical capability, market engagement, and professional judgment. Insurance brokerage, financial advisory, and most knowledge-work intermediaries hold execution moats, not flywheels — a distinction that matters when deciding where to invest in AI and infrastructure. Introduced in Rethinking the Data Moat.
★ Five-layer data ownership
A framework for distinguishing what intermediaries actually hold when they claim to “own” data. The five layers: legal ownership (transferable title), custody (possession under fiduciary obligation), usage rights (contractual, revocable, and scoped), control of capture (who logs it, in what schema), and derived features (outcomes, labels, negotiation patterns). Most of what intermediaries call “their data” falls into custody and usage rights — held under obligation, not owned. Introduced in Rethinking the Data Moat.
Industry and Technical Terms
Agentic automation / Agentic AI
AI systems that do not just assist humans but replace them in executing multi-step workflows. They log into systems, navigate UIs, make contextual decisions, handle exceptions, and coordinate across applications. Architecturally, the question is not whether the agent is capable but where it is deployed — in Box B (as a more capable workaround) or in Box A (as integration infrastructure).
API (Application Programming Interface)
A structured interface that an application exposes to allow other systems to interact with it programmatically. APIs are the primary mechanism of conventional integration. They work well where both sides have invested in building and maintaining them — but they place the onus to comply on every participating application.
BPO (Business Process Outsourcing)
The practice of contracting business operations to third-party providers, typically in lower-cost geographies. BPO centres were the first large-scale response to the integration gap — people bridging systems that could not talk to each other. The BPO industry’s revenue model depends on the continuation of software-driven labour.
Canonicalisation
The traditional integration approach of driving every system toward a common data standard — canonical formats, shared ontologies, and universal schemas. It works for high-volume, stable, bilateral exchanges (SWIFT, EDI, HL7) but cannot touch the long tail because it places the onus to comply on every participating system and organisation.
Copilot
An AI assistant (typically LLM-powered) that sits between the human and the application, augmenting the human’s interaction with the UI. Examples: Microsoft 365 Copilot, GitHub Copilot, Salesforce Einstein Copilot. Copilots make Box B faster without making Box B less necessary.
COTS (Commercial Off-the-Shelf)
Pre-built software products designed for the broadest possible audience — Salesforce, SAP, ServiceNow, Microsoft 365. Mature, heavily supported, and shaped by thousands of customers. The trade-off: configurability constraints and a roadmap you do not control.
CRM (Customer Relationship Management)
Software for managing an organisation’s interactions with customers and prospects. One of the core Box A applications.
EDI (Electronic Data Interchange)
A standardised format for exchanging business documents (purchase orders, invoices, shipping notices) between organisations electronically. One of the earliest B2B integration mechanisms. Works where adoption is widespread; does not cover the long tail.
ERP (Enterprise Resource Planning)
Integrated software platforms that manage core business processes — finance, HR, procurement, supply chain, manufacturing. One of the primary Box A applications.
ESB (Enterprise Service Bus)
Middleware architecture for routing messages between enterprise applications. Part of the conventional integration stack that handles high-value, stable integration cases.
Hyperautomation
A term coined by Gartner to describe the combination of RPA, AI, process mining, and other automation technologies into an integrated approach. In the Box A / Box B framework, hyperautomation orchestrates increasingly sophisticated technology within Box B — making the workaround layer more capable without addressing the integration failures that created it.
IDP (Intelligent Document Processing)
AI-powered extraction of data from invoices, claims forms, shipping documents, and other business documents. Uses LLMs, computer vision, and OCR. The most visible application of AI in Box B — and a prime example of the re-digitisation problem: data that was digital in the sender’s system, de-digitised into a document, and re-digitised using AI at the receiving end.
MGA (Managing General Agent)
In insurance, an entity authorised to underwrite and bind policies on behalf of an insurer or group of insurers. MGAs carry underwriting authority without needing the full capital infrastructure of a carrier. Relevant to the market fragmentation argument in Rethinking AI for Automation: The Real Redistribution.
Middleware
Software that connects different applications or systems, enabling them to communicate and share data. Includes ESBs, message brokers, and integration platforms. Handles the head of the integration curve — the high-value, stable connections. Does not reach the long tail.
Process mining / Task mining
Technology that analyses system event logs and user interactions to map how processes actually execute. Reveals where people spend time, where bottlenecks occur, and where processes deviate from their designed flow. In the Box A / Box B framework, process mining maps the workaround — it shows you the symptoms rather than starting the conversation about the diagnosis.
RPA (Robotic Process Automation)
Software that automates human interactions with computer interfaces — clicking buttons, entering data, navigating screens. Originally built as a UI integration technology (the author’s company, Inventys, pioneered this approach). Renamed and repositioned in the 2010s as a human-action automation tool. The renaming redirected the technology from fixing integration (Box A) to optimising the workaround (Box B). RPA’s core capability — operating application UIs without requiring the application to expose an API — is architecturally unique and is the only integration method that does not place the onus to comply on the component application.
SaaS (Software as a Service)
Software delivered over the internet on a subscription basis rather than installed on local infrastructure. Relevant to the build-vs-buy decision and to the proliferation of point solutions that create new integration gaps.
Semantic mediation
An AI-powered approach to integration where the integration layer understands what each application means — its data structures, business logic, and transaction semantics — and translates between systems in real time without requiring them to adopt a common standard. Instead of canonicalisation (forcing agreement), semantic mediation interprets on the fly. A key capability of AI in Box A.
Straight-through processing (STP)
The automated end-to-end handling of a transaction without manual intervention. The gold standard of operational efficiency. Every fork in the staircase — every point where a process drops from automated to manual — is a failure to achieve STP. The distinction between STP and human-mediated processing is not a difference of speed or cost. It is a categorical difference in operational capability.
SWIFT (Society for Worldwide Interbank Financial Telecommunication)
A cooperative messaging network connecting over 11,000 financial institutions in 200+ countries. Founded in 1973 because banks refused to operate on infrastructure owned by a single competitor. The cooperative, neutral governance model is the positive counterpart to player-led platforms that fail to achieve network adoption (see TradeLens). SWIFT demonstrates that the network, not the infrastructure owner, is the source of value.
UI integration
The technique of connecting applications by interacting with their user interfaces — the same interfaces a human would use — rather than through APIs or middleware. The technology that became RPA. Its architectural significance: it does not require the component application to expose an API, adopt a standard, or know it is being integrated. This property — removing the onus to comply — makes it the only integration method that can reach the long tail without requiring application-level compliance on both ends.