Using Event-Driven Systems to Reduce the Cost of Change

In today's turbulent and high-velocity business world, it is critical for business systems to be agile and quickly adaptable to new requirements, regulations and opportunities. Change needs to happen in days, not weeks or months, and shouldn't require an army of IT staff. Present business systems architecture is often a barrier to agility and cost of change is too high.

Business systems are often a combination of many independent applications running on-premise and, increasingly, in a cloud. The linkages between these applications also need to be agile and quickly adaptable to new requirements and opportunities. This article discusses how business systems are commonly combined and event-driven business applications can increase your organization's flexibility and intelligence to reduce the total cost of change. Here's how.

Time-driven and request-driven interactions are two common types of communication between business applications. Time-driven interactions follow a predetermined schedule that governs when one application requests a service or information from another, such as with polling scenarios. An example of a time-driven interaction is a daily download from a parts inventory system to obtain a current parts catalogue.

With request-driven interactions, an application requests a service or information from another system as and when needed, often as a result of logic embedded within the application, such as with push-pull scenarios. An example of a request-driven interaction is when adding a new customer to your CRM system, it makes a request for your accounting system to add customer as a new Accounts Receivable member.

Time-driven interactions work well when they occur infrequently or exchange just small amounts of information, such as a daily parts catalogue. As businesses demand more near-real-time information, the frequency of time-driven interactions increases. For example, instead of a daily update of vendors' parts catalogue, purchasers require up-to-the-minute pricing and availability. The time-driven approach ultimately leads to decreased performance and scalability as the communication between systems often happens when it is not needed, resultingin unnecessary chatter.

Request-driven interactions provide a better scenario. Applications request a service or information from other systems as a result of logic in the application. This is somewhat better than the time-driven approach as each interaction addresses a specific need in the application. However, the resulting system is not as flexible and efficient as it could be, and adapting to new requirements and opportunities requires internal modifications to applications. This type of change is typically expensive and takes weeks or months.

A third type of interaction is becoming more common -- those where business systems indicate when meaningful business events occur, allowing any consumer to deal with the event as desired. These event-driven interactions are leading to the development of new business applications and solutions allowing businesses to rapidly adapt to change. The event-driven approach is by no means new but it is now getting deserved attention in the business-application realm where reducing the cost of change is critical.

What is an event?

In a business-systems context, the term "event" means that a well-defined, categorized business condition has occurred. An event in this context provides just enough information so that recipients can respond to the specific type and occurrence of the event, as desired. These events are business focused; for example, the addition of a new customer, an employee resigning, a check being issued, a project's expenditures going 10 percent over budget, and so on.

Using an event-driven approach, consuming applications can monitor specific business events and, in response, choose to ignore the event, perform an immediate action, delay a response for better efficiency, or combine the information with that received from other events to gain an integrated view of the business. A consuming application might itself raise new business events that are further processed by other consuming applications. The application that raises the event needs no knowledge of its consumers or how its events are consumed. This results in a very loosely coupled, highly scalable and flexible application architecture with a low cost of change.

In an event-driven environment, there are no fixed consumer-provider relationships as there are in other interaction models. Instead, a business application communicates that a specific business event has occurred and any applications that are listening for that event become the consumers. The consumers receive just enough information to uniquely identify the event and are free to handle it as desired. Other approaches result in large, complicated data sets passed to all consumers regardless of whether they require the full set of data, negatively impacting scalability and increasing cost of change.

In this event-driven model, new consumers can be added without any change to existing business applications. Instead of having to build costly new functionality into existing time-and-request-driven systems, risking their stability and performance, new functionality can be delivered as standalone, lightweight applications deployed on-premise or in a cloud.

An example from social media

An example of an event-oriented environment from the social networking realm is Twitter. A person communicates (tweets) that an event has occurred and those people, or systems, in the twitterverse that have chosen to follow that person will know that the event has occurred. There can be any number of recipients of the event and each can choose to respond, ignore or alter and re-communicate the event. The event is categorized by using tags to convey metadata. Additional information is often available via a URL, ensuring that the original event-notification mechanism is extremely scalable. Solutions are constantly added to the Twitter ecosystem without any change to the core Twitter environment.

A business systems environment can benefit from a similar kind of loosely coupled, lightweight, secure event-driven architecture. The concept of a tweet becomes a concise, well-defined business event and a URL provides a link to retrieve more data regarding the details of the event should the consumer require it. Business applications act as event monitors and respond to desired events, forward, or repurpose the events for additional business use. Innovative business solutions can be created that weren't previously conceivable. While the reductions to cost of change are very attractive, the ability to take advantage of opportunities as they arise can propel your business ahead of the competition.

What about SOA?

Lastly, an event-driven approach does not imply there is no place for SOA, WOA and so on. Quite the opposite is true. Combining the best of an event-driven approach to business systems interactions with the best of supporting architectures such as SOA is necessary to gain the highest business value possible. Taking an event-driven approach to your business systems is the next step in the evolution of your business systems architecture, not a revolution.

About the Author

Ryan Gloeckler is CTO for UNIT4 Agresso, a provider of agile enterprise resource planning software. He provides technical guidance and leadership to the vertical markets serviced by the company. He has been with the company since 1997 and has held a number of positions in both North America and Europe, ranging from technical consultant to technical program manager at Agresso's European R&D center. He can be reached at For more information on UNIT4 Agresso, visit

More by Ryan Gloeckler