Integrations as part of the SAP LeanIX (Enterprise...

stevang

GLUE _v3.png

We may have our state-of-the-art Applications. But how do we make them work together? We may have all our Date Objects properly designed and governed. But how do we unlock it for the Users and Agents?

Integration – key is in the Integration Services!

We have to integrate Applications, Users and Agents – in order to unlock our Data and make our Business Processes run seamlessly and efficiently, cross whole Enterprise.

I’ve talked about importance of recognizing the work on integrations in the Enterprise Architecture domain (my article in SAP EA Community: Enterprise Architecture for integration?), but now let’s go with few practical examples…

Integrations @ EAM

If we use SAP LeanIX solutions[1] as EAM (Enterprise Architecture Management) tool, and we want to model our Enterprise Architecture – how do we manage it, if we do not “connect” the dots

Well, we cannot!

Figure 1. Integration Services

Of course, integrations are far more complex than just “connecting” dots. In this example, I’ve used an example where we replicate Business Partner Customers to two order taking channels – fairly common scenario in Omnichannel Sales.

Source is Master Data System (i.e. SAP MDG) – this is clearly marked as an Application in SAP LeanIX.(of course, we may have multiple Applications within one “box”, but overall object modeling is a different story, not covered by this article…).
Target Systems are B2B Channel and Field Sales – again I am color-coding those as Applications.
From Source to Target Systems, we are replicating Customer – this is Data Object.
Finally, we have an Interface (if we use SAP LeanIX notation), or Integration Service (in a broader sense). We may be “happy” in seeing “only” one line, representing BP Customer Replication. connecting Source and Target Systems… This is probably sufficient for high-level C4[2] diagramming and modeling.
However, if we want more details on Interfaces (or dots “connecting” Applications) – i.e. how it actually works, what are the underlying technology and capabilities, which patters were used etc. – then we must go few levels “below” in the integration hierarchy. Each “parent” Interface (or Integration Service). has one or more “child” Interface Components (or Integration Service Components) – i.e. APIs, IFlows, Queues etc.; and those “child” Interface Components “uses” some IT Components – i.e. SAP CPI, API-M, Azure Service Bus etc.

Figure 2. SAP LeanIX Interface Fact Sheet

In SAP LeanIX each object is modeled with its own Fact Sheet, thus each Interface, whether “parent” or “child”, has its Fact Sheet. There are some powerful features when defining Fact Sheets:

We are defining descriptions, attributes, and we also have a possibility to add links to external resources – i.e. we may have external repositories with functional and technical details in Azure DevOps Wikis or GitHub..
We can link Interface with its “parent” or “child:
We can link Interfaces among themselves into “left/right” flow.
We can link with appropriate Application(s), Data Object(s) and IT Component(s)

Interesting though is to note, general recommendation in SAP LeanIX is to use Applications for Business Applications, while Technical Applications (like SAP Integration Suite etc.), enabling specific Interfaces, we should model as IT Components. Although there is no strict limitation preventing us to set i.e. SAP Integration Suite as an Application (this will of course create different pictures in C4 diagrams), the important thing is to choose the approach “once” and stay consistent.

Figure 3. Integration model

Object models with connected Interfaces can very easily become very complex. But do we really have a choice – not to model full integrations? Is it sufficient to have only high-level Enterprise Architecture in EAM tool?

I guess it all depends on the preferences, but I would say – no, it is not sufficient.

And it’s not about – “hey SAP LeanIX give us possibility to model Interfaces in more granularity” – this is about overall management of the Enterprise Architecture. How can we manage something we do not see? And yes, integration is really a key, or a backbone, of daily operations of any Enterprise:

The Architect View(point) must include sufficient level of details on all Architectural components – otherwise we are “blind” in seeing AS-IS state.
Building new or reusing existing integrations cannot be made without appropriate visibility on the underlaying layers of the Interface(s) or Integration Service(s) – otherwise we cannot make educated decision for TO-BE state
If we do not have adequate view on AS-IS and TO-BE, we cannot properly understand the Gap and build roadmap, planning and strategy.

Integrations @ EA Frameworks

Ups looks like no Integration Architecture domain in TOGAF©[2]?

Figure 4. Where is Integration Architecture

Where is Integration Architecture domain?

Is it part of B. Business Architecture? Probably not, but aren’t we saying that integrations are enabling Integrated Business Processes…
Maybe it’s part of C. Information System Architecture, also (usually) split into Application Architecture and Data Architecture? Looks reasonable to be “somewhere” here, but still, it’s not “formally” listed here…
Or is it D. Technology Architecture? Integrations are often observed as “technology” domain, but this is not entirely correct perception…

Hold on, nothing is “carved in stone”…

Figure 5. LeanIX Application and Data Architecture

Interfaces (or Integration Services) should be observed on the same level as Applications and Data Objects – and in SAP LeanIX metamodel[3], indeed we do see that Interface(s) are part of Application and Data Architecture.

Application “provides” and/or “consumes” Interface.
Interface “transfers” Data Object.

Integrations are not just dots or lines – it’s much more, no matter if we observe some underlaying IPaaS or Event Broker as an IT Component or an Application. And if we accept these guidelines, then we have to “pay” attention to model integrations correctly and fully.

Simple and clear…

Integrations @ AI use-cases?

First “reply” would be – yes of course. But let’s think where we are heading with AI…

MCP Serves can be built on tables – accessing Data Objects directly. It can be done, yes, but do we want this or would we prefer some sort of governance by exposing Data Objects via OData and API Management in between? That is the question yet to be answered… But I know my answer. Of course, in the "world" of Microsoft Dynamic365, MCP Servers are actually based on Dataverse object or tables (not APIs) but this is different, I guess…

Now, what about A2A (Agent-to-Agent)? This is also some sort of integration… Well, if it is integration, it is an integration – “things” are not being integrated on its own...

Why am I bringing AI? AI is now “mixing and matching” with everything. While AI Agents and Agentic AI will most certainly impact integration technology, the need to precisely “craft” Integration Services will not disappear. It may change, but it will not disappear!

Putting this in the EAM perspective – yes of course we do want to manage all out AI investments, ideally in one EAM tool, and SAP LeanIX now comes with AI agent hub[4] – equipped to discover, manage and govern all AI agents. Of course, A2A and MCP are somehow inevitable part of it. Another reason to model integrations correctly and fully...

Integration is the key!

Integration, whether it is fully Decoupled Integration based on Event-Driven Architecture principles supporting Compostable Business (Architecture)[5], or it is some more legacy SOA[6] – in all cases, it is Integration Services which are making things “happen”.

So, it’s a glue connecting Application Blocks, right?

No, no – it’s not “just” a glue! It used to be a “real” glue – well at least in legacy solutions, connecting monolithic “boxes”. But now we are Agile, we are building Systems to be “Compossible”. If Applications are Blocks (one can imagine its LEGO©[7] or equivalent), we don’t want to glue Blocks, because we cannot “recompose” our System of Blocks into something different, we cannot change Blocks, and or try new Blocks..

This “glue” we use is invisible it is by design – its Blocks itself – the way how we build them to “fit” – no matter of their particular shape, or size or color, they can always fit. They can fit “tight” but can be “disassembled” at any time we need to “recompose” the System of Blocks.

Sounds simple, but it’s not.

If we want that flexibility, if we want to avoid “fixing” with glue – we need to design and build with precision. And this is more than just technology stack – this is also about overall strategy – what kind of Blocks we need to connect now, or in future. How do we “craft” integrations so everything can fit – not only now. but in foreseeable future as well.

Who are we?

We are Developers – yes (this is our usual background)! We are Engineers – yes (most certainly)! But we are seasoned Architects – yes as well, very seasoned (if I may add)!

We are versatile Architects who need to know, or at least understand, so many different “things” – not only integration technologies, but Data Models, Applications, even Business Processes. After all, we are not integrating Applications and Systems, we are integrating Business (Processes).

Figure 6. Work of EA for Integration

We can be Solution Architects or Enterprise Architect, just as in any domain – but we must be able to understand much more than “just” integration technology.

Is our work perceived that way? Well, this is a different story…

And again – Integration Services…

I am being subjective – yes. But haven’t I proved how important integration is?

Is the integration work seen and valued as any other Enterprise Architecture work? Very rarely, as integration is usually seen as very technical discipline, part of solutioning, not strategy… There are exceptions (obviously)…

Maybe we need to raise the awareness and change the mindset – proper integration modeling and design is the key for the success in many initiatives – and proper modeling has to come as a result of the Integration Strategy, not just "technical" solutioning on case-to-case basis.

Am I giving too much “credit” to integrations? Yes, but with a reason… Just think, how many projects failed or were delayed because integrations were not properly designed or implemented? And this (usually) has nothing to do with “bad” integration developers and integration engineers…

Does this resonate?