Lesson 3 of 5
Governance
10 min
Listen to this lesson
Integration governance is not a committee that approves diagrams. It is a small set of mechanisms that make the right thing the easy thing: a catalog everyone uses, standards that are checked automatically where possible, a request process that routes new needs to the right pattern, and clear ownership when something breaks at 02:00.
The integration catalog
The catalog is the single list of every interface, API and event channel in the landscape. It is the backbone of governance because every other mechanism (impact analysis, testing scope, monitoring setup, cutover planning, decommissioning) reads it. A catalog entry that is out of date is worse than none, so ownership of the catalog itself is a named role.
| Attribute | Why it matters | Contoso example |
|---|---|---|
| ID and name | Stable reference across tools and documents | INT-O2C-014 Fleet order intake |
| Business owner / technical owner | Who decides; who fixes | Maria / integration team |
| Systems and direction | Impact analysis for changes and outages | Great Lakes Fleet Services → CMP |
| Style, pattern, platform | Conformance to guidelines | Asynchronous B2B, Cloud Integration |
| Data classification | Security and compliance controls | Commercial confidential |
| Volume and SLA | Capacity, alerting thresholds | 1,200 orders/day; processed within 15 minutes |
| Version and status | Lifecycle: planned, live, deprecated, retired | v2, live; v1 retired after conversion |
| Test and monitoring references | Proof that it works and is watched | Test case set and alert rule IDs |
Minimum catalog attributes. Many teams keep the catalog in an architecture repository and link it to SAP Cloud ALM.
Governing APIs
APIs are products with consumers. Governance means consistent design (OpenAPI descriptions, naming, error formats, pagination), explicit versioning with a deprecation policy, and a runtime layer that enforces policies. In SAP Integration Suite, API Management exposes APIs through API proxies that separate the consumer-facing endpoint from the backend target. SAP Learning describes the runtime as policy-driven: policies such as rate limiting (spike arrest) are attached to APIs to enforce operational limits and quality of service, and APIs are published to a developer hub for consumers.
- DesignOpenAPI description reviewed against API guidelines
- ProxyAPI proxy with authentication, rate limiting and threat protection policies
- PublishProduct published to the developer hub with documentation and terms
- ConsumeConsumers subscribe; usage is visible per application
- Version and retireNew major version alongside; old version deprecated with a date
Governing events
Events need the same discipline, with two extra problems: consumers are invisible to the publisher, and events live on after the moment they describe. Govern them with an event catalog (each event type, its producer, schema, version and known consumers), schema descriptions in an open format such as AsyncAPI, topic naming rules, and a policy for breaking changes. SAP publishes its standard business events on SAP Business Accelerator Hub; custom and derived events for SAP S/4HANA can be built with the ABAP RESTful Application Programming Model, as SAP's Architecture Center notes. Each custom event is a new contract that needs an owner.
Requests, design authority and clean core
New integration needs should enter through a request, not a hallway conversation. Integration Assessment supports this with questionnaires for interface requests (technical view) and business solution requests (business view), producing a technology proposal per the strategy. A small design authority reviews the exceptions: new styles, new platforms, unreleased interfaces. Clean core gives a useful yardstick: SAP's current guidance grades extensions from level A (released, stable interfaces only) to level D (non-recommended objects). Integrations that read unreleased tables or call unreleased function modules sit at the risky end and need an explicit decision and an exit plan.
| Request type | Path | Approver | Evidence |
|---|---|---|---|
| Standard pattern, standard content | Fast track: catalog entry, build, test | Integration lead | Catalog entry, test results |
| Standard pattern, custom flow | Design review against blueprint | Integration architect | Design note, tests, monitoring setup |
| New style or platform | Design authority decision | Architecture board | Decision record with alternatives |
| Unreleased interface (clean core risk) | Exception with exit plan | Architecture board and process owner | Risk, upgrade test, replacement date |
What would you do?
A Wave 2 project team wants to read Alternadores del Norte stock directly from S/4HANA tables with a custom RFC because "the API is slower." What should governance do?
- The catalog is the backbone: every interface, API and event with owners, style, platform, SLA, version and status.
- APIs: design standards, versioning and deprecation, proxies with policies, publication to a developer hub.
- Events: event catalog, schemas, topic naming, breaking-change policy; each custom event is a contract.
- Proportionate governance: fast track for standard patterns, design authority for real deviations and clean core risk.
Check your understanding · not graded
Lesson check
1. Why is the integration catalog the backbone of governance?
2. What does an API proxy separate?
3. Which is a governance challenge specific to events?
4. In SAP's clean core levels, which level is preferred for integrations?