Why focus on an Event-Driven rather than a Process-Driven Integration Design?

With the rise of Service-Oriented Architecture (SOA) in the late 1990s / early 2000s and a maturing understanding of the benefits of leveraging an integration platform or an Enterprise Service Bus (ESB), a process-driven integration design became a kind of "standard approach" to handle enterprise application integrations.

Starting with BPEL (Business Process Execution Language) and later BPML (Business Process Modeling Language), platform vendors added capabilities to define, orchestrate, and manage integration flows as processes or workflows.

In a process-driven integration design, the integrations are typically modeled as data flows, describing the sequence of processing steps (services) and the transitions between those services.

A desired "happy path" would be modeled, but in addition, the "unhappy paths" would also be modeled to include all possible process deviations, failure situations or technical exceptions.

This is exactly what makes a process-driven integration design extremely complex, even when using more modern platforms such as the Camunda BPML Workflow Engine. Process-driven integration design has many shortcomings and creates challenges for big data integration and real-time application integration for today's data-driven utilities.

In an environment driven by digital transformation, big data and IoT, we in Greenbird strongly believe that an Event-Driven Integration Architecture offsets the shortcomings of a process-driven integration design.

In an article entitled Solution Architects Guide to Event-Driven Integration, Martin Arndt from Servian, a specialist IT consultancy for cloud technologies, data analytics, and AI explains that "Event-driven integration architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events".

Why is this important? Instead of modeling or defining a sequence of processing steps, their transitions, and all business or technical exceptions, an event-driven integration design focuses on identifying and defining the business events.

Here are some examples: "Purchase Order" in a webshop, "Change-of-Supplier" in an energy retail case, "Meter Installed" or "Fieldservice Completed" message in a Smart Meter Rollout project, "Power Outage Alarm" in a Smart Grid Analytics initiative) and then describes how defined services or systems will handle or react to those events.

Here’s another example using the "Meter Deployment" process that includes "Provisioning & Commissioning." Most digital utilities need to implement this process to manage their AMI rollout. Imagine a process-driven integration design and how complex a process model would look after defining the steps for installation and deployment, provisioning and commissioning processes. Next, add all potential process deviations (including incorrect type of meters installed, meter / device ID mix-ups, failing communications to the concentrator, incorrect meter readings during a test phase, and so on) as well as all the technical exceptions (including timeouts during a service call out, data validation failures, and more). You can see how complicated it would be to operate such a model effectively. It's extremely complex to manage, maintain or adapt this type of process. And it's very difficult to make this process perform within strict KPIs in a mass-rollout and full-scale production environment.

Now, let's explore the same "Meter Provisioning & Commissioning" process, but this time focusing on identifying the various events, including:

• Fieldservice Completed / Meter Installed Event
• Meter Detected / Meter Connected Event
• Meter Configured Event
• Meter Readings Events
• Meter Readings Validated Events
• Missing Data Event
• and more

The next stage would be to define which systems or services should react and how they should react to each event.

Compared to a process- or workflow-driven integration design, the event-driven approach is both simpler and, at least for us at Greenbird, a much more natural way of thinking.

Utilihive iPaaS is designed as an event-driven integration architecture and built as a network of reactive microservices. Utilizing an event-driven Enterprise iPaaS and event-driven integration architecture, creates an integration solution that:

• handles big data integrations (i.e. smart metering solutions)
• is built for real-time application integration (i.e. intelligent grid operations, redispatch, trading scenarios)
• is dynamically and elastically scalable accommodating fluctuating (increases or decrease) in data volumes (i.e. massive power outages in case of a Typhoons or Hurricanes)
• can easily be extended or adapted by adding either additional types of events or adding additional event-consumers (e.g. ongoing application landscape modernization, introduction of centralized data hubs or new market communication platforms)
• is easy to operate from an IT point of view