Separation of Concerns and Spheres of Influence in System Integrations

Introduction

Recently, I have been working on integrating two enterprise systems together using a middle-ware integrations suit . Multiple lengthy discussions about data shape, logic and system responsibilities where held in order to get all the stakeholders to agree on how the integration should behave. Although the rules of system integration are well defined, I found that it is easy to get crushed by anti patterns, people opinions and the most dangerous word in any industry (We have always done it that way).
So, I decided to write down some of the principles I hold dear when approaching integration tasks.

The Two principles I live by were elegantly described by a senior colleague and friend of mine (Richard),
1- Let each system do what it does best.
2- Let the integration act as a bridge, not a merger.

Now lets go into details.

When connecting enterprise systems together, the biggest challenge isn’t just the technical link as much as it’s keeping responsibilities clear. Integrations that ignore boundaries quickly grow into complex, opaque chains where no one knows which system truly owns the data or the rules.

To Prevent that, two principles should be upheld

• Separation of Concerns (SoC): Each integration layer should only handle its own responsibility.
• Spheres of Influence: Each system should remain authoritative in its domain, without another system leaking logic or reshaping its data.

Separation of Concerns in Integration

A well-designed integration separates responsibilities into distinct layers:

1. Data Ownership Layer
   • Each system exposes only the data it owns.
   • Avoid letting another system dictate or overwrite values it doesn’t own.
2. Transformation Layer
   • Data mappings and conversions (e.g., units, codes, classifications) happen here.
   • Neither system should be forced to adopt the other’s “shape of data.”
3. Transport Layer
   • Responsible for secure, reliable delivery (APIs, queues, events).
   • Includes retries, error handling, and monitoring — but not business rules.
4. Business Logic Layer
   • Rules remain local to each system.
   • Integration should invoke them, not duplicate or override them.

Spheres of Influence

A sphere of influence defines where a system is the single source of truth.

• A design system governs product structures, CAD metadata, or engineering change history.
• An ERP governs inventory, procurement, and financial data.
• A CRM governs customer interactions and sales cycles.

Crossing these boundaries without care leads to logic leakage and data shape leakage.

The Danger of Leaking Logic

Logic leakage happens when one system starts carrying out rules that belong in another system.

• Example: An integration script in the ERP calculates engineering release approvals instead of letting the design system handle it.
• Problem: Now both systems “think” they control approval, which leads to conflicts, double effort, and governance breakdown.

Principle: Always let each system enforce its own business logic. Integrations should only trigger or listen to events — not replicate rules.

The Danger of Leaking Data Shapes

Data shape leakage happens when one system’s internal structure dictates how another system must model its data.

• Example: A CRM is forced to adopt ERP cost-center codes just because the integration copied them over directly.
• Example: A product lifecycle system is forced to rename its fields to match another system’s table schema.
• Problem: This couples systems too tightly. If one changes its schema, everything breaks.

Principle: Use transformations to normalize or map fields in a neutral integration layer. Each system should keep its own model intact.

Visualizing the Principles

Here’s a simple diagram showing layers of concern and spheres of influence:

flowchart TB
    subgraph SOI1["System A"]
        A1[Authoritative Data A]
        A2[Business Rules A]
    end

    subgraph SOI2["System B"]
        B1[Authoritative Data B]
        B2[Business Rules B]
    end

    subgraph Integration["Integration Layer"]
        T1[Transport]
        T2[Transformation]
    end

    SOI1 -- Events / API --> Integration
    Integration -- Normalized Payloads --> SOI2
    SOI2 -- Acknowledgements / Enriched Data --> Integration
    Integration -- Updates / Notifications --> SOI1

• Spheres of Influence: Systems A and B each own their own logic and data.
• Integration Layer: Only handles transport and transformation.
• No Leakage: Logic and data shapes do not spill over — they are mediated.

Why This Matters

• Maintainability → Clear separation makes it easier to upgrade or replace systems.
• Governance → Compliance and auditing are simpler when each system owns its data and rules.
• Resilience → Failures in transport or transformation do not corrupt authoritative data.
• Future-proofing → Adding new systems becomes an exercise in extending mappings, not rewriting logic everywhere.

Bad vs. Good Integration (In my opinion)

Please take this information with a pinch of salt, as Bad and Good can sound definitive.
I do not adopt such a language but I used Good and Bad for the lack of other words

Bad Integration: Logic & Data Shape Leakage

In this model, systems directly embed each other’s rules and data structures.

• Logic leakage: System B enforces approval workflows that should belong to System A.
• Data shape leakage: System A changes its schema, and System B breaks because it depends on those internal details.

flowchart TB
    subgraph SysA["System A"]
        A1[Data A]
        A2[Business Rules A]
    end

    subgraph SysB["System B"]
        B1[Data B]
        B2[Business Rules B]
    end

    SysA -- "Direct Data Push (Schema A)" --> SysB
    SysB -- "Embedded Logic from A" --> SysB

Good Integration: Clear Separation of Concerns

Here, integration happens through neutral layers, where each layer works regardless of other layers state, logic or even existence.

• Each system owns its sphere of influence (its own rules and data).
• Integration handles only transport and transformation.
• Both systems remain insulated from each other’s internal schema and logic.

flowchart TB
    subgraph SysA["System A"]
        A1[Authoritative Data A]
        A2[Business Rules A]
    end

    subgraph SysB["System B"]
        B1[Authoritative Data B]
        B2[Business Rules B]
    end

    subgraph Middleware["Integration Layer"]
        T1[Transport]
        T2[Transformation]
    end

    SysA -- Events/API --> Middleware
    Middleware -- Normalized Payload --> SysB
    SysB -- Acknowledgements --> Middleware
    Middleware -- Notifications --> SysA

Real-World Analogy: Aras, CPI, and SAP

Think of Aras, CPI, and SAP like three roles in an international shipping operation:

• Aras (PLM system) → the factory that designs and packages the product.
  • Sphere of influence: product structures, engineering data, CAD metadata.
  • Concern: Ensuring the design is correct and ready for release.
• SAP CPI (middleware) → the shipping company that transports and translates the goods.
  • Sphere of influence: transport, translation, routing.
  • Concern: Making sure the product arrives safely and in the right “language” (data format) for customs.
• SAP ERP → the warehouse & customs office that receives, stores, and processes the goods.
  • Sphere of influence: inventory, procurement, financial accounting.
  • Concern: Managing supply chain and cost control.

flowchart LR
    A["Aras (Factory)- Owns Engineering Data"] 
    C["CPI (Shipping) - Handles Transport + Mapping"] 
    S["SAP ERP (Warehouse)- Owns Procurement & Inventory"] 

    A -- "Product Data" --> C
    C -- "Transformed Payload" --> S
    S -- "Acknowledgement / Status" --> C
    C -- "Notification" --> A

Conclusion

System integration is about more than connecting APIs. It’s about guarding boundaries. By applying separation of concerns and respecting spheres of influence, you prevent the leakage of logic and data shapes across systems.