Horizon
The Integrator’s Next Asset Is a Maintained Process Model
Over the next 12–36 months, I expect more integration value to sit in maintaining how a business actually works: its decisions, exceptions and evidence of acceptable outcomes.
Two developments worth reading together
Accenture announced an investment in process-discovery company Within on 23 September. A separate announcement was updated on 30 September to confirm the completion of its McCoy acquisition, adding SAP and managed-service capabilities. The original McCoy announcement was in August; the closing update is the event inside this review window.
These transactions do not prove that the integration market has changed its business model. They do, however, suggest a useful question: where does a delivery partner retain value when more of the software can generate its own code and operate through agents? My working hypothesis is that a maintained understanding of the customer’s processes becomes more valuable than a one-off description of them.
A process model must explain the exceptions
A diagram of the happy path is a limited operating asset. It rarely captures why a particular order needs another approval, which contractual exception overrides the standard policy, or who can resolve a conflict between records. Those details determine whether automation is commercially usable.
A maintained process model would connect activities to decision rights, authoritative data and tested examples of acceptable behaviour. Its value would come from staying correct as the organisation changes. This need not mean a single elaborate platform. A carefully governed set of definitions, decision tables and evaluation cases may be more useful than an ambitious model nobody owns.
Watch the commercial contract
The early signal I would look for is a change in what customers buy after implementation. Does the service agreement fund policy updates, exception analysis and regression evaluation? Or does it still pay mainly for incident response and minor configuration changes? The difference reveals whether process knowledge has become an operating responsibility.
There is also an ownership question. Customers should be able to retrieve their business definitions and test cases in a usable form. A partner can own reusable tooling while the customer retains access to the operational knowledge needed to change suppliers. Otherwise, a valuable service can become an expensive dependency.
Three plausible paths
In one path, application vendors absorb most of this work into their platforms, and integrators specialise in cross-system exceptions. In another, customers build internal process and evaluation teams, buying specialist support when needed. A third path is an ongoing partner service that maintains the process model across several applications.
These paths can coexist. The determining factors are likely to include process uniqueness, the customer’s internal capacity and the cost of a wrong action. I would be cautious about outcome-based fees where neither party can separate the effect of automation from demand, staffing or policy changes. A shared baseline has to come before a shared upside.
What would change my view
I plan to revisit this thesis in six months by looking for named process owners in service contracts, repeatable evaluation after business changes, and customer access to portable process definitions. These are more useful indicators than the number of agents announced.
The thesis would weaken if standard applications handle most exceptions reliably with little customer-specific maintenance, or if maintaining the model costs more than the work it improves. The durable opportunity is not documentation for its own sake. It is a demonstrable reduction in the effort required to keep an automated business process trustworthy.