Your Business Knowledge, Connected: Making Process, Architecture and Transformation Knowledge Work Across Tools and AI

Key message: SAP, Celonis, ARIS and Microsoft now all offer a context layer that makes AI agents smarter inside their own platform (see our market briefing Everyone Now Sells a Semantic Layer for Processes). That is good news for customers. But it raises a fair question for us too: is Business Flows just one more tool? It is not. Most enterprises already own the right tools. What they lack is a reliable connection between them: one agreed meaning for each process, role, control and application, with rules that keep it correct and governance over who may change it, people and AI agents alike. That is what we help customers build, run and own. Under the hood we use open W3C standards, so the result belongs to the customer and outlives any single tool.

1. Not another tool: what we actually offer

In a typical S/4HANA transformation, every tool does its job well:

• ARIS or SAP Signavio hold the designed processes.
• SAP LeanIX holds the application landscape and capabilities.
• SAP Cloud ALM holds requirements, solution processes and tests.
• Celonis or SAP Signavio Process Intelligence show how processes really run.
• Jira holds the delivery backlog; a GRC tool holds the controls.

We do not replace any of them, and we do not want to. Our work starts where they stop: at the questions that span them. If we replace this application, which processes, roles, requirements, controls and tests are affected? Is "Approve Purchase Requisition" in Signavio the same thing as the step in Cloud ALM and the control in the GRC tool? Which of these definitions may an AI agent rely on?

What a customer gets from us is a combination of three things:

• Expertise and method. Process, architecture and transformation governance know-how from years of SAP and BPM programs, applied to the customer's landscape.
• The Business Flows reference content and accelerators. End-to-end scenarios, a reference process model aligned with SAP best practice, and connectors to the tools above.
• A shared knowledge core the customer owns. Definitions, cross-tool links and governance rules, kept as open-standard files under the customer's version control, not locked in our platform or anyone else's.

This makes the vendors' tools more valuable, not less. A Signavio process that is linked to its LeanIX application, its Cloud ALM requirements and its controls is worth more to the customer, and to every AI agent that reads it.

2. Four use cases where it pays off

Not every technically interesting application is worth a budget. These four are the ones where we see clear, near-term value.

A. Cross-tool transformation impact analysis

Situation: A customer replaces an application, changes an SAP process or introduces a new operating model. What we do: Identify the affected processes, organizational roles, requirements, controls, documents, tests and improvement initiatives, across all repositories, in one view, with a link back into each tool. Who it is for: Transformation leads, CIOs, enterprise architecture and BPM centers of excellence. Value: Less manual impact analysis, fewer missed dependencies, faster and better-founded change planning. Because it answers a question every program already has, with a budget already attached, this is usually where we start.

B. Governed business context for AI agents

Situation: AI agents need to know which process they support, which rules apply, which application is authoritative and when to escalate to a human. What we do: Provide approved business definitions as a common, permission-aware context service that agents on different platforms can use, and route any change an agent proposes through the same review as a human modeler's. Who it is for: Enterprise AI leads, CIOs, automation and transformation leaders. Value: Approved business knowledge is reused instead of rebuilt per agent platform, integration effort is not duplicated, and agent answers and decisions become more reliable and explainable. This is the larger, strategic opportunity, and it grows naturally out of A.

C. BPM repository migration and coexistence

Situation: Companies merge, consolidate vendors, migrate from ARIS to SAP Signavio (or the other way round), or run several repositories side by side during a multi-year transformation. What we do: Use the shared knowledge core as a neutral intermediate layer that preserves identities, mappings, relationships and selected governance metadata while content moves or coexists. Who it is for: BPM centers of excellence, IT transformation and enterprise architecture. Value: Less migration effort and less loss of business knowledge. Owners, approvals, control links and history survive the move instead of being rebuilt by hand.

D. Continuous repository quality and governance

Situation: Over time, repositories drift: owners leave, references go stale, an activity is assigned to two applications, a control points at a process that no longer exists. What we do: Check the repositories continuously against agreed, executable rules and report every violation with its source and owner. Who it is for: BPM centers of excellence, governance, risk and compliance, enterprise architecture. Value: Less manual repository maintenance and better information quality, which every other use case, and every AI agent, depends on.

These use cases build on each other. A quality baseline (D) makes impact analysis (A) trustworthy; a connected, governed core built for A is exactly what AI agents need (B); and the same core carries knowledge safely through a migration (C). Customers can start with one immediate problem, such as a single application replacement or a repository clean-up before a migration, and grow from there.

3. Why open standards matter to the business

The technology choice is ours to justify, not the customer's to buy. But it has direct business consequences:

• Ownership. The definitions and rules are plain, documented files in the customer's own version control. No license is needed to read them.
• Survives tool change. When a repository is replaced or a vendor relationship changes, the shared meaning, mappings and history stay intact. That is what makes use case C possible.
• Auditability. Every definition has an owner, a version, a status and a change log. Every rule can be shown to work. Regulated customers need exactly that.
• No dependency on us. The standards are W3C recommendations, readable by many tools. A customer could take the core to another partner. We would rather earn the follow-up work than lock it in.

The rest of this article explains the engineering for readers who want to look under the hood: what the standards do, how we use them, and the trade-offs we made.

4. Under the hood: one enterprise, five repositories, no shared meaning

Take a single activity, "Approve Purchase Requisition":

• In the process model it is a task in a BPMN lane.
• In Cloud ALM it is a solution process step linked to requirements and test cases.
• In LeanIX it is an implicit dependency of an application and a business capability.
• In the control framework it is the point where a segregation-of-duties control applies.
• In Jira it is the subject of three user stories, under two different names.

Naming conventions and modeling handbooks keep one repository tidy. They do not make five repositories agree, and they cannot answer the impact question of use case A. That needs a layer above the tools that defines each business concept once and records where every tool represents it.

5. The standards in plain language

Three W3C standards do the heavy lifting. None of them is new, and that is a feature: they are vendor-neutral, stable and readable by many tools.

RDF: the sentences. The Resource Description Framework stores knowledge as simple three-part sentences: "Approve Purchase Requisition — is performed by — Purchasing Manager." Every concept gets a stable web address, so a sentence written in one system means the same thing in another.

OWL: the dictionary and the grammar. The Web Ontology Language (see the W3C OWL 2 Primer) describes the kinds of things and how they relate: a Sanction Screening is a kind of Compliance Check, which is a kind of Control; a Control governs an Activity; part of is transitive across step, process and scenario. A reasoner can apply such rules and conclude facts nobody wrote down, so a query for "all Controls" also returns the screenings.

SHACL: the quality gate. The Shapes Constraint Language states what a valid repository looks like: "Every approved activity names exactly one responsible role." "No two approved activities share a name." A validator checks the actual data and reports every violation. This is the engine behind use case D.

6. Open world vs. closed world: why the gap must be a finding

Take the rule "every approved activity has a responsible role" and an activity that has none.

• SHACL says: the role is missing, so this is an error. This is the closed-world view.
• OWL says: a role must exist; we just don't know which one yet. No error. This is the open-world assumption.

OWL was designed for the open web, where information is always incomplete. A governed repository is the opposite: a gap is a finding, and someone owns fixing it (research such as SHACL: A Description Logic in Disguise shows how different the two semantics are). So we use OWL to define meaning and SHACL to enforce rules, and never let OWL quietly "repair" a modeling error.

7. What the Business Flows core covers

The ontology is written in OWL, stored as Turtle files under version control, and is the source of truth; the graph database holds a working copy built from it. It covers the business layer, not the data layer:

• Processes and their hierarchy. Scenarios contain processes, processes contain activities, activities are performed by roles. Each is a governed definition with owner, version, status and governance namespace; GxP-validated content must be approved.
• Roles from evidence, not opinion. Role-to-lane assignments are derived from the process models, with source models and evidence counts attached. Hand-made assignments are rejected.
• Compliance woven into the process. Obligations and controls govern activities; every obligation must govern at least one activity. "Show me every control on Order to Cash" works regardless of which control subtype was modeled.
• Operating models. Operating-model entities and flows connect to the same scenarios, processes and roles, so an operating-model change traces to everything it touches (use case A).
• Enterprise architecture. Applications and capabilities sit in the same graph; an activity records the system it runs in, and LeanIX fact sheets are registered against the definitions they describe.
• Reference content without lock-in. The Business Flows reference model and SAP best-practice scope items form a read-only reference layer. Customer processes refine or are realized by reference content but never change it, so a customer can adopt the reference and still diverge where its business really is different.
• Tools are registered, not copied. Every artifact in ARIS, Signavio, Cloud ALM, LeanIX or Jira is registered with a deep link back into the tool and a depth dial per source: D0 identity only; D1 plus an anchor to the governed definition; D2 selected attributes monitored for drift; D3 a full import, only with a named justification. The knowledge core holds definitions, identity and links, and leaves models and diagrams in the tools where they belong. This is what keeps us complementary to the vendors, and what makes migration and coexistence (use case C) manageable.
• Sync with a clear authority. For every artifact type, a sync policy names the authoritative tool, for example Cloud ALM for requirements and Signavio for process diagrams. When both sides change, a steward decides; nothing is silently overwritten.

8. Governance as code: stage, validate, promote

Nothing enters the live core directly. Every change, whether from a person, a connector or an AI agent, is staged, validated against the SHACL rules, and only then promoted by a steward or an auto-promote policy (GRC content never promotes automatically). Every promotion writes a change log.

Example rules from the current set:

• One meaning per name: two approved activities may not share a label.
• Approved activities have an owner: each names a responsible role.
• Validated means released: GxP-validated content must be approved.
• Reference content is immutable: customer writes never hang off reference nodes.
• Respect the depth dial: no tool artifact is registered deeper than its source allows.

Each rule ships with a scripted "break demo" that must trigger it exactly once, so a governance board can trust that a rule does what its description says.

For AI agents (use case B) this is the key point. An agent working through our MCP interface can read governed definitions, ask for impact, or trace where a definition comes from. It can propose changes, but those land in staging and face the same rules and steward as a human modeler. The knowledge core is the agent's guardrail, not just its knowledge base.

9. Properties on relationships: RACI as part of the model

Process knowledge often lives on the relationship: the Purchasing Manager performs an activity as Responsible, Accountable, Consulted or Informed. We declare such properties in the ontology and export them as statements about a statement, the RDF-star idea now part of the RDF 1.2 work at W3C:

Approve Purchase Requisition  performed by  Purchasing Manager  {| raci "R" ; confidence 0.9 |}

Three rules check these annotations, and the round trip works against an RDF 1.2 triplestore that answers SPARQL queries about who is Responsible for what. A RACI matrix stops being a spreadsheet next to the model and becomes a queryable, validated part of it that survives a move between tools.

10. Why we use less OWL reasoning than you might expect

Today we rely on the class hierarchy (a Sanction Screening counts as a Control) and on derivations the engine computes and records with evidence. Full OWL reasoning could do more, such as aligning a customer's own control types or navigating hierarchies in one query. But in a governed repository it also costs: errors can be explained away under the open-world view, inferred facts carry no owner or provenance, one wrong sameAs statement merges a Signavio task with a LeanIX object, and a rule could be satisfied by a role nobody agreed on.

Our answer is a controlled set of inferences: subclass and subproperty hierarchies, inverse and transitive relationships and property chains, each materialized with provenance. Domain and range inference and automatic identity merging stay switched off. For auditors and process owners, explainability beats cleverness.

11. Standards first, database second

Because the ontology and rules are W3C files and the database only holds a working copy, the database is replaceable. Whether a native RDF store such as GraphDB, Stardog or Siemens' Graph Studio should replace or complement a property graph is a measurable question, not a strategic bet. We recommend the same order to every organization exploring this field: define the meaning and the rules first, in open standards; choose the engine second.

12. How an engagement starts

We do not ask customers to invest in a new architecture for its own sake. We start with a problem that is already on the table:

1. One live change. Pick an application replacement, an SAP process change or an operating-model decision in the current program, and deliver the cross-tool impact analysis (use case A).
2. A quality baseline. Run the governance rules over the repositories involved and fix what matters (use case D). Often this is the most immediate win before a migration or go-live.
3. Expand where the value is. Carry the core through a repository migration or coexistence phase (C), and expose the approved definitions to the customer's AI agents (B).

At every step the customer's tools stay in place, and the knowledge core stays the customer's.

Learn more

• Web Ontology Language (Wikipedia) and the W3C OWL 2 Primer
• W3C SHACL Recommendation and Open-world assumption (Wikipedia)
• RDF 1.2 Concepts (W3C), the basis for statements about statements
• Free course: Knowledge Graphs – Foundations and Applications by Harald Sack on openHPI
• Talk: An Introduction to OWL by Sean Bechhofer, ISWC 2007
• Hands-on: Protégé Ontology Tutorial for Beginners and OWL Ontologies using Protégé, Part 2
• Stanford CS520 Knowledge Graphs seminar: designing a knowledge-graph schema
• Deeper: SHACL: A Description Logic in Disguise
• Market context: our briefing Everyone Now Sells a Semantic Layer for Processes and the live BPM Trends page

Facing an application replacement, a repository migration or an AI rollout that needs reliable business context? Write to sales@bpexperts.de, and we will start with the question already on your desk.