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
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
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
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 Ryan.Gloeckler@agresso.com. For more information on UNIT4 Agresso, visit www.AgressoNA.com.