Why most integration governance gets ignored
Governance fails when it is a document nobody opens at the moment of decision. A team under delivery pressure will pick the fastest path, and if the standard is slower than the shortcut, the shortcut wins.
Rules stick when they are short, tied to a tool or a template, owned by a named role, and backed by an exception route. Test every proposed rule with three questions:
- Who checks it?
- When is it checked: at design, at build, at release or in operation?
- What happens when it is missed?
If you cannot answer all three, the rule is a wish. Remove it or rewrite it until you can.
Set scope and ownership first
Decide what is governed before you write a single standard. For most SAP estates the scope includes:
- Integration flows in Cloud Integration.
- API proxies, policies and products in API Management.
- Events and topics in SAP Integration Suite, advanced event mesh.
- B2B content in Integration Advisor and Trading Partner Management.
- Any remaining PI/PO scenarios.
- Connectivity through SAP Cloud Connector.
Then assign four roles. The CIO sponsors the model, funds it and handles escalation. The head of the SAP centre of excellence runs the process and the exception board. The integration architect owns the technical standards. Delivery teams own compliance in their own work.
Choose a central model when only a few teams build integrations and you need consistency quickly. Choose a federated model when many teams build, and let the centre of excellence supply templates, reviews and tooling rather than doing every build itself.
Naming conventions that survive contact with delivery
Naming looks trivial and is the cheapest governance win. Good names make monitoring, search, access control and migration easier. Bad names make every later task slower.
Rules for names
Keep the convention to one page. A workable pattern is business domain, source, target, object and direction, for example a finance domain sending payment files from S/4HANA to a bank. Decide and document:
- Package names: one package per domain and purpose, not per developer.
- Integration flow names: describe the business object and direction, not the technology.
- API proxy names and base paths: stable, lower case, consumer friendly, with a version suffix only for breaking changes.
- Event topics: a hierarchy of domain, object and event type, designed and catalogued in the event portal.
- Credential aliases and keystore entries: named by system and purpose, never by person.
- Environment markers: one consistent way to tell development, test and production apart.
