5
Types of Event-Processing Applications

A list of business problems for which event processing is the preferred solution would help you to determine where it could be applied in your organization; however, such a list would be incomplete and out of date the instant it was compiled. The ever-increasing variety of business problems for which event processing is being used profitably will make any such list obsolete. A better approach is to use a systematic framework to evaluate whether event processing in general and event-driven architecture (EDA) and complex event processing (CEP) in particular are appropriate for a given problem. Let us look at a framework built upon the material presented in the preceding chapters. Let’s use this framework in this chapter to evaluate the suitability of event processing for existing business problems, and in Chapter 12 to predict how event-processing technologies will evolve.

Note: A list of business problems for which event processing is applicable will be incomplete and out of date the instant that it is compiled.

Features Driving Demand for Event Processing

This section discusses features of business problems that drive increasing demand for event-processing applications. The presence, or absence, of each of these features in a problem is one of the measures used to evaluate the appropriateness of event processing for the problem.

As you read in Chapter 1, the system drivers for event-processing applications are timeliness, agility, and information availability. The technology push and consumer pull drivers for event-driven interactions were summarized in Chapter 2 as the PC-cubed (price, pervasiveness, performance, connectedness, celerity, and complexity) trends. You also saw that the informal expectations people have about event-driven components, as well as the formal contracts that designers use to specify components of event-driven systems, are different from those for more traditional time- and request-driven systems. Chapter 3 showed how EDA and CEP help improve business. You explored different categories of benefits and costs in Chapter 4, organized under the REACTS (relevance, effort, accuracy, completeness, timeliness, and security) rubric. Now, you’ll see how these concepts help you evaluate whether the best IT applications for a business problem should, or should not, include EDA components.

As you saw in Chapter 2, most IT systems are hybrid systems with components that are event-, time-, or request-driven. Good designs use components that are tuned to execute the functions they perform; even in event-processing applications, some functions are best carried out in a time- or request-driven manner. This chapter helps you determine whether EDA components are part of the best IT solutions to a given business problem. This chapter identifies the characteristics of business activities for which hybrid systems containing event-driven components are the best technology:

Looking outside the virtual enterprise to detect critical events

Responding to rapidly changing situations by keeping up with newly generated data

Managing by exception

Adaptability—adapting the behavior of business activities as needs change

Instrumenting business activities in a virtual enterprise for purposes of business intelligence, application monitoring, and application integration

Looking Outside the Virtual Enterprise

Much of enterprise IT, from the 1950s through the 1980s, focused exclusively on services within the virtual enterprise. Things have changed: now IT is expected to help the enterprise respond rapidly to conditions outside the virtual enterprise, as depicted in Figure 5-1.

An enterprise can ensure that interactions among all agents within the virtual enterprise follow well-defined protocols and speak the same language—that is, use the same schemas, the same meanings for phrases, and agreed-upon services. A supplier may be required to submit a quotation to a manufacturing company by making a request for a submit-quotation service provided by the manufacturer. The supplier’s request must use the schemas and meanings specified by the manufacturer so that the service can process the request. The manufacturer, for example, may require a supplier of ball bearings to specify the size of a bearing in terms of diameters in millimeters as opposed to radii in inches. When you buy an item from an online retailer, you describe the item you want by filling out a form specified by the retailer; you are, in effect, using the retailer’s language and the retailer’s service. Agents within the virtual enterprise can interact with each other using services and languages approved by both parties.

Figure 5-1: “Looking outside the enterprise.”

Agents outside the virtual enterprise may be unwilling to interact with agents within it by using services and languages specified by the enterprise. An enterprise’s competitor, for example, will not keep the enterprise informed about the competitor’s actions by invoking the enterprise’s services. Government agencies will not inform an enterprise about new regulations or unemployment figures by using schemas and services specified by the enterprise. The enterprise must actively acquire external information and make sense of it.

Agents within a virtual enterprise may collaborate with each other using time- or request-driven interactions. For example, a buyer in the enterprise may meet with a supplier at a specified time and place, or a business activity may invoke a service in a logistics company. Agents, such as competitors, outside the virtual enterprise do not carry out actions at the times of the enterprise’s choosing. In a smart road management system, cars enter toll booths when drivers choose, not when the system determines that they should. In a smart electric grid system, customers turn on appliances when they want to. Patients fall ill and need medical care at unscheduled times. These actions are driven by external agents and are, therefore, inherently event-driven.

Note: Use event-processing technologies for applications that sense and respond to activity outside the virtual enterprise.

Responding to Changing Situations

Some situations change so rapidly that applications cannot keep up with the changes. For these business situations applications that keep up with arriving data, but drop items occasionally, are better than applications that never drop items but fall behind. Cross-trading is an example of such applications. Cross-trading applications make money by matching offers between buyers and sellers of a stock within a firm; however, not identifying a match isn’t a catastrophe. Normally, buy and sell orders are matched in an open exchange, but a firm can match the buy order of one customer with the sell order of another within the same firm, provided the transaction is executed in accordance with regulations. If the firm cannot match buy and sell orders within specified times, the firm is required to send the orders on to an exchange. Regulatory agencies impose severe penalties if the application falls behind and the firm holds buy and sell offers for longer than the permitted time. Therefore, the firm passes a buy or sell offer to an exchange when the offer is held for a time near the regulation limit. The firm makes more money if it executes more matches, but the system does not incur severe penalties if it misses making a match. Event processing is more suitable than request-driven interactions for such applications that must keep up with arriving data in a best-effort fashion and that don’t have to process every single item of data.

Online transaction processing (OLTP) applications, such as airline reservation systems, handle high data rates using request- or event-driven interactions. Ticket purchases are required to be transactions—that is, either the purchase is aborted (the customer doesn’t pay for the ticket and the airline doesn’t sell the ticket) or the purchase completes successfully. Many business interactions do not have to satisfy the stringent constraints of transactional processing, and EDA applications are particularly cost effective in these situations. Though EDA can be used for transactional systems, a more common view of transactional interactions is that they are requestreply interactions. EDA applications are often overlaid on top of request-driven applications where EDA applications capture and act on events generated by the request-driven substrate.

A commonplace illustration of event- and request-driven interactions is the way in which you pay the toll at a tollbooth. Fifty years ago, all tollbooth interactions were request-driven and transactional: the tollgate was closed when you got to the tollbooth, you paid cash, and then the tollgate opened, signaling the completion of the transaction. Now your car can be equipped with wireless payment mechanisms, such as FasTrak, that allow you to drive through. There are no gates that stop you. A toll system that lets people go through without stopping and later penalizes the few people who pass without payment is more efficient than a system that stops everybody and lets them through only after they pay the toll. Likewise, some applications that asynchronously send data items, as the items are generated, are more efficient than applications that send data items to their destinations in a synchronous request-reply fashion. In the smart electric grid, phasor measurement units are sent from multiple sensors several times per second to event-processing agents; a lost measurement is not a catastrophe, and so event-driven asynchronous messages are adequate and efficient. A synchronous request-reply transaction to transmit each phasor measurement is slow and unnecessary.

Note: Use EDA for applications that must respond quickly to situations that change rapidly and asynchronously, and where interactions do not have to be transactional.

Use EDA layered on top of transactional applications to capture and process events generated by transactions.

Managing by Exception

Colonel Alfred D’Amario, in his book Hangar Flying (AuthorHouse, 2008), describes flying an airplane as “hours and hours of sheer boredom punctuated by moments of stark panic.” Like instrumentation systems that alert airplane crews about exceptional conditions, event-processing systems help organizations deal with atypical events. People aren’t as effective as computers in remaining alert while monitoring the environment for signs of unusual events. Event-processing applications support management by exception (MBE)—the applications acquire and analyze large quantities of data, detect atypical situations, and initiate responses. This frees organizations from having to pay attention over long periods to multiple high-throughput data streams to detect and respond to uncommon conditions.

A seismic network for first responders that detects, locates, and identifies collapsed buildings, broken bridges, or buckled roads is a system that supports management by exception. Seismometers and accelerometers measure thousands of values each second, and many trillions of measurements may be made between the severe earthquakes that destroy buildings. The system provides a great deal of value when the unusual situation occurs.

The many examples of management by exception include applications that warn management about patterns of trading that indicate fraud, respond to overloading of the power grid, determine that peanut butter from a factory is contaminated with salmonella, detect mad cow disease, and identify drivers who run toll booths without paying. Management by exception enables systems to monitor huge volumes of activity efficiently because only a small fraction of the activity needs exceptional handling. Most stock transactions are not fraudulent, the power grid is rarely overloaded, most peanuts aren’t contaminated, most cows don’t suffer from mad-cow disease, and most drivers don’t try to run through tollbooths without paying. Management by exception is an inherently event-driven activity since the occurrence of the exception is an event.

Smart infrastructure systems—smart bridges, smart water systems, and smart hospitals, for example—deal with high rates of events. Strain gauges on bridges, phasor measurements on the electric grid, and electronic monitors on patients measure many values each day. Only a few seconds in a day are critical and require extensive analysis; most of the time systems behave in their usual fashion. In normal periods smart systems monitor data for unusual situations and may log data, but otherwise do relatively little; when exceptions arise they carry out computations, communicate data, and actuate responders to deal with the exception. Our nervous systems work in the same way. Most of the time our bodies operate in normal mode, but when we detect threats we transition to fight or flight mode: adrenaline is released, heart rate increases, and blood is pumped into the major muscles. Smart people and smart systems often manage by exception.

Note: Use event-processing technologies for applications that support management by exception.

Let’s compare the following two applications with respect to the variety of actions that the application must handle: (1) an application that customers use to configure and purchase computers online, and (2) an application that detects cybercrime. A customer specifies many parameters to configure a computer: the machine type (notebook, laptop, desktop, or tower), size of memory, number of hard drives and USB ports, and so on. Though the vendor does not anticipate each customer’s specific request, the vendor does anticipate and restrict the types and ranges of requests. Unlike transactions used to configure computers, the cybercrime application must deal with more varied and unanticipated actions—not all criminal behaviors are foreseen. Criminals remain undetected by hiding evidence of criminality. Detecting criminal or noncompliant behavior often requires CEP.

Responses to anomalous behaviors are, perforce, less well defined and more fluid than responses to anticipated situations. Applications for configuring computers online can be request-driven because behaviors generally fall within anticipated ranges. Applications that detect cybercrime and other anomalous behaviors are largely event-driven because the detection and characterization of the behavior is a key part of the application.

Detection of anomalous events and management by exception are not exclusively event-driven; exceptions are also raised in request-reply interactions. When you fill a form on the Web that asks for your address and you leave the address field blank, the application will raise an exception and display a message such as “this field is mandatory.” So, what makes EDA and CEP particularly better for detecting unusual patterns and management by exception?

An unfilled field in a web form is an exception in a single interaction whereas the detection of a pattern that indicates a significant anomaly, such as cybercrime, requires analysis of data from multiple sources over a period of time. Trading stock “ahead” and “interpositioning” of trades by trading specialists are violations of federal securities laws, and such trading violations are not detected from a single violation but rather from a time-series analysis of trades. Warnings of tsunamis are based on fusion of data obtained over time from many sensors. CEP is useful when characterizations of anomalies are complex and when detections of anomalies require analyses of data gathered from multiple agents across time.

Note: Use event-processing technologies for applications that must react rapidly to unusual situations.

Adaptability

EDA applications can be more agile, and more adaptable, than request-driven applications. As discussed in earlier chapters, an important difference between event-processing interactions and time- or request-driven interactions is that the creation of an event object is decoupled from its eventual use. The dissemination network is responsible for getting event objects from agents that produce them to the agents that need to act on them. The dissemination network also stores event objects for later use by consumers, and the network may have databases to facilitate dissemination. A common structure of event-processing networks (EPNs) is a “hub-and-spoke,” with agents—including sensors, responders, and other types of event-processing agents— at the spokes and the dissemination network at the hub. The spokes produce, consume, and process event objects. The hub receives event objects from the spokes and sends (copies of) event objects to the spokes that need them. An alternate view of the huband-spoke structure is that of an event-object bus (the hub), with producers pushing data on to the bus and consumers pulling event objects from the bus. An EPN is flexible to the extent that event-object producers and consumers can be modified, attached, and detached from the bus easily; and the flow of event objects through the bus can be modified easily. Most implementations of EDA are, indeed, flexible.

EPNs don’t always have bus structures. Indeed, the dissemination network can be hardwired, with each producer sending event objects in proprietary formats to specific ports of specific Internet Protocol (IP) addresses. Hardwired networks are, however, generally less flexible. The bus structure is a logical structure, not a physical one, and the bus may be implemented as a distributed system. The specifics of the implementation are not important at this stage; what is important is the logical separation between producers and consumers of event objects on the one hand and the dissemination network on the other.

An EDA application can grow by accretion with the addition of agents and event object types that were not planned for when the application was first designed. For example, a record of a credit card transaction is an event object. A credit card transaction is itself a request-reply interaction between a retailer and the bank that issued the card, but the record of the transaction is an event object that can be used by other agents at other times. Fraud-detection applications act upon the information recorded about the credit card transaction to evaluate the probability of fraud. Customer relationship management (CRM) applications act upon the same information to determine whether the customer should be offered promotions. Risk-management applications act upon the same information to evaluate lines of credit. Corporate performance management (CPM) applications use the information on an aggregate level to tell top management about the overall health of the business. (Chapter 10 discusses performance management in more detail.)

If an EPN is represented by a hub-and-spoke structure, then the spokes are agents in applications such as CRM, fraud detection, risk management, and performance management, while the hub is the dissemination network. New applications, new producers, and new consumers of event objects can be added after the system is in operation. Adding spokes to a hub-and-spoke structure is generally easier than changing an organizational chart or some other graph structure. The key to flexibility is the dissemination network, and many flexible networks are available today.

Note: The decoupling of production, consumption, and copying of event objects results in looser coupling between components of event-driven systems than request-driven systems. Use event-processing technologies when loose coupling and adaptability are key requirements.

Instrumenting the Virtual Enterprise

Instrumentation to sense and respond to events helps make enterprises more efficient. The events that are detected may be routine events—such as bags moving along a conveyor belt, patients moving from one hospital ward to another, or steps in a business process—or they may be unusual events such as patterns that indicate fraudulent activity. Now, let’s look at the combined benefits of efficiencies gained from instrumenting routine business activity coupled with the benefits of timely responses to unusual high-value events.

The benefits of instrumentation and EDA applications for normal activity are tangible and measurable as part of routine business operations. The potential benefits from timely reactions to rare but huge opportunities or major threats become evident when the events occur and the business responds more effectively with EDA than without it. A business case can be made for instrumentation and EDA that provides immediate and continuing value in normal operations with the added advantages of massive gains from critical rare events. There are many examples of such business cases; let’s start with an example in astronomy.

Astronomers use telescopes to study the cosmos in a time-driven, scheduled fashion and to detect important rare events. The Report of the National Science Foundation, Division of Astronomical Sciences, Senior Review Committee of October 22, 2006 states: “The rise of organized, transient astronomy, with its enormous demands for follow up observations of supernovae, gamma ray bursts, and microlensing events, requires telescope networks that respond to alerts by immediately interrupting the background programs.”¹ Astronomers schedule time on telescopes well in advance based on the positions of objects in the sky. When an important transient event occurs in the sky, time-driven control of telescopes is interrupted and telescopes are reoriented to observe the event. Astronomical event objects are called VOEvents—these are documents encoded in XML. The scientific community is considering automatic triggering to event-driven control when a VOEvent arrives; the current control mechanism is manual. Telescopes are instruments that provide value to astronomers on an ongoing, regular basis, and also provide high value in responding to rare, significant events.

RFID (radio frequency identification) tags can help pharmaceutical companies institute flexible, demand-driven supply chains, and the benefits of this event-driven application are tangible and measurable on a day-to-day basis. In addition, the application helps to detect and respond to rare, critical events such as diversion of drugs and the addition of counterfeit drugs.

Summary of Features Favoring Event Processing

Event-processing technologies are also used to deal with applications that don’t have the features discussed here; however, most event-driven applications do have one or more of these features. The key features were identified in Chapter 1: agility, information awareness, and timeliness. Let’s add detail to these features to help us determine whether event-processing technologies are appropriate for a business application. We refer to the features of business applications that favor event processing as “problem features” or the “A-E-I-O-U features”:

A Adaptability—adapting to changes in a system, the environment, or the user

E Exception—management by exception; responding to exceptional events

I Instrumentation—instrumenting a system to measure and record events so that the system can be improved

O Outside—responding to events outside the virtual enterprise

U Unanticipated—responding to unanticipated situations

Event processing also provides features such as greater efficiency that play critical roles in our analysis of whether event-processing technologies are appropriate for a business domain; however, this book does not explicitly highlight evaluation parameters, such as efficiency and total cost of ownership, because these parameters are used to analyze all systems.

A Framework for Analyzing Which Business Domains Are Suitable for Event Processing

In this section, we propose a framework, based on the material presented earlier, that helps you determine whether EDA is the best choice for a problem you face. We use the framework to identify business problems suitable for EDA in different domains. The framework is based on the following:

The types of contracts, or expectations, of agents in different interactions

The cost/benefit measures

The features of problems, such as the A-E-I-O-U features, that favor different types of interactions

The framework focuses on how information flow impacts what the business does and not on information as an end in itself. As a consequence, the framework must explicitly consider uncertainty, the likelihood of error, the costs of mistakes, and the benefits of timeliness. We review, very briefly, the elements that go into the framework:

1. A problem that has any of the A-E-I-O-U features is a candidate for event-processing technology. The degree to which these features are pronounced in the problem determines whether event processing, often combined with other technologies, is the preferred choice.

2. We also compare the expectations we have about the proposed application with expectations we have about components in time-, request-, and event-driven applications; if the expectations are similar to those for event-driven applications, that’s a clue that EDA is appropriate.

3. If we decide, based on the A-E-I-O-U features and comparison of expectations, to evaluate EDA solutions, we then compare the REACTS cost/benefit measures for an EDA solution with alternative approaches and choose the approach with the best cost/benefit ratio.

4. Event-processing technologies may not be the best solution for a business problem today but may be in the future. So, we’ll also look at trends, such as the PC-cubed trends, to gauge how event processing may be used in the future.

Note: A systematic framework for analyzing which business domains are suitable for event processing is more useful than a list of domains.

Applying the Framework to Determine which Business Domains Are Suitable for Event Processing

Many business activities are suitable for event processing, and an exhaustive list is not instructive. Our focus here is on applying a framework that will help you evaluate the suitability of event processing for any problem. Next, we’ll carry out the exercise of applying the framework to several domains. This brief exercise illustrates the use of the framework but is far too brief to be a complete analysis of different vertical markets.

Defense and Homeland Security

Problems in defense, security, and crisis management exhibit all the A-E-I-O-U features. Many of the devastating events handled by homeland security agencies, ranging from tsunamis to chemical spills, are rare exceptions to normality. Systems continuously monitor the environment for signs of these events and take action when the events are detected. These situations unfold rapidly, asynchronously, and unpredictably, and responses to events must be rapid as well. Agencies must respond to critical events that occur outside the agencies. And though agencies plan extensively for crisis situations, each crisis has unanticipated features.

The kinds of expectations we have for components in defense and homeland security applications are more typical of expectations for components in EDA than of expectations for components in request- or time-driven applications. We expect components to sense and respond to conditions continuously. For example, they must sense when contaminants are in the water supply and take remedial action, predict when and where a hurricane will make landfall and warn citizens, and detect intrusion into a network and then identify and shut out the intruder. We don’t expect a server to tell a client the condition of the water supply, the location of a hurricane, or the presence of an intruder only when the client makes a request.

An analysis of each of the REACTS cost/benefit measures demonstrates the value of EDA in general and CEP in particular. Military applications are tuned so that only highly relevant information is pushed to soldiers on battlefields. Technology is helping soldiers communicate relevant information—such as their location, their health status, and the status of their equipment—with little or no effort. Event-driven applications and sensor technologies provide more accurate situation awareness; for example, remote-controlled unmanned aerial vehicles, such as the Predator, give soldiers views of the terrain. The benefits of event-driven applications in defense, when compared with time- or request-driven applications, in terms of accuracy, completeness, and timeliness, are self-evident. Security is a problem, however, as EDA applications are as vulnerable to attack as are other types of applications. Nevertheless, military, security, and crisis-management problem domains exemplify areas where EDA and CEP have great and obvious business value: these problems have all the A-E-I-O-U features and have excellent cost/benefit values for the REACTS measures. Defense and homeland security applications are examined in more detail in Chapter 12.

Track and Trace

Most shipping, trucking, railroad, and other logistics companies use track-and-trace applications that allow the company and its customers to track the location of an item and trace its path from shipment to destination. Concerns about mad-cow disease and bioterror attacks are leading toward a national farm identification system that tracks every farm animal with an identifier and possibly a tag or microchip from birth to death. Contaminations of milk products with melamine, peanut butter with salmonella, and spinach with E. coli have highlighted the importance of ensuring safety in food supply. Tracking food sources, both animal and vegetable, helps identify problems early and minimize risk.

Electronic pedigree systems record major events—location of manufacture, shipment, prior sales, and trades—that occurred over the lifetime of items such as pharmaceutical products. All of these applications track events in the items’ histories—whether they are packages, cows, tomatoes, medicines, or data. Some applications send alerts when histories deviate from norms: for example, when a food shipment that should have been kept at temperatures below a specified threshold is exposed to higher temperatures for an extended period, or when a package that should have arrived at a trans-shipment station by a specified time doesn’t arrive.

Expectations for track-and-trace applications and components are closer to expectations for EDA systems than to those for systems based on request-driven or timedriven interactions. We want to initiate the process of detecting a salmonella outbreak or tracing a lost package as soon as possible—not on a once-a-month or even a oncea-day basis. And we expect these components to be continuously active carrying out tasks; we don’t expect them to remain passive, waiting for requests.

Most track-and-trace problems have some of the A-E-I-O-U features. The consequences of poor track-and-trace systems may be severe; in the food industry the consequences include deaths and loss of confidence in basic food staples such as milk and peanut butter. An analysis of the REACTS measures shows that CEP is an appropriate technology for many applications dealing with track and trace. The detection of a salmonella or E. coli outbreak, for instance, requires analysis of time-varying data from multiple sources in different organizations. Pinpointing the outbreak to a specific peanut factory or spinach plant requires a great deal of analysis. A study of the cost/benefit measures suggests that public health agencies, fast-food chains, agribusinesses, package-handling companies, and indeed all enterprises that need to track and trace items benefit from EDA. The PC-cubed trends tell us that event processing will be even more widely applied in the future for track-and-trace applications. As described next, a look at e-pedigree systems for tracking pharmaceutical products shows that event processing will be adopted more widely in the future.

The U.S. Food and Drug Administration (FDA), defines a drug pedigree² as follows:

A drug pedigree is a statement of origin that identifies each prior sale, purchase, or trade of a drug, including the date of those transactions and the names and addresses of all parties to them. Under the pedigree requirement, each person who is engaged in the wholesale distribution of a prescription drug in interstate commerce, who is not the manufacturer or an authorized distributor of record for that drug, must provide to the person who receives the drug a pedigree for that drug.

Electronic pedigrees (e-pedigrees) help combat counterfeit drugs and diversion. In the future, wholesalers will be required to have drug e-pedigrees to acquire or sell prescription drugs. California and other states have passed legislation requiring electronic records of pharmaceutical drugs; these laws are planned to take effect at different times in different states. Let’s analyze where track-and-trace technology is headed in the pharmaceutical industry from the vantage point of the PC-cubed trends. Trends in prices of RFID and bar-code technology, when compared to costs and errors of manual tracking, favor automation and event processing. The performance of business intelligence systems at ever-decreasing costs will allow many points along the supply chain to track the provenance of drugs. Increasing complexity of regulations in different countries, the global supply chain for pharmaceutical drugs, and the need for rapid detection of counterfeits all point to increasing use of event processing. All the trends—price, performance, pervasiveness, celerity, connectedness, complexity— in the context of greater enterprise agility and situation awareness tell us that IT in general and event processing in particular will play a greater role in the pharmaceutical supply chain.

Smart Infrastructure

Increasing amounts of funds in many countries are being allocated to public infrastructure such as roads, bridges, the electric power grid, and the water supply. Increasing power and decreasing costs of sensors, responders, and CEP agents makes “smart infrastructure”—a combination of traditional infrastructure with IT—more costeffective than traditional infrastructure. The term “cyber-physical systems” has been coined to describe systems that conjoin information systems with physical systems to provide powerful capabilities. Buildings with active controls that determine how the buildings respond to earthquakes are examples of cyber-physical systems; the building without controls may collapse, but the building with sensors, processing agents, and responders is expected to be more resilient. A smart infrastructure is an infrastructure integrated with EDA applications. Cyber-physical systems have EDA applications tightly woven into the design and implementations of physical systems.

Monitoring the Health of Civil Infrastructure

Infrastructures, such as bridges, have been traditionally inspected on a time-driven basis. As the infrastructure ages, the frequency of inspections has to increase because the mean time to failure decreases. EDA applications integrated with the infrastructure can improve reliability without requiring more frequent inspections. Buildings and bridges can be equipped with sensors such as accelerometers and strain gauges that transmit data to event-processing networks that detect potential problems. Analysis of sensor data from instrumented buildings under normal conditions, before and after an earthquake, can help determine if hidden trusses and welds in the building have been damaged. The possible failure of transformers in the electric power grid can be predicted using data from sensors that measure parameters such as temperature, gas dissolved in transformer oil, and transformer vibration. Work crews are sent to inspect those components that are identified by the EDA application as likely to fail. A combination of periodic inspections and sensor-based health monitoring of infrastructures reduces the likelihood that the public will be exposed to catastrophic failure.

The A-E-I-O-U Features

All the A-E-I-O-U features that favor event processing appear in smart infrastructures. The systems are required to be adaptable to deal with additions and replacement of components such as sensors and actuators. Early-warning mechanisms manage by exception: smart infrastructures—roads, ports, buildings—behave normally most of the time, but rapid response is required to deal with anomalous behavior. Instrumentation of civil infrastructure monitors its health. Applications must respond rapidly to situations outside the enterprise, and they must deal with unanticipated situations. The expectations we have about components of smart infrastructure are closer to expectations for EDA than expectations for request- or time-driven systems.

The REACTS Cost/Benefit Measures

The values of the REACTS cost/benefit measures depend on the specific application; however, an analysis of these measures for many businesses that manage access to fixed resources—roads, power grids, and bridges—shows that EDA applications are cost-effective in managing smart infrastructure. Consider, for example, a traffic-management system. The users of the system include commuters, security personnel, and transportation officers. The information that is relevant to each group of users is well known, and so ensuring high relevance of traffic information displayed on dashboards is not a problem. The displays that commuters and transportation officers need are well defined, and different users don’t need extensive tailoring of displays to fit their specific needs. So, the effort required to customize an application to each user is small. The system is helpful even if it has some inaccuracy—for example, a commuter derives benefit from a system that warns that traffic ahead has been slowed down to 30 miles per hour even if that true speed of traffic is only 20 miles per hour. Commuters also benefit from a system with some degree of incompleteness; for example, the system may not warn about a traffic accident and consequent slowdown of traffic for some time; however, both false positives and false negatives can be corrected quickly. Traffic-monitoring applications benefit from “crowd-sourcing” sensors: commuters report problems or GPS devices on cars monitor speeds. Timeliness is not a major problem; commuters can benefit from the system and adjust their commutes even when information is several minutes late. Security is an issue—the system must be protected from attacks, but the number of points of attack is more limited than in applications such as the smart electric grid. The benefits from reasonably timely, accurate, and complete information are that commuters have shorter commutes that adapt to changing traffic conditions.

The PC-Cubed Trends

The PC-cubed trends tell you that event processing (and “smarts” in general) will play an increasing role in infrastructure upgrades and new designs. The ratio of costs of information systems to costs of raw material—oil, iron, and steel—and costs of building physical artifacts such as cars, electric power transmission lines, and dams continues to change in favor of information systems. The decreasing price, increasing pervasiveness, and greater power of sensors, actuators, and computing devices will result in traffic systems, cars, bridges, and buildings becoming smarter, with the capability to sense and respond to changing conditions. Demands for greater celerity, the increasing regional and global interconnectedness of transportation systems, and the complexity of interactions—with a traffic accident in one part of a freeway system impacting traffic many miles away—will also result in greater use of event processing in traffic systems and infrastructures generally.

A useful exercise is to apply the framework to evaluate the appropriateness of eventprocessing technologies in other parts of civic infrastructure such as ports, water distribution systems, and air-traffic control systems. The standard evaluation metrics such as efficiency and total cost of ownership; the key drivers of agility, information availability, and timeliness; the A-E-I-O-U features; what we expect from components of these systems; estimations of the REACTS cost/benefit measures; and the PC-cubed trends—these all tell us that event-processing technologies will play an increasing role in infrastructure.

Science

The framework tells us that EDA will play an increasing role in science experiments. You saw the importance of instrumentation for continuous measurement and response to high-value, rare events in the context of event-driven astronomy described earlier in this chapter. Science experiments, perforce, deal with events outside the virtual scientific enterprise—scientists cannot schedule times of occurrence of natural events. Expensive scientific instruments are retargeted to observe new phenomena when unexpected events are observed. Scientific experimentation has many of the AE-I-O-U features. The increasing costs of scientific instruments and experts and the decreasing costs of IT tell us that scientific experiments of the future will have increasing amounts of software. Indeed, each of the PC-cubed features drives greater use of EDA in scientific applications such as illustrated by the Large Hadron Collider.

The Large Hadron Collider, near Geneva, Switzerland, is one of the most important instruments for high-energy physics experiments. One of its goals is to detect rare events that indicate the presence of the Higgs boson particle. Detectors in the collider generate data at rates of hundreds of gigabytes per second. This data stream is filtered to produce a stream of interesting events at rates of hundreds of megabytes per second. This stream of events is valuable to physicists around the world. Truly wonderful, and probably rare, events are those that demonstrate the presence of particles that are hypothesized to exist but for which there is no measured evidence. The instrument will provide ongoing, continuing benefits during normal operations and may also provide immeasurable value when critical, but possibly rare, events occur. Seismic monitoring, observations of glaciers, and space missions also depend increasingly on EDA.

Workforce of the 21st Century

The PC-cubed trends tell us that the workforce of this century will be supported by increasing amounts of IT in general and event-processing technologies in particular. The devices that the workforce manages and maintains are getting increasingly complex. The smart electric grid, healthcare instrumentation, airplanes, cars, water treatment and distribution, and finance will become more complex in the decades ahead. Workers in the field are increasingly connected by communication devices, such as mobile phones, with experts elsewhere; for example, an electric utility worker dealing with an overheated transformer in the field can get advice from experts at headquarters. Celerity is vitally important in managing critical infrastructure such as power and water distribution. Likewise, trends in price, pervasiveness, and power of IT drive greater use of EDA for the workforce.

The workforce manages tasks on a time-driven schedule as well as an event-driven basis. A tree falling on a high-tension line is an event; this event is detected by the utility, which responds by assigning work crews to the problem. GPS and communication connectivity with workers in the field enables enterprises to have situation awareness about its workforce—it knows which crews are where and how long they’ve been in operation. The enterprise can determine the tools and workforce crews needed to handle a situation at a given location based on crew experience, resources available nearby, and work regulations. Scheduling and managing crews for airlines and railroads requires global situation awareness and dynamic management of the workforce to deal with unscheduled events.

An electric utility worker dealing with an overheated transformer on a pole several meters off the ground needs both hands and total concentration to deal with the problem. The framework tells us that EDA will support the worker doing the task; for instance, the worker will get just-in-time information about the transformer from RFID tags, detailed information about the device—its type, the time that it was installed, its repair history—will be flashed to goggles worn by the crew, and if necessary expert advice will be transmitted from the utility company’s home office or from the transformer manufacturer. The detection and diagnosis of the specific problem and the delivery of just-in-time information are implemented by EDA systems.

Healthcare

Healthcare applications are likely to remain hybrid systems with request-, time-, and event-driven components; however, applying the framework to different areas of healthcare suggests that event-driven processing technologies will play an increasing role in many domains. There is insufficient space in this chapter to apply the framework to applications such as helping aging populations to take care of themselves; use of sensors and RFID devices in hospitals and health-delivery systems; application integration of medical devices and technologies; public health and epidemiology; and telemedicine. Here we consider a few applications briefly.

Older people who want to take care of themselves at home can do so better in smart homes equipped with sensors that detect such things as whether doors are open or closed, whether gas ranges and other appliances are turned on or off, and where people are inside the home and whether they are moving. Smart shirts and other systems monitor heart rate, temperature, and other vital signs and send alerts to healthcare support systems. Smart homes generate thousands of events a day, only a small fraction of which results in alerts that demand nontrivial responses; thus these homes manage by exception. Events such as heart failure are not scheduled by the healthcare system; in terms of our framework, these events are outside the virtual enterprise. Smart homes adapt to changing behavior patterns of the elderly and changing seasons. These applications have many of the A-E-I-O-U features. Each of the PC-cubed trends demonstrates that homes will continue to become smarter over the next decades.

A similar analysis of hospitals shows that though hospital IT systems will remain hybrid systems with time-, request-, and event-driven components, the number of event-driven components will increase. An EDA application that monitors hospital assets and generates alerts illustrates management by exception in a medical setting. Blood, vaccines, and medication must be stored in stable conditions and controlled temperatures; when temperatures deviate from specified ranges, the system must respond by recording the problem and either fixing it or discarding the assets. Timedriven systems monitor assets at regular intervals, and alerts are generated when potential problems are discovered.

RFID tags on patients alert staff when patients enter restricted areas or leave hospitals without authorization. An analysis of the REACTS cost/benefit measures is instructive. For example, Code Pink alerts are issued in a hospital when an event is triggered that suggests that an infant is being abducted. False positives are generated when Code Pinks are triggered by parents or caregivers carrying an infant across RFID reader stations. Hospital caregivers may suffer from “alarm fatigue”; they can get desensitized to frequent false positives. Though EDA applications are not without cost, an analysis of all the REACTS measures coupled with PC-cubed trends for medical applications tells us that EDA systems will become commonplace in hospitals.

The Medical Device Plug-and-Play (MD PnP) interoperability program illustrates hybrid systems with significant event-driven components. The program supports acquisition of measurements from vital-signs monitors, ventilators, imaging systems, and other devices. It also supports integration of distributed medical devices to improve delivery of medication and fluids. For example, doctors may need an X-ray of a patient on an operating table. The patient’s ventilator is switched off to keep the patient’s chest still while the X-ray image is being recorded. If the ventilator is not turned back on, the patient may die. Synchronizing the ventilator with the X-ray machine obviates the need to turn off the ventilator.

Unexpected reactions may occur when pain medications are administered intravenously, and in such cases physicians must respond quickly to mitigate the situation. Connecting intravenous pumps to sensors that monitor vital signs improves the likelihood that the system will detect unexpected reactions in time. This is another example of an EDA application that helps enterprises manage by exception—most intravenous administrations of pain medication don’t result in life-threatening conditions, but EDA applications help to detect such conditions in the rare cases when they do occur.

The components of the MD PnP system are similar to components of EDA architectures described in Chapters 6 and 7. The components include a clinical rules engine, components to manage privacy and security, mechanisms to maintain audit trails and carry out forensic analysis, components that enforce security, and network managers. MD PnP systems provide significant benefits compared with current hospital practices and these benefits must be weighed against the costs of the REACTS features including the effort required from hospital staff to maintain these systems.

EDA applications and CEP are used in public health surveillance systems. Companies and nongovernmental organizations (NGOs) are exploiting widespread use of mobile phones in poorer countries to provide healthcare to underserved rural areas. Telemedicine systems are hybrid systems with time-, request-, and event-driven components, and an application of the framework suggests growing emphasis on eventdriven interactions.

Finance

Finance is one of the “sweet spots” for applications of event-processing technologies. More has been written about applications of EDA in finance and defense than in most of the other business domains. There are many areas of finance where the use of eventprocessing technologies provides a competitive advantage; some of them require millisecond responses and some require complex analyses in seconds or minutes. Many applications in finance have most of the A-E-I-O-U features that favor event processing. Financial applications must be agile to deal with rapidly changing global conditions; they must detect and respond to exceptional conditions; they are required to respond instantly; they instrument, monitor, and record a great deal of data to build accurate models; they monitor activities outside the enterprise; and they must respond to unanticipated situations.

Our expectations of many financial applications match our expectations of EDA applications: for instance, users expect financial applications to monitor markets and respond when conditions indicate significant opportunities or threats. Analyses of cost/benefit measures show significant benefits from using event-processing applications in finance, particularly in trading capital markets, but also in credit card processing, retail banking, and CRM applications such as cross-selling and up-selling. Many interactions in finance are not required to be transactional; in these applications businesses make more profit by keeping up with current conditions even if they drop a few events. EDA and CEP are used in many aspects of trading, including cross-trading, reducing errors such as fat-finger trades, algorithmic trading, order routing, market surveillance, and fraud detection.

Applying the Framework to Other Business Domains

The business domains analyzed in this chapter certainly do not include all the domains for which event processing is suitable. Next, we discuss a few more domains but treat them very briefly. Here too, our point is not that the list is valuable in itself but that you can use the framework to identify business domains where EDA adds value. EDA plays a role in the central concerns of people—water, food, energy, health, housing, work, civil infrastructure, and entertainment.

Entertainment and leisure —Online games process events triggered by actions that cannot be scheduled. Timeliness is critical in interactive games. Sensors such as haptic gloves that simulate tactile sensations of objects in gaming environments generate events at high volumes. The framework tells us that eventprocessing technologies will be used increasingly in online interactive games. RFID devices embedded in plastic bands are used in theme parks to keep track of customers’ movements enabling them to be participants in games that span large areas of the park. The devices also help ensure that underage children can be located if they do get separated from parents.

Water management —Sensors that monitor algae and other contaminants in water systems and alert water resources officials have been deployed in many countries. These sensors are also used in power plants and factories to monitor water temperature and aquatic life, such as schools of fish, and alert systems to respond appropriately if water temperatures are too high or aquatic life is approaching a power plant intake pipe. The growing shortages of clean water around the world and the PC-cubed trends tell us that EDA systems will be used increasingly in water management.

Energy —Events on oil rigs, wind farms, and solar energy farms cannot be totally scheduled. Demand-response of the smart grid, where electrical appliances are turned off automatically when the grid gets to its capacity, is eventdriven. EDA will become increasingly important in energy systems because these systems have to respond to events over which they have little control.

Summary

This chapter proposed a framework for determining whether a hybrid system with event-processing components is the best choice for a business domain. The framework is based on the A-E-I-O-U collection of features that favor event processing, the expectations (or specifications of contracts) of what components of applications do, a comparison of the REACTS cost/benefit measures, and an analysis of the PC-cubed trends. We used this framework to determine the appropriateness of event processing for a wide variety of business domains. Chapters 6 and 7 describe the architectures of event-processing systems, and Chapter 8 describes best practices in developing these applications.