Event Driven Architecture (EDA): The core of your future-proof integrations?

Comparison

In picture A, the receiver schema affects the development of the sender. This is the because the sender must push all fields required on the receiver side, unless data is enriched via lookups in the Integration Suite.

Introduction

Traditional system transformations are not just costly and time-consuming, they're also failing us when it comes to integration development. It's understandable why some professionals advocate for sticking with tried-and-tested methods like IDocs, which are familiar and have a track record of reliability. But while IDocs were groundbreaking in the 1990s, the world has moved on.

Why traditional integrations are so last season?

Persisting with traditional, tightly coupled architectures is not just an outdated practice – it almost seems like strategic misstep.

Developing and maintaining custom or push-type integrations is costly. Each change or update adds additional coding, testing and deployment efforts on both the sender and the receiver side. It’s not uncommon to see integrations taking months to develop, test and deploy.

Coordinating multiple teams and managing dependencies in these tightly coupled architectures complicates project timelines, often leading to delays and budget overruns. When changes are costly and time-consuming, teams are less likely to pursue new ideas. They simply do not have the bandwidth.

One of the biggest issues with systems that have tightly coupled architecture is their high level of interdependence. A change or failure in one part of the system can lead to unexpected issues in another part. This fragility increases downtime and affects service reliability. Yet these systems must be updated regularly, requiring coordination across multiple domains while increasing the risk of errors and service interruptions.

If you have participated in SAP PI/PO integration maintenance, perhaps you remember those service breaks where you needed to stop integrations due to updating your SAP system? It was a recurring headache to figure out which interfaces needed to stop and start again, in which order and how to communicate about these to third parties and business units.

The Event Driven Architecture approach offers a potential answer to all these issues.

Composable business through decoupling – is this the solution?

The concept of a composable business refers to interchangeable, modular components (i.e. units, companies, organisations, systems, etc.) that can easily be replaced or reconfigured. You have the ability to decouple components. In integrations, this approach is called Event-Driven Architecture (EDA). The idea is that with events serving as the communication medium, systems and components can react to changes independently.

But what if you do not have such a decoupling mechanism in place?

When a change is imminent, you need to decouple integrations at some point. This almost always means you have to redesign some interfaces and rebuild others, such as when migrating to SAP S/4HANA.

The question is: Why would you continue using old integrations when you have the opportunity to rethink your processes and potentially end up with something far better?

It’s a missed opportunity to perform a technical migration only because an old system will soon be unsupported. Such an approach is also costly in the long run. EDA and a composable business mindset can position you to innovate, rather than just maintaining the status quo.

The provocative claim: Cut 50% of your workload with EDA and AI

By adopting EDA and AI to leverage standard events and APIs you can reduce your integration workload by up to 50%. This is not hyperbole; it's a reality that forward-thinking businesses are already experiencing. Best of all, Tietoevry has already proven it in a real-life project.

Here's how you do it:

• Rapid Integration Development: Building integrations with events and existing APIs can be accomplished in a matter of hours. This is the because the setup allows you to focus on core functionalities, instead of getting entangled in complex configurations. It’s an area where you can reduce the workload by 10-20%. The first instance of building the event mechanism (i.e. the architecture) takes some time, but you see the savings later.
  
  
• Accelerated with AI: Mapping data to the receiver's format traditionally takes time, but Large Language Model (LLM) based AI tools have significantly sped up the process. AI models automate tedious tasks and reduce the potential for human error.
  
  You can do this manually, whereby developers ask AI to generate mappings or more advanced architecture. Perhaps you want to integrate AI/machine learning as part of the integration, so that it does the mapping and returns response in a requested output format. Using LLM based tools can reduce mapping time by 20% – sometimes much more. It depends how familiar you are with mapping tools such as groovy or xslt. You should at least have input and output formats available so you can ask the LLM tool to generate mappings/codings for you.
  
  
• Elimination of Custom Integrations: Standard events and APIs handle the heavy lifting, minimizing the need for custom code and specialized solutions. Even if you need custom query APIs, you can build those faster (without custom coding) by creating data views from multiple database tables. You then allow SAP tools to generate the OData API protocol. The time saving is approximately 10-20%.
  
  
• Streamlined API Management: Manage updates and changes at the API level to enable swift adaptations without overhauling your entire system. Employ APIs to enrich data and fill in any gaps without altering core systems. APIs can fetch missing information or enhance data quality. This will speed up testing.
  
  
• Reusability Across Systems: The CloudEvents format for events in legacy (SAP ECC) and in S/4HANA can publish the same events (depending on the ECC version.) This enables seamless transitions and the reusability that is key to efficient migration (assuming both systems have the same APIs available).

A few more things about EDA advantages

Another often-overlooked advantage of EDA is the significant improvement it brings to testing and error handling. EDA eliminates the need to manually recreate complex test data or scenarios, saving time and reducing errors. In traditional integrations (point-to-points), error handling often requires a deep understanding of the application and may involve multiple steps to reprocess data. With EDA and the help of APIs, resolving errors is much simpler. You can simply resend the event message directly into the queue.

EDA also allows for the design of automated retry mechanisms. If the processing of an event fails, the system can automatically attempt to process it again or can route it for manual intervention.

Conclusion

Making an action for a single event can be easy. But if you ignore the need and wait until you have tens or even hundreds of events, then you will probably need more resources to handle them all. You’ll basically end up running scheduled jobs. I recall hearing about someone marketing S/4HANA as a solution to eliminate the need for scheduled jobs. Has this been tried in your landscape? If so, how has it worked out?

If you ever think to use AI as part of your integrations, then asynchronous messages like events are more suitable. Play with AI, approve the results and put the codes, routings and mappings into the tools you use in any way suitable for you. The tools exist, it’s just a question of whether you want to go forward with this path or not.

Join the Conversation

Disagree? Think this is an overstatement? Let's engage in a dialogue. The goal is not unanimous agreement, as there are so many ways you can perform integrations. The intention of this post is to spark discussions that drive progress.