Event-Driven Approach

Available under Creative Commons-ShareAlike 4.0 International License.

As society progresses in the information age, users’ expectations of the information they need at their fingertips has escalated dramatically. User information demands have highlighted several fundamental weaknesses in the traditional approach of transaction processing. First, in order for data to be in a format that can be easily summarized, only data related to classification (e.g., a customer account number or an inventory part number) and quantitative descriptions can be captured. Thus, only a very narrow view of the event is portrayed by the data we collect—for instance, maybe only a financial accounting assessment or a listing of available stock in the warehouse. Second, once transaction data have been summarized, descriptions of individual transactions may be lost, with only summary information available to users.

Event-driven systems capture a complete description of each event, regardless of its economic impact on the firm, and permanently store the individual descriptions of each event. There are many business events that carry no economic impact, which would not be reflected in traditional transaction-oriented systems. Two examples are a sales representative capturing contact information about a potential customer, and a warehouse clerk updating location information when inventory items are moved from long-term storage to a place where “pickers” can get easy access to them. Neither of these events shows up on financial reports, but both are important for running the business.

Of equal importance, however, is the focus on capturing a wider variety of data about each business event to meet the needs of multiple users. Transaction processingsystems have historically been limited in the diversity of data they capture. This limitation is due to an initial focus on automating paper-driven financial processes. While these traditional systems may play an important role in meeting the financial information needs of an organization, they do not necessarily support the marketing, human resources, and manufacturing aspects of an organization very well. The nonfinancial aspects of business events are of great importance to these varied users. Event-driven systems facilitate use by multiple information users with very different needs for information about the events that have occurred within business processes.

Storing data at the event level makes it much easier to retain data related to other nonfinancial and nonquantitative aspects of an event. Ideally, in an event-driven system, the data captured during business processes will be sufficient for someone who was not a party to the event to reconstruct every important aspect of what happened—whether he or she is in marketing, human resources, financial management, manufacturing, or any other part of the organization. Typically, this mandates that at a minimum data be collected and stored related to the four Ws:

Once the event data are collected and recorded, the data can be aggregated and summarized in any manner that a given user chooses. The key is that any aggregations and summaries are temporary and only for the user’s application, but the event data remain available to other users in its original form. For applications such as the generation of financial and inventory reports that are frequently required in the same format, programmed procedures can be developed within computerized systems to generate such reports automatically. Thus, the same needs for financial information fulfilled by traditional transaction processing systems are fulfilled by event-driven systems, but with the latter systems a host of other users’ needs can also be met more efficiently and effectively.

Let us take, for example, a series of events that might take place during the course of capturing a customer’s order, putting through a job order to produce the ordered goods, and delivering the goods to the customer. When setting up our event-basedsystem, we will want to capture multifaceted data to track the progression of the process. To capture the sales order event, we need to record data related to the salesperson and customer (the who), the goods ordered (the what), the delivery location (the where), and the date of sale and promised delivery (the when). This information would then be linked with information already stored that relates to a selected supplier for goods. Based on the combined information, an order would be placed with the supplier. A purchase order becomes a link between the purchaser and the supplier (the who) already in the system, the goods (the what) that have already been entered, the location to which the goods will be delivered (the where), and the delivery date from the supplier to our company (the when).

Notice in our sales example that all of the traditional systems data are readily available. The data required for the Order-to-Sales, Purchase-to-Pay, and Business Reporting processes are all captured and available for processing. But, now if the supplier changes the delivery date, the salesperson can also have immediate access to the change and notify the customer. The salesperson can pull together the necessary data by using links between the changed order information, the sales order, and the customer, and narrow the search down to only the sales that he or she is handling. Very quickly, the salesperson can have the information needed to notify the customer immediately of any delay in shipment.

It is important to note that event-driven systems may appear no different to the average user than more traditional transaction processing systems for collecting business event data. Rather, the underlying data storage and management (that is unobservable to most users) differ, while at the same time new sets of users have access to more relevant information for business decision making. In subsequent sections of this chapter, we will revisit these two approaches to Information Systems and discuss the underlying information technologies that enable their existence.