API-led integration is bought for reuse. Whether the reuse happens is decided by how the interface was specified, not by the platform it runs on.
A modern integration is more than a successful API call. It has an owned contract, an error path, a retry strategy, and a business process that can recover when one system is unavailable.
Most integration debt is not caused by bad engineering. It is caused by applying one pattern to every need, usually the pattern the team was most comfortable with when the first project started.
This table is the correction. Each row describes a real need, the pattern that fits it, the pattern teams reach for instead, and what the wrong choice costs later.
Fragmented enterprise application environments
ERP, PLM, CRM, quality, maintenance, warehouse, a supplier portal and several things built in-house. The count is rarely known precisely, which is itself the first finding.
Point-to-point integrations and technical debt
Each one was the quickest option at the time and each was correct in isolation. The cost is not in any one of them, it is in the dependency map nobody holds.
Inconsistent API standards and governance
Three teams, three authentication approaches, three error conventions and three versioning schemes. Consumers then write three clients, and the fourth team writes a fourth.
Manual business process handoffs
A process that crosses four applications and is held together by two people and an inbox. It works, nobody has measured its error rate, and it is invisible in every system diagram.
Data duplication and inconsistent records
The same customer, supplier or material in several systems, each slightly different, with no agreement on which one is right. Integration will propagate this faster rather than resolve it.
Limited application interoperability
Applications chosen well for their own purpose and never assessed on whether they expose what the next process needs. The interface quality is rarely in the selection criteria.
Legacy applications without modern APIs
Older systems with a database, a file drop and nothing else. An adapter with a proper contract in front of it is the answer. Direct database access is the thing that breaks at the next upgrade.
Complex hybrid and multi-cloud integration
Cloud applications, on-premises plant systems and a data centre in between. The network path and the identity model are usually harder than the integration.
Integration scalability and maintainability challenges
The estate grows and nothing is ever retired, so the maintenance effort rises until it consumes the team that was supposed to be building new things.
Limited API visibility, security and lifecycle management
Nobody can list the APIs, who consumes them, or which ones nothing calls any more. The last of those is the cheapest improvement available and almost nobody looks.
An application inventory tells you what you have. A business process tells you what has to work. Integration programmes organised around the inventory produce connectivity. Programmes organised around processes produce outcomes, and they finish, because a process has an end.
Step 1
Enterprise application landscape assessment
What exists, what each system owns, and what each exposes. Including the things that are not officially applications: the scheduled job, the shared spreadsheet, the file drop.
What exists, what each system owns, and what each exposes. Including the things that are not officially applications: the scheduled job, the shared spreadsheet, the file drop.
Step 2
Business workflow and integration dependency mapping
The processes that matter, end to end, with every handoff marked and the manual ones marked as manual. The manual handoffs are usually where the business rule lives.
The processes that matter, end to end, with every handoff marked and the manual ones marked as manual. The manual handoffs are usually where the business rule lives.
Step 3
API and integration maturity evaluation
What standards exist, what is enforced, and the gap between the two. Published standards that nothing checks are not standards.
What standards exist, what is enforced, and the gap between the two. Published standards that nothing checks are not standards.
Step 4
Enterprise integration architecture design
A pattern assigned per handoff using the table in section 2, rather than one pattern applied to everything.
A pattern assigned per handoff using the table in section 2, rather than one pattern applied to everything.
Step 5
API standards and governance definition
Authentication, error conventions, versioning, naming and the contract format. Small, enforced, and checked in the pipeline rather than in a review meeting.
Authentication, error conventions, versioning, naming and the contract format. Small, enforced, and checked in the pipeline rather than in a review meeting.
Step 6
Application and data model mapping
A canonical model per domain, derived from the flows that exist. The enterprise-wide version of this is discussed on the Data & Application Integration page and is not attempted here.
A canonical model per domain, derived from the flows that exist. The enterprise-wide version of this is discussed on the Data & Application Integration page and is not attempted here.
Step 7
API development and integration implementation
Built with the idempotency and retry behaviour decided per interface up front, not added after the first duplicate.
Built with the idempotency and retry behaviour decided per interface up front, not added after the first duplicate.
Step 8
Integration testing and security validation
Contract tests that both sides run, plus load testing at the real peak and a security review before exposure rather than after.
Contract tests that both sides run, plus load testing at the real peak and a security review before exposure rather than after.
Step 9
Deployment, monitoring and lifecycle management
With the consumer register populated from day one, because you cannot manage a lifecycle without knowing who depends on each interface.
With the consumer register populated from day one, because you cannot manage a lifecycle without knowing who depends on each interface.
Step 10
Continuous API and integration optimisation
Including deliberate retirement. An estate with no retirement mechanism only grows, and the uncalled interface is the cheapest thing to remove.
Including deliberate retirement. An estate with no retirement mechanism only grows, and the uncalled interface is the cheapest thing to remove.
For each item the reuse position is stated plainly, because about half the things in this list are usually built once for one consumer and that is the correct decision.
Enterprise API development
Interfaces built to a contract, versioned and documented. Reusable where the three conditions in section 3 are met and specified as an integration where they are not.
API-led application integration
Layered interfaces separating system access from process logic, which is genuinely valuable where several processes touch the same system and overhead where only one does.
REST and SOAP API integration
Both, because enterprise estates contain both and replacing a working SOAP interface because it is unfashionable is a cost with no benefit.
Event-driven application integration
An event published once and consumed independently. This is where reuse actually happens most reliably, because a new consumer requires no change to the producer.
Application workflow orchestration
Multi-step processes with state, compensation and a visible position for every in-flight instance. Required wherever a process crosses systems and can fail halfway.
Legacy application API enablement
An adapter with its own contract in front of a system that has no interface, so the legacy system can later be replaced without every consumer changing.
Enterprise data synchronisation
Keeping records aligned where one system is authoritative. Where two want to write, that is a system of record decision before it is an engineering one.
SaaS and cloud application integration
Using each vendor’s interfaces, with their rate limits and their outage behaviour designed around rather than discovered. Vendor rate limits are the most common cause of a working integration failing at month end.
B2B and supplier application connectivity
Customer and supplier connectivity, including EDI where it is in use, with the partner’s capability as a design constraint rather than an assumption.
API gateway and API management
Authentication, rate limiting, routing and observability in one place. Worth it once you have a real portfolio, and premature where you have four interfaces.
Integration microservices and reusable connectors
Components built once and configured per use. Reusable connectors are the one thing in this category where reuse reliably happens, because the variation is configuration rather than contract.
The pattern is named for each, from the table in section 2, and so is whether it is genuinely a reuse candidate. Several are not, and saying so is the point.
ERP to CRM integration
Customer, order and delivery status moving between the two.
ERP to supplier portal integration
Purchase orders out, confirmations and documents back.
Procurement and supplier workflow integration
Requisition, approval, order and receipt across systems.
Manufacturing customer portal integration
Order status, documentation and delivery visibility for customers.
PLM to enterprise application integration
Engineering releases reaching manufacturing, procurement and quality.
Quality and compliance application connectivity
Inspection, nonconformance and document control linked to transactions.
Enterprise document and workflow integration
Documents and approvals attached to business records.
Order to cash process integration
Order, production, despatch and invoice across systems.
Procure to pay process integration
Requisition through to payment, including the three-way match.
Cross-application workflow automation
Handoffs currently held together by people and an inbox.
Integration standards documents are usually long, thorough and ignored. A short set that is checked automatically at build time changes behaviour, and a long set that is checked in a design review does not.
API-led integration architecture
Layered separation of system access from process logic, applied where several processes share a system and skipped where only one does.
REST, SOAP, GraphQL and web services
Chosen per interface. GraphQL where a consumer needs to shape its own query, REST for most things, SOAP where the counterparty requires it.
API gateways and management platforms
Authentication, rate limiting, routing and observability centralised. Justified by portfolio size rather than by architectural preference.
Event-driven architecture and message brokers
Events published once with delivery guarantees stated per topic, and a dead letter path so an unprocessable message is visible rather than silently dropped.
Microservices and integration services
Where independent deployment and scaling are genuinely needed. A distributed system built for an integration estate that did not require one is a cost that arrives every month.
iPaaS and enterprise service bus connectivity
Working with the platform you run. Whether to replace it is the subject of the Integration Platform Modernization page and is not assumed here.
OAuth 2.0, OpenID Connect and API authentication
Standard mechanisms, with service-to-service and user-delegated access kept distinct, and credential rotation designed in rather than deferred.
Canonical data models and transformation
Per domain, from the flows that exist, extended when a new flow needs it.
Hybrid and multi-cloud integration
Cloud applications with on-premises plant systems is the normal shape. The network path and the identity model usually take longer than the interfaces.
CI and CD and API lifecycle management
Contract tests, automated standards checks and a documented deprecation path, with the consumer register as the input to any change notification.
Governance defines who may change an interface, how exceptions get resolved, and how production continuity is protected. Everything below serves one of those three.
Every control below depends on an inventory of interfaces and their consumers. Most organisations do not have one, which is why the lifecycle controls in this category are usually aspirational.
API security and authentication
One mechanism, per-consumer credentials, rotation designed in, and no shared credential across consumers. A shared key means a revocation affects everybody.
API authorisation and access policies
Authorisation decided by the system that owns the data rather than at the gateway. A gateway that authenticates and does not authorise gives a false sense of control.
API versioning and lifecycle governance
A version policy agreed before publication, a consumer register maintained, and deprecation notified to named consumers rather than announced generally.
Data protection and encryption
In transit always, at rest where the data warrants it, and with pricing, supplier terms, formulations and process parameters restricted at the interface rather than only at the application.
Integration audit logging and traceability
What was called, by whom, with what result, retained so that a business record can be traced back to the call that created it.
API contract and schema governance
The contract is the agreement. Changes go through the version policy, and contract tests run on both sides so a breaking change is caught in a pipeline rather than in production.
Error handling, retries and idempotency
Decided per interface before build, per the sub-section in section 5. This is the control that prevents the most expensive failures in this category.
Rate limiting and traffic management
Protecting the provider from its consumers, and respecting the limits that external vendors impose on you. The second is the one that causes month-end failures.
Integration change and release management
Interface changes released like application changes, with the counterparty retesting. A change made on one side only is the most common cause of an integration outage.
Third-party and supplier API governance
An external dependency is an availability dependency. Each one assessed for its stated availability, its rate limits, its change notice period and what your process does when it is down.
Per-interface measures tell you whether each one is healthy. Estate-level measures tell you whether the programme is working, and only one of the two predicts next year’s cost.
API availability and response time
Per interface, at the percentile the consumer experiences, against an agreed target rather than a general one.
Integration throughput and latency
At the real peak, with peak defined by the business cycle: month end, a campaign, a seasonal run.
API error and failure rates
Split by cause: a client error, a provider error and a timeout need different owners and are usually reported as one figure.
API consumption and adoption
Calls per consumer per interface. This is the measure that tells you whether reuse happened, which is the whole premise of the investment.
Integration transaction success rates
End to end at the business level, since every individual call can succeed while the business process still fails to complete.
API dependency and service health
Including external dependencies, with their availability tracked separately because you cannot fix them and you do have to plan around them.
API gateway and platform performance
Platform capacity against portfolio growth, which is a capacity planning input and the thing that fails quietly as the estate expands.
Integration incident resolution
Time to detect and to resolve, and the share of incidents caused by a change rather than a fault. A high change-caused share means the release process needs attention, not the engineering.
API lifecycle and technical debt reduction
Interfaces retired, versions withdrawn and consumers migrated off old versions. The estate-level measure that matters most.
Continuous integration optimisation
Maintenance effort as a share of integration capacity. When that share rises year on year, the estate is accumulating faster than it is being managed, and that is the number to put in front of a board.
Connected enterprise applications, with the processes that cross them completing without an inbox in the middle
Faster business process integration, mostly from reusable connectors and published events rather than from an API layer as such
Reduced point-to-point complexity, which requires retirement as well as replacement. Without retirement you have both
Improved application interoperability, limited by what each application actually exposes, which is not something integration can fix
Reusable enterprise APIs where the three conditions in section 3 are met. Where they are not, a well-built integration, honestly labelled
Scalable application integration, evidenced by maintenance effort as a share of capacity holding steady or falling rather than rising
If an API programme has delivered interfaces and no reuse, the cause is almost always a missing product owner or a missing second consumer. Both are organisational, and both are cheaper to fix than the platform.
CaliberFocus builds enterprise application integration judged on reuse rather than on architecture. We assign a pattern to each integration need, specify every API against a second consumer or build it honestly as an integration, decide idempotency per interface before build, and enforce a small set of standards in the pipeline rather than in a document.
- A pattern chosen per need rather than one applied to everything
- Every API tested against the three conditions for reuse
- Idempotency decided per interface before anything is built
- A consumer register, and retirement of interfaces nothing calls
Security & Compliance
