The Growing Role of Events in Enterprise Applications



  Free preview of Gartner research


Future applications will be more event-driven than today's applications. Five forces are behind this development.

Table of Contents


As enterprises strive to cut costs and improve their responsiveness to customers, suppliers and the world at large, the concept of event-driven design is becoming more widely used. Event-driven business processes and event-driven application systems help enterprises react quickly and precisely to rapidly changing conditions.

Computer scientists have understood the basic principles of events for decades, and events have been widely used in system software, such as operating systems and network and system management (NSM) tools. However, events have been underutilized in business applications, in part because many developers are unfamiliar with them (see "Event-Driven Applications: Definition and Taxonomy" ). Even where events have been used in business applications, they have been mostly just simple events, implemented in graphical user interface event-driven programs, message-driven applications or application integration scenarios. More-powerful complex-event processing (CEP) has been limited to leading-edge niches, such as business activity monitoring (BAM) and computer hardware design.

This is about to change. Events in several forms, from simple events to complex events, will become much more widely used in business applications during 2004 through 2008, because five forces are driving their adoption:

1. Business Strategies Demand Event-Driven Design

There are enormous financial and strategic benefits to implementing event-driven business processes, because they suit the inherently event-driven nature of many aspects of the real world (see "The Business Value of Event-Driven Processes" ). Event-driven business processes are not just traditional processes made to run faster; rather, they have specific characteristics that distinguish them from "business as usual." Line managers and business analysts can understand and implement event-driven processes because they involve familiar business issues, such as changing standard operating procedures, workflows and relationships with customers and suppliers.

Although event-driven business processes are primarily a business issue, they do have implications for the IS department. Many aspects of event-driven business strategies can only be implemented if the underlying application systems are also event-driven — that is, event-driven processes often need event-driven applications. Traditional application architecture is too static, inflexible and cumbersome to implement the kind of sense-and-respond behavior that event-driven processes need (see "The Case for Event-Driven Design" ). Event-driven applications allow processes to be modified rapidly and to respond to errors and exceptional conditions that disrupt conventional processes.

2. SOA Is Helping to Educate Developers on Distributed Computing

The broad-scale migration to service-oriented architecture (SOA) is helping to pave the way for broad adoption of events, because SOA and event-driven computing are based on distributed business components (see "Event-Driven Architecture Complements SOA" ). Many of the same characteristics, such as modularity, encapsulation and interface documentation, that apply to SOA components also apply to event-driven components. However, client/server SOA is vastly different from an event-driven architecture. They address different problems, so neither is right for all purposes. As developers understand the differences better, they will use event-driven design for situations in which it is appropriate. For example, business-to-business (B2B) is an area where the majority of interactions will use events rather than SOA (see "B2B Application Integration Is Typically Event-Oriented" ). SOA and event-driven architecture are complementary; neither is right for all purposes.

3. Vendors Offer Enabling Tools

Vendors are bringing to market more and better development tools and middleware for event-driven applications:

  • Software products, such as message-oriented middleware (MOM) and Web services middleware, for the simpler forms of event-driven applications, are already widely available from most large software vendors. All of the major application server vendors bundle MOM, and all Java 2 Platform, Enterprise Edition (J2EE) application servers also support message-driven beans (MDB), which ease the development of event-driven Java components. Application server vendors are expected to enhance other event-handling features during the next four years (see "Events Will Transform Application Servers" ).

  • More-sophisticated event-driven applications, with transformation, content-based routing and business process management (BPM), are enabled by integration brokers and BPM engines. These tools are widely available as stand-alone products or embedded in application platform suites, integration suites and packaged applications. Although integration brokers are used in only about 20 percent of application integration projects in 2003, half of integration projects in 2006 will use a broker (0.7 probability).

  • The most-powerful forms of event-driven applications require CEP. Numerous small startups and a few established vendors are offering or actively developing CEP. Some general-purpose CEP software is already available, and CEP features are found in some vertical applications and in BAM tools (see "Opportunistic BAM Pits Users Against IT Planners" ).

  • NSM tools were one of the early adopters of CEP for their own internal purposes. NSM tools are also an enabler for event-driven applications because they can improve the reliability and performance of distributed, heterogeneous applications of all types, both event-driven and non-event-driven (see "NSM Products Support Event-Driven Applications" ).

  • Finally, some capabilities for modeling simple and moderately sophisticated event-driven solutions are available, although such facilities are not well-integrated with mainstream development suites or most integration middleware tools (see "Finite State Machines: Modeling for EDA" ). However, modeling for CEP is less mature than modeling for simpler kinds of event patterns, and more research will be required in this area.

4. Standards Will Be Key

Industry standards for event-driven applications are incomplete, but, as they fill in and mature, they will popularize event concepts and bring some consistency among software products. SOA provides a parallel example. Thoughtful application architects knew that SOA was a good idea by the early 1990s, but only now, a decade later, with the consensus adoption (by vendors at least) of Web services standards, is SOA becoming broadly used. Event-driven computing will undergo the same transition as standards evolve. Good architects already understand the benefits of events, but the incomplete nature of event-related standards will retard the adoption of events at the application level during the next several years.

XML, XQuery, Java Message Service (JMS), uniform resource indicators (URIs) and the Internet in general, and J2EE MDB partially facilitate simple event-driven and mediated event-driven applications. However, Microsoft's lack of support for JMS and MDB partially limits the usefulness of those standards. Simple Object Access Protocol (SOAP)-based standards, if extended for better support of events and accepted by all major vendors, would do much to accelerate the adoption of events. Note that event-driven and SOA applications can be implemented with Web services, but neither requires Web services. SOAP message exchange patterns (MEPs) already enable SOA request/reply or one-way event delivery. Organizations such as the Organization for the Advancement of Structured Information Systems (OASIS), World Wide Web Consortium (W3C) and Web Services Interoperability Organization (WS-I) are taking steps toward more standards that will help event-driven applications. For example:

  • Guaranteed delivery — two preliminary specifications have been proposed (WS-Reliability and WS-Reliable Messaging), although more work remains before a single recommendation is adopted, which will happen by mid-2004 (0.7 probability).

  • Web services have a notification specification, but it is too open-ended with respect to the transport protocol to help wire-level interoperability. The notification specification will be improved by year-end 2005 (0.7 probability), but interoperability will still not be fully accomplished between disparate vendors because of incompatible details (0.7 probability).

  • WS-Addressing can be used to support some of the indirection required for mediated intelligent routing, but most aspects of publish-and-subscribe (pub-sub) are missing from the Web services specifications. Web services could add full pub-sub by 2006 (0.6 probability).

  • Web Services Description Language (WSDL) v.1.2 has some features that help standardize the metadata for modules that participate in an event-driven solution, but additional work must be done before metadata for event descriptors is nearly complete.

We are not aware of any standards work under way for the deeper aspects of CEP, although at least one large vendor is developing specifications that could standardize the schema for event-bearing messages of many types. Multivendor standards for CEP message schemas and event-processing languages could emerge by 2007 (0.7 probability), but, until then, CEP growth will be a bit chaotic.

5. Hardware and Network Improvements Will Help

The perennial improvements in hardware and network performance and cost are making event-driven design practical in applications where it had been prohibitively expensive. Event-driven processes are more information-intensive than conventional processes, because events are being generated to mark things that would normally go unrecorded. CEP applications, in particular, are likely to increase network loads by orders of magnitude by 2010 or later. This traffic volume will be justified by the improvements in the effectiveness of applications that exploit events. Application developers traditionally did not see a need to immediately transmit an event message for each state change just to improve the visibility of a process or to accelerate the activities of other business units and other application systems. This is changing as networks become faster, more reliable, more standardized and less expensive (although, of course, event-driven processes are not the automatic result or the only result of Internet standards and fast networks). Other advances, such as the plummeting cost of radio-frequency identification tags, are also making it practical to collect event information far more widely than in the past.


In this Spotlight, we focus on the concept of events because we believe that it is the key underlying factor that will enable certain revolutionary improvements in business processes and application systems during the next five years. Strategies that are being promoted using labels such as the zero-latency enterprise, the real-time enterprise, the event-driven enterprise and On Demand computing (IBM's term) cannot be fully realized without event-driven design (these terms are roughly synonymous). Applications developed during the next 10 years will make more use of events than those developed in the previous 50 years. Simple forms of events, already found in numerous mainstream applications, will become even more widely used, and sophisticated uses of events, such as CEP, will be introduced into a growing range of new kinds of applications.


"Event-Driven Applications: Definition and Taxonomy" — As business requirements escalate and event-enabling technologies become more available, enterprises will increase the number and sophistication of their event-driven applications. By Roy Schulte

"The Business Value of Event-Driven Processes" — Enterprises will need to sense and respond to events as they occur, rather than carrying out predetermined processes developed using historical information. By Roy Schulte

"The Case for Event-Driven Design" — Event-driven design will reduce the elapsed time of business processes and increase enterprise agility through the use of specific design practices and technologies. By Roy Schulte

"Event-Driven Architecture Complements SOA" — Enterprises will need both event-driven architecture and service-oriented architecture, which are compatible but distinct concepts. By Roy Schulte and Yefim V. Natis

"B2B Application Integration Is Typically Event-Oriented" — In business-to-business application integration projects, most interactions between trading-partner applications will be event-oriented rather than service-oriented. By Benoit Lheureux

"Events Will Transform Application Servers" — As event-driven architecture reaches its peak user demand, application servers will become as much event servers as servers of transactions, services and application components. By Yefim V. Natis

"Opportunistic BAM Pits Users Against IT Planners" — Business activity monitoring will cause conflict between users, who consider it a hot "killer application," and IT planners, who consider it a core IT infrastructure. By David W. McCoy

"NSM Products Support Event-Driven Applications" — Many network and systems management products will have a dual role regarding event-driven design by using event technology internally and providing support for event-driven applications. By Cameron Haight and Milind Govekar

"Finite State Machines: Modeling for EDA" — One of the key design tools of the systematic development process for large, complex, event-driven systems will be finite state machines. By Jess Thompson

© 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartners research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.

Not a Gartner Client?

Want more research like this?
Learn the benefits of becoming a Gartner client.

Contact us online



Why Gartner

Gartner delivers the technology-related insight you need to make the right decisions, every day.

Find out more