In the previous articles, I was describing how to build an Integration Architecture for the Intelligent Enterprise (Part 1 and Part 2) – but now I would like to go few steps forward…

Network of roads

What is integration?

It is much more than one bridge… It is a road… It is a network of roads…

Roads are foundation infrastructure… Integration Architecture is the foundation infrastructure – integrating “Business Systems”…

If we want to move, we need a road. If we want to move fast, we need a highway. And it takes time to build any road, especially highway:

• not all roads are highways;
• not all roads go straight A to B.

The same this is with the Integration Architecture – building takes time, but once basic network of integrations are built, then we can move fast and we can connect new and new Systems to the already existing infrastructure.

Business Objects for the Integration Services

In the Part 1 article, I was emphasizing on connection between Business Objects and Integration Services – setting the whole concept on a bit higher level of abstraction, then just “Interface” or “API”. API is too technical, and Enterprise Integration is much more than Interfaces or APIs. Integration between Systems is not about Interfaces but about integrated Business Processes – as we know, we are integrating Business Processes, not just System…

So, we are integrating Business Objects (which may be dispersed between various Systems), using associated Integration Services between two or more Systems – whenever there is a need for Business Object date to be partially or fully replicated, or when we need to create/read/update/delete data from one or the other System.

And, in practice, there is no indefinity number of Business Objects which really needs to be integrated in one Enterprise or Organization. Let’s review a catalogue of most common Business Objects to be used for the Integration Services – it’s not hard-coded recommendation, or anything of the kind – it’s just a conceptual reference list, which can be used as a starting point.

Figure 1. Catalogue of Business Objects

Every Enterprise or Organization will, of course, develop its own model of Business Objects, and Integration Services – perhaps using different taxonomy, e.g.:

• use Customer (or Consumer) instead of Account;
• use Prospect as well, instead of only Lead;
• or may not use Lead at all
• …

Or one Business Object may have multiple Integration Services, e.g.:

• Sales Order, as a Business Object, will be utilized by Order Simulation, Order Create, Order Replicate, or specific Order events – and each of those would usually be different Integration Service – with perhaps different Integration Execution, Integration Pattern or Integration Function in place…
• Price, may include only integration of the final Product/Service pricing information, or it may include exchange of various pricing data – like Condition Type, Condition Record, Pricing Procedure

Of course, one Integration Service might have more than one Interface e.g. different flow, logic or even endpoint might be used for create operation, update operation, read operation etc.

Also, integration wise, several Business Objects may in fact be combined in one Integration Service, e.g.:

• For Order in B2B scenario, when we use EDIFACT or X12 for exchanging Sales Orders and Purchase Orders, whether we sell or purchase, in fact we can utilize the same Integration Service – but with different backend processes.
• Various Interactions may share the same Integration Service – disregarding we are interacting with Customer, Supplier, or conducting some in-house communication.
• Customer Actions could be based on some Customer Case (e.g. repair some equipment) or could be part of the generated visit list (for the Business Developer) etc.

Finally, we may decide to split some Business Objects into something more meaningful for the specific Line of Business, e.g. split Customer Attributes to:

• Marketing Attributes
• Customer Segments
• …

In fact, there could be many different variations how we organize Business Objects and associated Integration Services.

Figure 2. System – Business Object – Integration Service

This is now “slightly” upgraded version of the image describing System – Business Object – Integration Service relationship, initially explained in the Part 1 article.

Although, I was trying to stay vendor neutral in the taxonomy for Business Object (relevant for the Integration Services), and build the “model” based on some general best practices[1][2] (seeking some inspiration within LeanIX) and my own experiences – I have relied mostly on SAP ISA-M and SAP Business Accelerator Hub. The sheer volume of already predefined integration artifacts and business documentation, makes it predominantly influencing methodology (and logical choice) when building an Integration Architecture, especially when having SAP backed core (e.g. S/4HANA). But, as already mentioned in the Part 1 article, SAP ISA-M does (or can easily) provide wider context then just SAP Eco-space, and can be used as a foundation for building more agnostic Enterprise Integration Strategy – adopted to the specific needs of the Organization with large heterogenic System Environment.

Adjusting the integration delivery approach

The more mature we are in the Integration Strategy – the more already built & available Integration Services will be at hand ready to be reused.

Figure 3. Reusing Integration Services

Scope of integration is always End-2-End, but how to deliver it – this is different question.

Initially when we were building our ways into proper governance models, we needed to apply End-2-End integration delivery approach – we just needed to invest high to build the network of “roads”. In order our Business Process to flow seamlessly (and this is the ultimate goal, right?) it was necessary to implement beyond the Middleware, sometimes it was necessary to provide delivery of the APIs on both (or all) endpoints, as we do need to “prove” the Solution Concept.

Figure 4.a. E2E integration delivery approach

But at the end, this is not the target delivery model we want.

Matured delivery model foresees we can Publish APIs to the Client System(s) who will just Subscribe to the specific Integration Service, based on their needs.

Figure 4.b. Evolving to PubSub integration delivery approach

In the ideal circumstances – this PubSub (Publish-subscribe pattern)[3] can be managed and orchestrated only through Middleware, but in some cases, some adjustments would still be needed in the Core/Master Systems – we might have to enhance some Integration Services, or builds some new Integration Services. Over time, some Integration Services would be retired and replaced with some new solutions etc.

In majority of the cases Middleware would have to be enhanced with new flows, and transformations for the new subscribers – in cases of the Broadcast Integration Pattern, e.g. when we are doing Event Notifications or Data Replications, minimum needed would be to extend multicast with the new branch for the new subscriber.

What to expect next?

A bit more high-level thoughts…

As we are climbing through the ladder of the “continues” progress, where do we see an end? Well, there is no end in fact – because there will always be something new… Some new ladder…

As described in one of my earlier article[4], we are now heading to the “state” of the Continuous Transformation[5] – raising from Client Server Architecture; through Service Oriented Architecture and Cloud, Mobile, Big Data Architecture; to Intelligent Enterprise Architecture.

Figure 5. The Ladder…

We do not know (with certainty) what is next – because we do not know what is the next “big disruption” which will re-shape IT industry… Uber, Amazon, ChatGPT – they were (or still are) creating major disruptions – but we could not tell what the next “big one” would be, before the “disruption” itself emerge…

How to be prepared?

We cannot runaway, we cannot hide, so let’s embrace the change!

In the integration world – let’s think “outside of the box” of SOA or API-first…

Figure 6. Interoperability in the Integration Architecture

No, there is nothing wrong with SOA or APIs or Event-Driven Architecture; but we cannot “box” ourselves in one or few prescribed patterns – in fact various patterns will coexist and new will emerge – let’s call this pattern as Interoperability Integration Architecture[6]… Or let’s not call it any name at all, does not matter… We have too many “buzz-world” already…

Final Thoughts & Conclusions

In my articles, I try to focus only on the Solution Concept, an idea “how to do”…

As we know, “one size, does not fit all” (Organizations)… Each Organization will have to find its own way – and this is where an Architect, responsible for building the Integration Strategy, will lead the way.

In this roadmap, using any “assistance” which enables speed and agility – can be of the enormous value.

Although one could try to build Integration Architecture around core Systems like SAP S/4HANA without SAP Integration Suite – would this be the right choice for the Intelligent Enterprise? For me it is very difficult to imagine S/4HANA as a “big” and “bulky” monolithic System – it has evolved long time ago into Digital Core[7] working/collaborating together with SAP Business Technology Platform (including, of course, SAP Integration Suite) as a foundation of the Intelligent Enterprise – with seamless integrations and seamless possibilities…

If you are using S/4HANA as your backend core – expanding further with SAP ISA-M and SAP Application Extension Methodology[8] is the next logical step forward…

I am inviting you to keep following relevant blogs and community resources, post and answer questions, and read other posts on the integration topic.

And of course, share your thoughts and comments on my article, in the comments section.

Acknowledgment

*) Intro photo by Ed 259 on Unsplash

References

[1] LeanIX: Best Practices to Define Data Objects (leanix.net)

[2] LeanIX: Integration Architecture – The Definitive Guide

[3] PubSub: Publish–subscribe pattern – Wikipedia

[4] SAP Community Groups: Enterprise Architecture in the era of Agile…,

[5] Continuous Transformation: #sinergija22 #speeditup

[6] SAP Community Groups: Agile EA – from SOA to Interoperability

[7] SAP Digital Core: SAP S/4HANA: The Digital Core

[8] SAP Blogs: Introducing SAP Application Extension Methodology version 2.0