Most integration strategies are written before anyone knows what is actually running. The slide deck talks about a target architecture, a move to cloud-native integration, an API-first approach, maybe a decommissioning wave. Then the first migration project starts and the team discovers 400 interfaces nobody documented, three RFC destinations pointing at a system that was retired two years ago, and an IDoc flow that a business unit quietly depends on for month-end closing.
The gap is not ambition. It is evidence. A strategy that cannot name its own objects is a statement of intent, and intent does not survive contact with a real landscape.
Four questions a strategy has to answer
Before target pictures and roadmaps, a strategy needs answers to four plain questions:
- What exists? Every interface, across every technology, including the ones that were never part of a central middleware.
- What is it used for? Which business process, which system pair, which data object.
- What is actually alive? Traffic, not documentation.
- Where should it go? A target integration style per interface, with a reason attached.
Each question is cheap to ask and expensive to answer without tooling. That is the problem the Integration Cockpit is built for.
Discovery has to cover the whole estate
Integration landscapes are rarely contained in one place. A typical SAP customer runs flows through Integration Suite, still has PI/PO in production, and carries a long tail of point-to-point connections that never touched middleware at all: RFC and BAPI calls, IDoc and ALE partner profiles, SOAP services registered in SOA Manager, OData v2 and v4 services, ICF nodes, RAP-based services, AIF interfaces, event-based flows, and third-party connectors.
If discovery stops at the middleware, the resulting picture is not wrong so much as misleadingly incomplete. The interfaces you can see get governed, and the ones you cannot see become the reason the migration slips.
The Cockpit reads each of these technology families where it actually lives, in the backend configuration and runtime data, and normalizes the result into one model. The value is not that any single extraction is difficult. It is that the extractions are repeatable, scheduled, and comparable across systems, so the inventory stays current instead of aging into another stale Excel file.
Interfaces are technical, integrations are not
A raw inventory of technical interfaces is necessary and not sufficient. Business stakeholders do not fund the decommissioning of an RFC destination. They fund the reliability of order-to-cash.
This is why the Cockpit separates technical interfaces from end-to-end integrations. An interface is one technical hop. An end-to-end integration is the business-meaningful chain across hops: sender system, middleware steps, receiver system, and the data object that travels. One end-to-end integration often spans several interfaces of different technologies, which is exactly why it is invisible in any single tool’s monitoring view.
Once integrations are modelled at that level, strategy conversations change. Instead of debating whether to keep a protocol, you can ask which business capabilities depend on a platform you intend to retire, and how many of them are single-threaded through it.
Use evidence to decide what to keep
The fastest strategic win in most landscapes is not migration. It is deletion.
When you combine the inventory with runtime usage, the estate usually splits into three groups: interfaces with steady traffic, interfaces that once ran and have been silent for months, and interfaces that were built and never used at all. The second and third groups are frequently a large share of the total. Every one of them carries documentation debt, security surface, licence weight, and migration effort that nobody has questioned because nobody could see the pattern.
Usage data converts a political argument into a factual one. “We might still need it” is hard to refute in a meeting and easy to refute against eighteen months of zero traffic and a named business owner who confirms it.
Inventory tells you what exists. Governance asks whether it is acceptable
Once objects are known and usage is measured, the next layer is judgement. Three properties carry most of the weight in an SAP landscape, and all three are machine-readable, so each can become a standing check instead of a review meeting.
Adapter
Record the adapter or protocol on both the sender and receiver side, including the adapter version.
What to check: flows pinned to deprecated adapter versions, adapter types outside the approved list, file-based exchange where a service already exists, ProcessDirect chains that hide coupling between flows, commercial third-party adapters with licence implications, and adapters that simply have no counterpart on the target platform.
Why it is strategic: the adapter distribution across the estate is the best single predictor of migration effort. It separates the flows that can be re-platformed almost mechanically from the ones that need a redesign, before anyone opens a single iFlow.
Authentication
Record the mechanism per interface: basic authentication with a technical user, client certificate and mTLS, OAuth 2.0 including the grant type, API key, principal propagation, or none.
What to check: basic authentication on externally reachable endpoints, one technical user shared across dozens of interfaces, certificates and credentials approaching expiry, inbound ICF or OData services exposed without adequate protection, secrets kept outside the credential store, and credentials with no recorded rotation.
Why it is strategic: authentication debt comes with dates attached. Certificates expire on a known day and platform providers retire weak mechanisms on published timelines. Grouping the estate by mechanism turns a vague security concern into a funded workstream with a finish line.
Complexity
Score the flow itself: number of steps and branches, mappings, scripts and their size, whether logic sits in script collections or embedded in the flow, externalized parameters, persistence through Data Stores or JMS queues, error handling and retry behaviour, number of receivers.
What to check: flows above a complexity threshold with no documentation or test coverage, business logic buried in scripts that belongs in mapping or in the application, one flow serving many receivers, exceptions swallowed silently, and missing dead-letter handling where queues are in use.
Why it is strategic: complexity is the multiplier in every migration estimate and the main source of key-person risk. Ranked by complexity, the estate tells you where refactoring pays and where a rewrite is cheaper than a migration.
Make the checks standing, not seasonal
The value appears when every object is scored on every refresh against the same rules: an adapter whitelist, an authentication target, a complexity threshold. New objects are evaluated when they are created. Exceptions get an owner and an expiry date instead of a fresh discussion each quarter. The strategy then reports a compliance rate rather than a list of principles.
Connect the picture to the systems that govern it
An inventory that only lives in an integration tool will be ignored by the people who run enterprise architecture and service management. So the model has to travel.
Two targets matter in most SAP-centric organisations. In SAP LeanIX, interfaces and integrations attach to the application portfolio, which lets architects see integration dependencies alongside application lifecycle decisions. In ServiceNow, the same objects map onto CSDM, so integrations and interfaces appear as services, systems as business applications, and data sources as technical services, with relationships modelled where discovery can actually establish them.
The point of the mapping is not tool tidiness. It is that architecture decisions, change management, and incident handling all start referring to the same objects. That shared reference is what makes a strategy enforceable rather than advisory.
Turning a picture into a plan
With a current, usage-backed, business-mapped inventory, the roadmap almost writes itself:
- Retire what has no traffic and no owner willing to defend it.
- Re-platform what has traffic and a clean one-to-one mapping to a target integration style.
- Redesign what only exists in its current shape because of a constraint that no longer applies, such as batch file exchange that was built before event-based options were available.
- Leave alone, deliberately and with a documented reason, the flows where the cost of change exceeds the benefit.
Sequencing then follows dependency, not preference. Migration waves can be cut by business domain, by system pair, or by receiving application, and the effort estimate rests on counted objects instead of a percentage guess.
Start with facts, not frameworks
Integration strategy has no shortage of frameworks. What it usually lacks is a maintained, complete, technology-agnostic view of the landscape it is supposed to govern, refreshed often enough that people trust it.
That is the role the Integration Cockpit plays: a management plane over SAP and non-SAP integration, where discovery, business context, usage, and governance targets sit in one model. The strategy work is still yours. The facts underneath it stop being the bottleneck.
