[[{“value”:”

Disclaimer

Between March 12 and 13, 2026, during a late-night architecture review, the model I had been developing finally crystallized.
What had initially started as two SAP-oriented patterns converged into a five-layer semantic integration architecture, culminating in DEIP – Domain Enterprise Integration Pattern.

On February 7, 2026 the scope of this work was limited to two patterns designed for SAP landscapes:

• DCRP – Domain-Centric Routing Pattern
• PDCP – Package Domain-Centric Pattern

Both focused on solving structural governance problems in SAP API Management and SAP Cloud Integration.

In just 36 days this initial nucleus evolved into a fully formalized five-layer semantic control architecture, designed to address a problem that many integration architects recognize but rarely formalize: integration sprawl.

This problem is not new.

For 17 years I have observed the same structural pattern repeating itself across different generations of SAP integration technologies:

• SAP XI – fragmented Software Components
• SAP PI/PO – interface and configuration proliferation
• SAP BTP Integration Suite – proxy, package, credential and artifact sprawl inside CPI landscapes

Each generation improved the technology stack, but the structural indexing problem remained the same: integrations were organized by system or project, rather than by domain intent.

During these 36 days of research and experimentation, this recurring chaos was distilled into a single architectural model.

At the center of this model sits DEIP, the parent architecture layer responsible for governing the three execution patterns:

DEIP — Semantic Control Plane Decision Model
└── Decision Pipeline
Intent
→ Interaction Type
→ Quality Profile
→ Integration Capability
→ Protocol Profile
→ Platform Binding
└── SDIA — Semantic Domain Integration Architecture
(DEIP Reference Architecture)
├── GDCR — Gateway Domain-Centric Routing
│ Reference Implementation — recommended starting point
├── DDCR — Domain Driven-Centric Router
│ Routing and capability resolution engine
└── ODCP — Orchestration Domain Composition Pattern
Cross-domain orchestration layer
└── Execution Platforms

SAP BTP · AWS · Azure · Kong · Kafka · IoT · AI/LLM · etc.

Together, these patterns form a domain-centric semantic control plane that sits above any specific execution platform.

From this point of closure — looking at SAP landscapes where the required capabilities already exist but are often applied without consistent domain semantics — this final blog post of the series begins.

Disclaimer SAP

SAP BTP Integration Suite already provides all the capabilities necessary to implement and validate this architecture in practice.

The platform offers:

• a mature API Management layer
• a powerful Cloud Integration runtime
• Event Mesh
• security services
• and strong governance tooling.

The problem has never been the SAP platform itself.

Instead, the issue often lies in how integrations are indexed and governed.Many landscapes organize integrations by projects and systems, rather than by domain intent, which leads to proxy, package and credential sprawl even on top of a strong platform.

This same concern was raised earlier in January 2026 in my SAP Community article:

SAP BTP – Integration Suite: Clean Architecture vs The Frankenstein Landscape.

As a way of acknowledging the SAP ecosystem that shaped much of this work over the past 17 years, I am making a small professional commitment.

Within schedule constraints, I will offer five 1:1 discussion sessions, free of charge, for SAP architects interested in discussing how the following patterns can be applied in real landscapes:

These sessions are not intended as training or presentations.Participation assumes bringing concrete architectural questions, since the discussion will focus on the structural decision model behind the framework — beginning with the fundamental key I propose:

What is the domain intent of this integration?

Alignment with SAP Strategic Directions

This work aligns directly with three strategic directions already promoted by SAP:

• Clean Core
  • DEIP keeps protocol complexity and integration decision logic outside of S/4HANA by moving these concerns into a semantic control plane on SAP BTP.
  • This allows the core ERP to remain standard while integrations stay governed and evolvable.
• RISE with SAP
  • By indexing integrations on domain intent rather than on individual systems, DEIP provides RISE transformation programs with a structured way to rationalize legacy interfaces during cloud migrations.
• ISA-M
  • DEIP complements ISA-M by operating as a decision layer above the integration scenario model.While ISA-M classifies integration scenarios, DEIP maps them to capabilities, protocol profiles and platform bindings, ensuring that integration architectures remain domain-driven and consistent across platforms.

Dedication and Acknowledgement

Dedication

This work is dedicated to my father, Brigadier Ricardo Holanda Viana,
The Commander, whose discipline, courage and leadership shaped much of the character behind this journey.

Acknowledgement

Beyond its personal dedication, this work stands on the shoulders of foundational contributions that have shaped modern enterprise architecture and integration thinking.

Key references that served as intellectual guidance in the development of this model include:

• Hohpe & Woolf (2003) — Enterprise Integration Patterns

• Martin Fowler (2002) — Patterns of Enterprise Application Architecture

• Eric Evans (2003) — Domain-Driven Design

• Sam Newman (2015) — Building Microservices

• Kreps et al. (2011) — Kafka: A Distributed Messaging System for Log Processing

• Istio Team (2017) — Service Mesh control plane architectures

• Zhamak Dehghani (2022) — Data Mesh

These works served as conceptual references and navigational points during the research and development process.

The central motivation behind this work was to revisit these architectural patterns and integration models and explore how they could be structurally combined into a coherent enterprise architecture perspective, organized around a single primary key:

the intent of the domain.

In this model, domain intent becomes the organizing principle that allows architectural decisions — from interaction patterns to protocol profiles and platform bindings — to be navigated consistently across the enterprise integration landscape.

Ricardo Luz Holanda Viana – March 2026

Introduction

Enterprise integration landscapes have evolved significantly over the past two decades.
Technologies have improved, platforms have matured, and new capabilities have been added to integration stacks across the industry.

Yet one structural problem persists across almost every enterprise landscape: integration sprawl.

Interfaces are frequently indexed by systems, projects, or technical artifacts, rather than by the intent of the domain they serve. Over time this leads to landscapes filled with proxies, packages, credentials, endpoints and flows that are technically functional, but structurally difficult to understand, govern and evolve.

This blog introduces DEIP — Domain Enterprise Integration Pattern, a vendor-agnostic semantic meta-framework structured across five architectural levels, governed entirely as a metadata control plane, designed to bring structural clarity to modern enterprise integration landscapes.

At its core, DEIP proposes a simple but powerful shift:
integration decisions should begin with domain intent, not with technology.

From that starting point, integration architectures can be navigated through a structured decision pipeline that determines:

• the interaction type

• the required quality characteristics

• the integration capability

• the protocol profile

• and finally the platform binding.

This model forms a semantic control plane that governs runtime architectures such as SDIA, GDCR, DDCR and ODCP, while remaining independent from any specific execution platform.

The goal of this article is not to dive into every technical detail of the model.
Instead, it aims to provide architects with a clear conceptual overview of the architecture and the problem it addresses.

A complete technical companion document — expected in the coming months — will describe in detail how to map domains, structure the decision model, and navigate the architectural layers in real enterprise landscapes.

Until then, the most important idea to retain is simple:

everything begins with a single primary key: the intent of the domain. – “The Domains never lies”

Interpretation Note

This timeline should not be interpreted as positioning DEIP as “higher or better” to the foundational work of Hohpe & Woolf (2003).

Enterprise Integration Patterns defined 65 fundamental patterns describing how messages move through enterprise integration systems. Their work remains one of the most important references in the field and continues to guide integration architecture today.

The name Domain Enterprise Integration Pattern (DEIP) was deliberately chosen as a tribute to that work. Hohpe and Woolf defined the patterns that govern how messages travel inside enterprise integration systems.

DEIP builds on that legacy by addressing a different architectural question that emerged as enterprise landscapes evolved into multi-cloud, multi-vendor environments and AI-driven systems.

While Enterprise Integration Patterns describe how messages move across integration infrastructure, DEIP proposes a structural model for how domain intent moves across the enterprise landscape.

In this model, the domain becomes the primary architectural key, allowing integration decisions to be navigated consistently across interaction types, capabilities, protocol profiles and platform bindings.

In that sense, DEIP should be understood as an evolutionary architectural layer built on top of the foundations established by Enterprise Integration Patterns, extending their ideas into modern enterprise integration landscapes.

This work is therefore presented not as a replacement of those foundations, but as a continuation of them — an attempt to take the principles established in 2003 and structure them for the next generation of enterprise integration architectures.

What is DEIP?

DEIP – the Domain Enterprise Integration Pattern – is a semantic decision architecture designed to bring structural clarity to modern enterprise integration landscapes. Instead of organizing integrations by systems, projects or technical artifacts, DEIP proposes that every integration decision starts from a different primary key: the intent of the domain. In this model, the domain becomes the organizing principle used to navigate integration decisions across the entire landscape, and a semantic control plane replaces ad‑hoc design inside individual flows, proxies or API configurations.

The DEIP Decision Pipeline (6 stages)

At the center of DEIP is a seven‑stage decision pipeline:

Intent → Interaction Type → Quality Profile → Integration Capability → Protocol Profile → Platform Binding  

Each stage answers a different question and progressively transforms domain intent into a concrete integration implementation:

• Intent – What is the semantic purpose of the integration?
  Examples: invoice.read.finance, orders.create.ecommerce, iot.sensor.stream, security.identity.authenticate.

• Interaction Type – Which interaction family does it belong to?
  Examples: request, command, event, stream, batch, workflow, replication.

• Quality Profile – What non‑functional characteristics are required?
  Examples: low latency, high throughput, at‑least‑once delivery, strict ordering, strong authentication, data sovereignty.

• Integration Capability – Which abstract integration capability is needed?
  Examples: API mediation, event streaming, CDC replication, long‑running workflow, IoT ingestion, AI tool routing, security authentication/authorization.

• Protocol Profile – Which concrete protocol or messaging style implements that capability?
  Examples: HTTP/REST, gRPC, OData, Kafka, MQTT, AMQP, ETL/CDC, OpenID Connect.

• Platform Binding – On which runtime platform will this flow execute?
  Examples: SAP API Management, SAP Cloud Integration, SAP Event Mesh, Kafka cluster, IoT broker, identity provider, Kubernetes/Istio.

• Execution Binding – What is the concrete execution artifact or RouteID that binds this decision to a real endpoint or flow, without exposing internal topology to consumers?

By navigating these seven stages, architects can consistently determine how integrations should be implemented, independent of specific vendors or products.

Metadata as the Control Mechanism

DEIP does not introduce another integration product. It operates purely as a semantic control plane expressed as metadata that describes the integration landscape. This metadata acts as the control map of the architecture and can live in a structured database, a metadata catalog, a governance repository, or—even in the early stages—a well‑structured spreadsheet.

Metadata control plane = a table where you store your enterprise integration decisions.

Can be:
– Excel ← it’s metadata
– Google Sheets ← it’s metadata
– Database ← it’s metadata
– Redis / KVM ← it’s metadata
– Sticky note on the wall ← technically also metadata

The fancy name is just that — a table where you store the map of intentions.

The sophistication is not WHERE you store it. It’s WHAT you store and how DDCR uses it.

A simple starting point can look like this:

DomainIntentInteractionCapabilityProtocolPlatform

From Decision Model to Runtime Architecture

DEIP itself is not a runtime system. It is an architectural decision model that governs runtime architectures such as:

• SDIA – Semantic Domain Integration Architecture

• GDCR – Gateway Domain‑Centric Routing

• DDCR – Domain‑Driven Centric Router

• ODCP – Orchestration Domain Composition Pattern

These patterns implement the decisions derived from the DEIP pipeline inside real integration platforms (for example, SAP API Management, SAP Cloud Integration, Event Mesh, IoT brokers, service meshes and identity providers). The semantic control plane decides what should happen and where; the runtime patterns execute those decisions.

The core principle behind all of this remains intentionally simple and universal:
every integration decision starts from a single primary key — the intent of the domain.

DEIP and DDCR — A Simple Mathematical Model

Although DEIP is primarily an architectural decision model, its pipeline can also be expressed as a simple mathematical function that transforms domain intent into a concrete integration implementation.

Friends from SAP, I’m going to present the mathematical formulas that I derived. But don’t worry — the solution is DEIP itself. The formulas are only here as a visual aid to help understand the model.

What matters is the architectural, structural and execution vision behind it. At this point, the way I see integration architecture is very simple: I see patterns, domains and mathematics.

Mathematics is universal – 2 + 2 = 4 anywhere in the world.

Look at the table below for example. The Order to Cash process is essentially the same anywhere in the world.So how does DEIP interpret this?

No matter where you are in the world, regardless of language or platform, the entry point for any Order to Cash call is:

/<domain>/<entity>/<action>/<target>

Example:

/sales/order/create

What does this mean inside SAP API Management ?

Only one proxy is required. It can be defined using a single OpenAPI or Swagger specification with an entry point like:

/sales/orders/create/<target>

The routing is static, and a JavaScript policy (DDCR) resolves the final destination.

This means you can place 20 vendors behind a single API proxy in SAP API Management.

The code can include custom headers for tracking, and additional headers can also be added if needed.

This approach eliminates proxy sprawl at the root.

That is the idea behind DDCR.

In practice, the DDCR runtime proved this approach works. A simple JavaScript policy implementation processed around 2,067,904 requests across 8 platforms and 5 programming languages, running continuously for about 29 hours, withzero routing failures — 158 network-layer failures only (ECONNRESET/ETIMEDOUT)

The full implementation details, experiments and runtime evidence are available in the GitHub repository associated with this work.

DEIP(Intent, Context) → Implementation

The DEIP pipeline is a sequence of deterministic functions. Each stage is a formal reduction where context constrains the valid outputs:

f₁ : I × C → T
Intent + Context → Interaction Type

f₂ : I × T × C → Q
Intent + Interaction Type + Context → Quality Profile

f₃ : I × T × Q → Cap
Intent + Interaction Type + Quality Profile → Integration Capability

f₄ : Cap → Pprot
Integration Capability → Protocol Profile

f₅ : Pprot × C → Pplat
Protocol Profile + Context → Platform Binding

In this model:

I = Domain Intent
C = Context (environment, constraints, policies)
T = Interaction Type
Q = Quality Profile
Cap = Integration Capability
Pprot = Protocol Profile
Pplat = Platform Binding

DDCR Resolution Model – Remember in SAP APIM it’s just the javascript policy the name is my creation just it.

Once the decision pipeline produces a platform binding, the DDCR engine resolves the final runtime configuration using deterministic key resolution.

{ f(key) → value }

Where the key represents the resolved integration identity derived from the DEIP pipeline, and the value represents the runtime configuration to be applied (routing target, protocol adapter, credentials, endpoint, or orchestration behavior).

Applying DEIP in Practice

Once the DEIP decision pipeline is defined, the next step is applying its outcomes inside the runtime architecture.

DEIP itself does not execute integrations.
Instead, it acts as a semantic control plane that guides how runtime components should behave.

In practice, the pipeline outputs are implemented through the SDIA architecture and its execution patterns.

DEIP → SDIA

The first layer where DEIP becomes operational is SDIA (Semantic Domain Integration Architecture).

SDIA represents the runtime architecture organized by domain, where integrations are grouped and governed according to their domain intent.

Instead of organizing integration artifacts by systems or projects, SDIA structures them by domains, such as:

Orders
Payments
Customers
Logistics
Notifications

Each domain becomes a semantic boundary where integration decisions derived from the DEIP pipeline are applied consistently.

SDIA → GDCR

At the gateway layer, DEIP decisions guide GDCR (Gateway Domain-Centric Routing).

GDCR is responsible for routing requests according to the domain intent.

Instead of routing based only on technical endpoints, GDCR uses the domain structure to determine where requests should flow.

Example:

/<domain>/<entity>/<action>/<target | sender>

/sales/orders/create/salesforce
/hr/customers/update/workday
/finance/payments/authorize/stripe
/iot/sensors/stream/mqtt
/iot/devices/command/firmware

Here the domain is the primary routing key.

Entao com essa organizacao o que é feito dentro do SAP APIM ? Que na minha opniao é a melhor ferramenta no quisito User Design e configuracao de rotas estativas ? Vou te explicar.

Proxy Sprawl (1 proxy por backend or Contract)
/sap-s4hana/orders/create
/salesforce-crm/orders/create
/oracle-erp/orders/create
/legacy-system/orders/create
↑ 4 proxies · 4 contracts · 4 versioning

After with DEIP + SDIA + GDCR and DDCR

GDCR (1 proxy por domínio)

/sales/<entity>/<action>/<vendor>

↑ 1 proxy · 1 contract · new vendor via metadata – KVM for SAP APIM

For example – Domain: SALES – Process O2C,  the same sample works for SALES – Lead to Opportunity (L2O) – Opportunity to Quote (O2Q) – Quote to Order (Q2O) etc…

So you create one proxy – gdcr-proxy-domain-sales-o2c, it means what ever application, vendor, client, modile etc that goes for the intent domain SALES for APIM always will use only the entry dor /sales/ but than how to routing this ?

Static routing over the entity for the HTTP path /sales/orders… /sales/customers…/sales/invoices…/sales/princing

Entry door: https://<apim>/282cc9datrial/sales/ 

What does this configuration mean?

This is a static routing rule condition in the API Proxy design. This single proxy — SALES O2C — supports all calls from anywhere, covering 13 business processes from the O2C domain.

What does this still mean ?

500 applications · 1 proxy · 13 routing rules = End of proxy sprawl. The rest DDCR — JavaScript — resolves alone. Don’t worry.

Why did I decide to segregate the proxy per business domain? To avoid the sprawl of a single proxy responsible for all calls. This segregation also keeps everything more organized.

Does DDCR work with OpenAPI and Swagger ?

Yes — the JavaScript is the routing engine. There is no connection with the contract or SLA of the specification. But the mindset must change: you don’t create a specification per vendor — you create a specification per domain.

This means the specification, proxy, and DDCR JavaScript are immutable. If anything new comes to onboard — add one string in the KVM. That’s it. As simple as 2+2=4. This is mathematics.

But my company is working with IOT etc… so follow the same process, create proxy, add the routing, what will be the domain /LLM/ thats it

gdcr-ai-llm-proxy-domain-unified

    https://<apim>/282cc9datrial/llm

SDIA → DDCR

Once a request enters the domain structure, DDCR (Domain Driven Centric Router) resolves the final integration configuration.

DDCR acts as a deterministic resolution engine.

It takes the resolved domain identity and looks up the metadata produced by the DEIP pipeline to determine:

• protocol – http

• endpoint – any destiny

Conceptually:

Domain + Intent → Configuration

So let’s check again what was discussed above we are speaking about SALES – O2C means the entry door for SAP APIM:

Entry door: https://<apim>/282cc9datrial/sales/ 

Than we have this cenario – 1 proxy – routing ( /orders/** – / customers/** – /deliveries/** 😞

https://<sapapim>/sales/orders/create/salesforce
https://<sapapim>/sales/orders/update/salesforceemea
https://<sapapim>/sales/orders/create/microsoft
https://<sapapim>/sales/customers/sync/s4hana
https://<sapapim>/sales/customers/sync/shopify
https://<sapapim>/sales/deliveries/transfer/fedex

DDCR Keys — KVM (determinísticas e machine-computed)

dcrporderscid01salesforce:http
dcrporderscid02sfemea:http
dcrporderscid03microsoft:http
dcrpcustomerssid04s4hana:cxf
dcrpcustomerssid05shopify:http
dcrpdeliveriestid06fedex:http

Resolved URLs — CPI (execution-ready)

https://<cpi>/http/dcrp/orders/c/id01
https://<cpi>/http/dcrp/orders/u/id02
https://<cpi>/http/dcrp/orders/c/id03
https://<cpi>/cxf/dcrp/customers/s/id04
https://<cpi>/http/dcrp/customers/s/id05
https://<cpi>/http/dcrp/deliveries/t/id06

Again — this logic is pure mathematics. The only way to fail is a wrong intent HTTP path or a wrong string in the KVM, that triggers in the 3rd step the FAST-FAIL M2M in ~0.1ms, the backend don’t even know about this call. It never fails. Over 2 million calls across 5 different API platforms from the market — and everything else I tested — zero routing failures.

SDIA → ODCP

Some integrations require orchestration across multiple domains. This is where ODCP — Orchestration Domain-Centric Pattern — operates.

ODCP governs three things simultaneously:

1. Package Topology — One Domain, One Package

Before: After:
Salesforce_Orders_Pkg → nx.sales.o2c.integrations
SAP_S4HANA_Orders_Pkg → (same package — Sales domain)
SAP_ECC_FI_AR_v2_Package → nx.finance.r2r.integrations
FedEx_Shipping_Integration → nx.logistics.le.integrations
Ariba_Procurement_Pkg → nx.procurement.s2p.integrations
Temp_QA_DoNotDelete → eliminated

39 packages → 4. Package count becomes invariant — it scales with domains, not vendors.

ODCP defines a structured package naming convention that encodes domain identity, business process, and platform context into a single readable string:

[prefix].[domain].[process].integrations  Multi-division — same domain, same business process, one division owns the integration:

[prefix-company].[division].[domain].[businessprocess].[integration]

Multi-division — same orchestration tenant, multiple divisions, same domain:

[prefix-company].[division].[core].[domain]

2. iFlow DNA — Deterministic Artifact Naming

POST /sales/orders/create/salesforce
→ id01.o2c.salesforce.order.s4hana.c.in.sync

POST /finance/invoices/create/s4hana
→ id13.r2r.s4hana.invoice.target.c.in.sync

Every artifact is traceable from semantic URL → DDCR key → iFlow DNA. No more Salesforce_Order_Sync_v3_FINAL_USE_THIS.

id[seq].[subdomain].[sender].[entity].[receiver].[action].[direction].[sync|async]

Example:  id01.o2c.salesforce.order.s4hana.c.in.sync

 iFlow DNA Component Reference

 iFlow DNA — Implementation Proofs

Each iFlow DNA name is directly traceable to its semantic address in the GDCR facade and its KVM routing key in the DDCR engine. The id[seq] component is the explicit link: id01 in the iFlow DNA corresponds to iflowid id01 in the KVM key dcrporderscsalesforceid01:http.

4.5 The Semantic Chain — End-to-End Traceability

Business intent enters at the semantic address. Metadata decides at the DDCR engine. Domain governs at the ODCP orchestration layer. Technology becomes background. Semantics become the integration language — end to end.

3. Credential Segmentation — Sub-Domain Tiered

cr.sales.orders.rw — Orders only · 30 days rotation
cr.sales.analytics.ro — Analytics only · 90 days rotation
cr.finance.ap.rw — Accounts Payable only · 30 days rotation

39 credentials → 12. One rotation failure affects only one sub-domain — never the entire landscape.

The result: Business intent enters at the semantic URL. DDCR resolves. ODCP governs the artifact. Technology becomes background.

Credential Naming Convention

Technical user names follow the same domain‑centric semantic pattern as packages and flows:

Examples:

• cr.sales.orders.rw – Sales / Orders / Read‑Write
• cr.finance.ap.rw – Finance / Accounts Payable / Read‑Write
• cr.finance.reporting.ro – Finance / Reporting / Read‑Only
• cr.logistics.shipments.rw – Logistics / Shipments / Read‑Write

The naming convention makes credential ownership, scope, and permission level immediately readable from the identifier, eliminating the opacity of names like iflow_cred_12 or api_user_SF_orders.

Three Pillars of ODCP Credential Governance

SAP-Specific Artifact Scope

In SAP BTP Cloud Integration, the iFlow DNA naming convention extends to all integration artifacts within the package — not only iFlows. Script collections, value mappings, message mappings, data stores, communication channels, technical users, and even internal variables adopt the same domain‑centric prefixing (for example, vm.sales.order.status, sc.sales.order.transformation, cr.sales.orders.rw). This makes the entire CPI artifact space navigable by business domain rather than by technical type or vendor.

SDIA — COMPLETE ARCHITECTURE

End-to-End Semantic Flow

The Semantic Domain Integration Architecture (SDIA) preserves business domain semantics across every layer of the enterprise integration stack. ODCP is the final governance layer in this chain — ensuring that semantic continuity extends from the API consumer address to the backend execution artifact.

Human Semantic Address

POST /sales/orders/create/salesforce

The Result

When combined, these layers create a complete architecture:

DEIP — Semantic Control Plane → What · Why · Which
↓
SDIA — Domain Runtime Architecture → Organized by domain intent
↓
GDCR — Gateway Layer → 1 proxy per domain · immutable
↓
DDCR — Resolution Engine → f(key) → value · zero failures
↓
ODCP — Orchestration Layer → 1 package · DNA naming · tiered credentials
↓
Execution Platforms → SAP · AWS · Azure · Kong · IoT · AI/LLM
↓
Result = Sales + Sales + Sales + Sales

The full end-to-end — based on the intention of the Sales domain. The technology does not matter. What matters is what the domain needs.

Conclusion

Every enterprise integration landscape on Earth converges to the same six failure modes. Not because of bad engineers. Not because of bad platforms. Because the organizing principle was always wrong.

Technology was never the primary key. The domain always was.

DEIP does not add a new tool to your stack. It changes the question you ask before you build anything:

What is the domain intent of this integration?

Answer that first. Everything else — protocol, platform, proxy, credential, artifact — becomes a consequence.

The domain never lies. It never has. We just forgot to ask it first.

Start Here — Reading Order

⚠️Before reading anything else — start with GDCR.

GDCR is where everything began. Originally developed as DCRP and PDCP — two SAP-specific patterns — it evolved into the foundation of the entire SDIA ecosystem. Without reading GDCR first, the other documents will not make sense. This is not a suggestion. It is a requirement.

Reading order:

1. 🔗GDCR — DOI: 10.5281/zenodo.18582492 ← Start here
2. 🔗DDCR — DOI: 10.5281/zenodo.18864832
3. 🔗ODCP — DOI: 10.5281/zenodo.18876594
4. 🔗SDIA — DOI: 10.5281/zenodo.18877635
5. 🔗DEIP — DOI: 10.5281/zenodo.19004802 ← This document

5 Architecture Discussion Slots

I am offering five free 1:1 sessions for senior architects and integration experts who have read the documents and want to discuss the architecture at a structural and abstract level.

I am not excluding any professional from the APIM or CPI space — but I want to be clear: these sessions are not about how to configure APIM routing or how to get the DDCR JavaScript running. The documents cover that.

What I want to discuss is DEIP — the decision pipeline, the semantic control plane, and the structural model behind it. If that is the conversation you want to have, send me an email.

This is not a course. This is not training. The documents are already published and available for free.

If you have read the material and want to discuss architecture — send me an email: rhviana@gmail.com

What comes next

In approximately two months I will release a companion document covering how to build the complete DEIP integration map and navigate all four architectural layers in practice. I cannot commit to an exact date yet.

After that — my focus moves to IEEE. The mathematics behind DDCR and DEIP deserve a formal academic submission. That is where this work goes next.

The domain never lies.

Ricardo Luz Holanda Viana — March 2026 — Warsaw, Poland

“}]] 

  Read More Technology Blog Posts by Members articles 

#abap