EDA: events, real-time and decoupling in SOA


We are entering the age of the Internet of Things, where more and more objects of daily use will be connected to each other, exchanging information and responding to our needs and tastes. Systems integration is taking the leap from the business side to the citizen side, and is doing so globally. In both worlds, getting systems and devices seamlessly and efficiently integrated is absolutely key. The SOA strategy includes a suitable approach to achieve this: EDA, where business events, real-time integrations and decoupling of systems, go hand in hand.


Integrating information systems is complex. The traditional approach to functional areas still exists when defining and executing an ICT project, prioritizing the internal functionalities of the system, the requirements and requests of the responsible user, usability, performance, reports, etc., underestimating the Interoperability requirements.

All those requirements are important, of course. But that vertical and local focus, is behind this complexity when it comes to integrating information systems in an organization.


When the need to integrate an information system arises, there are basically four possible scenarios:

1. The information system is old, hardly modified, and was developed with an obsolete technology.

2. The information system is at an advanced stage of development.

3. The information system is recent, is operational in production, in maintenance, developed in a current technology.

4. The information system is new, will be developed, and the corresponding project is being defined.

Obviously the most favorable scenarios are the last two, but keep in mind that these systems are very likely to be integrated with systems that are in the first two scenarios.

Most likely all of these cases share what I said above: they are focused vertically, in the niche of their functional area. They are not designed to be part of a value chain, a flow of business processes.

However business processes do exist, and the business events that trigger and link them also exist in the real world.

The first working day of each month certain activities must be carried out involving several functional areas.

Every time a customer submits a complaint, a series of validations must be carried out in several functional areas.

Each insurance due date, a series of processes must be launched to issue letters, renew contracts and charge corresponding premiums.

And so on, in countless cases. All these events and processes in the real world exist although information systems seem to ignore them in their initial definition and subsequent construction.


This way of approaching information systems means that when a business event occurs on a master entity (eg clients, invoices, contracts, etc.), the responsible information systems of that entity execute transactions that solve all the functional logic defined for that entity. Such transactions normally include the persistence in their data model, updating the affected entity or entities, and keeping the user informed of the local result of that event.

And anything else?

What effect does this business event have on the other functional areas?


Traditionally this cross-flow has been solved by nightly, weekly or monthly batch processes. Large and complex process chains that are carefully planned to deal all that massive information, deferred in time, because every daily operation of each functional area has been locally registered, but only registered, and only locally.

However, that information has to move forward along the value chain of the organization, so that it can give what it’s supossed to give: value. Kind of business information assembly chain.

Batch processes as a global integration solution are inefficient


With the arrival and expansion of distributed computing and the advancement of communications, the information systems of each functional area have been incorporating new ways of exchanging information, aware of the need to integrate with other systems: invoking remote processes, accessing remote databases, running other applications, or publishing web services to be queried.

However, these advances, what do they really contribute to?

Of course, information systems are more integrated. But that way? Linking some systems to others? Sharing information on demand? Forcing other systems to know the internal design details of my system, so they can access the information I have and what they need?.

In addition, this approach does not eliminate the need for those batch processes. Maybe it allows them to be reduced a bit, but they are still there.


Another possible approach is to move the entire systems map to a proprietary technology that will ensure complete coverage of my value chain, encompassing all my functional areas, and its flow of information.

All right. How much does the license cost?

And what does it cost to maintain that system map?

How much of what it costs is more than I need? How much of what I need has to be adapted to what it costs?

And what do I do with my investments of the last 10-20 years?

How much will the next generation technology cost me?

The proprietary technology as integration solution is negative in the long term


Well, fortunately we have the SOA strategy. And this time his great ally is …

EDA: business events driven architecture.

If events move the business in the real world, why can not they move information between systems that support that business? Why “on this side” business events simply are not taken into account, deferring that flow of information to hours and days after these events occurred?

In an SOA strategy, business events play a key role. Event identification and orchestration are key to maximizing the success of an SOA deployment in an organization.

The major difficulty with the EDA approach is that it requires a significant change in mindset and design of information systems, even from its own definition of requirements. Since we are talking about business events, these must be perfectly identified in the business. Events of all kinds: a call from a client, a bank transfer reception, the expiration of a certain period of time, a patient admission, a claim submission, the arrival of a certain date, etc., etc.

Knowing well these business events, when and where they occur, and what process flow they trigger, is achieved through the analysis of business processes through BPM, the other great ally of the strategy.


The necessary change of focus implies, moreover, the information systems should not know the internal details of the rest of systems, neither internal nor external. They should be forbidden to know those details. They must only know the specifications of SOA services published by the organization to communicate their business events, or to consume the available events.


When this model is internalized, the problem of system integration becomes surprisingly simple, obvious and natural. And systematic. And profitable.

Terribly profitable.


Orienting a systems map to business processes from an orientation to functional areas is a cultural change for the organization. It is complex to be assimilated by those in charge, and both internal and external teams working in the organization. But it is necessary. And it is also a natural evolution, as we will see in future entries where I will use some analogies of the real world to see all this much clearer.

With EDA the SOA strategy promotes integrations in real time as a general pattern


Among the many advantages that EDA brings to the SOA strategy, I would highlight two:

On the one hand, the flow of information through the organization’s value chain is no longer deferred over time. Instead, it occurs in real time, just as it happens in the real world. It actually happens faster than in the real world: a patient’s digital medical record travels faster than the patient himself from the admission desk to his bed.

On the other hand, information systems are not islands anymore. Now they behave like encapsulated pieces of a business information assembly chain. The ecosystem works in real time, with independent systems, coordinated and orchestrated by the business itself. That is, decoupled information systems. So if the organization needs to revise one piece or change it, the rest of the systems map is not affected. Simply ensure that the new piece has the same behavior for the rest.


In short, in our life, in the real world, we are constantly producing events and reacting to external events. Companies and organizations exactly the same. But surprisingly the vast majority of business processes seem to require cycles of hours, days or weeks to complete. The event-driven SOA strategy reorients how to integrate the information systems that participate in those cycles, and implements them as an accurate reflection of the business processes, providing immediacy to the flow of information and decoupling the systems from each other, with the consequent benefit in competitiveness and savings for the organization.


Don´t you think that’s how we should face the age of the Internet of Things?


Te puede interesar



  1. SOA Principle 2: service loose coupling, the key factor. - […] between extremes should be promoted, and for this, the events orientation (EDA), of which we have spoken several times in this…
  2. CEP, boosting services in the SOA strategy - […] you know, one of the protagonists of the Service Orientation Strategy is the Business Event. The EDA approach that…

Submit a Comment

Your email address will not be published. Required fields are marked *

Follow me on social media

Share This