Event Driven Operations
Abstract
An agile enterprise must respond the events as they happen. This chapter addresses events that are relevant to routine business operations and events that threaten or signal operational failures. Action on these events must be supported by the IT infrastructure, particularly a notification service. Chapter 9 addresses events and trends that signal a need for change.
Keywords
Business events; Notification broker; Failure events; BPMN event; CMMN event; CMMN listener; Database trigger; Sensor events
VDM (value delivery management), CBA (capability-based architecture), and BCM (business collaboration management) can make an enterprise more flexible, accountable, and efficient, but they do not necessarily make it agile. The agile enterprise must sense what is happening and respond, and the responses must be timely and effective.
Business process automation helps streamline the movement of work through our business systems, but things happen that call for deviations from the normal process, and side effects of some processes require action by other processes. In an agile enterprise, these events must be communicated and initiate action.
For an agile enterprise, events and interactions are an important part of how an enterprise works. We do not just make information available to people who should take action, we send them a notice to pay attention. There are two fundamental levels of response to be considered. Some events occur that affect the normal course of business where we can identify who is responsible and can act more quickly or in a more coordinated way when it is time for them to act. Other events signal unfortunate or unexpected circumstances that disrupt the continued operation of the business.
In this chapter, we will first consider (1) how events drive the routine operation of the business and then (2) how events improve the response to operational failures that interrupt normal operation of the business. In Chapter 9, we will consider how changing circumstances drive changes to the enterprise.
Routine Events
Collaborations (including business processes and case management) respond to events, either events that occur within the collaboration or events from external sources. The most trivial event is the completion of an activity. Other events within a collaboration indicate a deviation from the normal flow of activity. In addition, in many cases, an action occurs in one domain, but a response, a consequential action, is required by another person or in another domain. Events then are an important part of timely and effective collaboration, coordination, and awareness.
Some events have predefined recipients. Other events are communicated in response to an expressed interest. These may include notice of changes in status or measurements for monitoring or action when changes require special attention.
An event that is communicated in response to an expression of interest is delivered as an event notice message to a notification broker to be forwarded to interested recipients (see the discussion of notification broker later in this chapter). Event notices may be requested by many recipients from many sources of events. The linkage to event sources and recipients is an ongoing activity. Sources change and new sources will emerge as the ecosystem changes, and interest in certain events will come and go based on various circumstances.
We will consider routine events occur in the following contexts:
• Case management
• Business network
• Coordination of collaborations
• Data updates
• Milestones
• Time expired
• Sensor events
• Performance management
Business Process
An event notice received by a business process may cause a business process to start or an active business process to alter its flow. A business process may issue an event to signal completion of an activity, to initiate action at a particular time, when an action or request is not completed in an allowed time, or to signal the occurrence of an exception (typically a problem that requires human intervention). Event notices received and issued are explicitly represented in BPMN (business process model and notation) (see Chapter 4). An event notice representing the occurrence of an exception may go outside the scope of the formal business process, for example, an operational failure event, discussed later.
Case Management
Case management in CMMN (case management model and notation) is driven entirely by events. Events drive responses to a changing situation, and they drive the flow of control as well as interactions between participants. Many case management events are equivalent to events in business processes. Events that drive a case are (1) an action that starts a case, (2) the completion of an activity or stage, (3) the occurrence of a point in time or expiration of a time delay, (4) a relevant change in the state of the data base representing the state of the case, or (5) an action by a participant. Any external event notice directed to the case is recognized as an update to the case database. Except for dependencies between activities, or time-based events, events of interest are recognized when there is a relevant database update from either an internal or an external source. The database represents the state of the world as the case sees it.
A case may generate an event notice to initiate action by a participant or another case or business process, or to report progress. From changes in the database, a case may generate other event notices that are of interest to others but are not necessarily of interest to the case.
Business Network
A business network interaction is similar to a business process except that the flow of control is through the exchange of messages. Message exchanges may be specified with choreography in BPMN. These interactions are fully defined, and any breakdown in the exchange will result in termination of the collaboration, possibly with event notices for problem resolution or performance reporting. The event notices, generally, are in the form of messages exchanged as specified by the choreography. A party expecting a response will use a time delay event to initiate an alternative action if there is no response. Recurring termination of a collaboration may be recognized as an operational failure (see later).
Coordination of Collaborations
Events may be exchanged between relatively independent internal collaborations, much like the exchanges between business networks. However, because the participating collaborations are within the enterprise, the interaction can be described and managed as a collaboration between the collaborations.
Data Updates
Data update events, or “triggers,” are issued when notice of a particular change of state has been requested. They are explicitly anticipated and drive some action as determined by the requestor. The commonly occurring data update notice will be to inform another service unit that a state of interest has occurred or that there is a change to master data that the receiving service unit has copied and is keeping up-to-date.
Milestones
A milestone event notice is a declaration of the occurrence of significant progress in a long-running process, project or initiative. A milestone only exists if its occurrence is anticipated and is of interest for a person or a process. Most often it will be recognized in a database update.
Time Expired
An event notice indicating that a particular time has occurred or a period of time duration has expired as the result of initiation of a timer event. Consequently, the event notice is expected unless it is no longer a concern and is canceled. In some cases, it may trigger action as notice of an operational failure. Most timer events are specified within a BPMN or CMMN process.
Sensor Events
Sensors may detect many forms of event from tripping a limit switch, to recognition that a process variable is out of range, to the human selection of a button or mouse click in a kiosk, or to the image perceived by a television camera. The event notice is anticipated or there would be no sensor. That does not necessarily mean that there is currently an action pending for an event notice from every sensor. Some sensors may only be of interest under certain circumstances, so the messages must be filtered.
Performance Management
There are many measurements of performance that are captured by the measurements service unit (see Chapter 6). Monitoring will typically focus on variances that require corrective action. These are event notices for responsible managers, but sometimes they are part of a bigger picture that is of ad hoc concern to business leaders or analysts considering more extensive improvements. These may involve ad hoc subscriptions to event notices.
It is preferable that the events being measured align with the completion of activities in the current VDM model so that they can be interpreted in that context. Eventually, key events should be presented in a VDM model context to interested users in their personal dashboards.
Operational Failure Events
Operational failure events represent circumstances that prevent normal operation of the business. They may range from the failure of a communication link to a factory fire. The desired result is to prevent an interruption or quickly restore normal operation of the business. The event notices may identify an interruption of normal operations or indicate an increased risk of an interruption. Recognition of the need for such event notices is closely related to risk mitigation—early intervention before a potentially costly interruption.
The current business VDM modeling provides insights on the propagation of effect of these failures for a full understanding of the consequences and possibly the rate of increase in cost when it takes time to return to normal operation.
Case management is particularly appropriate to coordinate a response to a operational failure because each situation will be somewhat different and require different actions by different people. Case management can support the ad hoc planning and immediate and coordinated response as the case evolves.
The following sections characterize operational failure circumstances where notices are needed for prompt action. Each of these events would trigger initiation of a different crisis response case management collaboration. Related events are important for coordination of the response. Notices of these events and the actions being taken must also be directed to business leaders and others whose action or awareness is needed.
Community Infrastructure Failure
Transportation facilities, telephone, heat, light, water, and natural gas may be essential to operation of the business. Event notices should raise awareness of the outage to determine the potential duration and take appropriate action.
Personnel Absences
If the start of a production process, or the ability to maintain a level of service requires a certain level of staffing, it is important to know if the personnel are available. An event notice might be issued if people have not checked in at the designated starting time, and possibly a notice when the required staffing level is achieved.
Machine Failure
A machine failure or repair request may be critical to business operation depending on the availability of alternative machines. Critical machines might be polled to determine if they are available and active with an event notice issued if there is no response. For a less critical machine, an event notice might be issued, but no action may be required unless multiple machines become unavailable.
Product Defect Threshold
Some frequency of product defects may be expected, but at some level, it is appropriate to stop, find the problem, and fix it. An event notice is appropriate when that threshold is reached. In some cases, this may have a significant impact on the ability to continue business as usual. It is likely that event notices will be required for individual defects so that frequency can be assessed before more significant action becomes necessary.
Supply Failure
For operations that depend on consumable resources, an event notice is appropriate when the inventory approaches depletion (maybe X hours on-hand), and again if depletion occurs. For reusable resources, an event notice should be issued when there is a risk that the supply is insufficient, and another event if there is an unmet need.
Damaged Facility
An event notice should be issued if a facility is damaged such that continued business operation is at risk or is discontinued. Such events may require reporting by people on-site, but other operations sensors should also signal a work stoppage.
Natural Disaster
Natural disasters include storms, floods, droughts, earthquakes, fires, and volcanic eruptions. In most cases, there is information available about an increasing risk. Event notices should signal increased levels of risk to initiate assessment, tracking, and possible action to mitigate the damage. For some industries, such events may foretell an abrupt increase in demand for certain products or services.
Epidemic
The risk of spread of disease has been heightened by a shrinking world. Individuals can carry infectious diseases around the globe, overnight. Concerns about a bird flu pandemic have faded, but such risks remain. An epidemic could disable a critical number of employees. A pandemic could have a major impact not only on the ability of the enterprise to function but on the demand for products and services.
Civil Disturbance
Civil disturbance could include a strike, riot, act of terrorism, or robbery. In some cases, like natural disasters, there may be warning signs, indicating an increased risk for which there should be event notices. In other cases, there may be no warning, and an event notice is needed to trigger immediate action to mitigate the damages.
Event Management Infrastructure
Event-driven operations require an infrastructure for communication of events to the persons or activities that need to be aware of events or take action as a result. The primary facility provides notification management. In the next chapter, we focus on sensing threats and opportunities. Here, most events are involved in internal coordination and collaboration or are reported by human observers.
Notification Management
The core of an event driven infrastructure is notification management, supporting publish and subscribe messaging. This facility filters and delivers notifications of events and other relevant circumstances.
Brokered Notification
Typically, as depicted in Fig. 8.1, a notification broker receives notices from publishers and forwards the notices to subscribers who have expressed interest in certain types of events. Notices are associated with topics and have attributes to describe the nature and context of the notices. Subscribers may specify constraints on the notices they want to receive. This may take the form of a topic designation and rules that filter notices based on notice attributes.
Note that a subscriber may subscribe to multiple topics, a publisher may publish notices of interest on multiple topics, and each notice may be forwarded to multiple subscribers.
The Organization for Advancement of Structured Information Systems (OASIS) has adopted the WS-Notification (http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm, http://www.oasis-open.org/specs/index.php#wsnv1.3) family of standards. The interfaces and message formats for a notification service using a broker are defined by the OASIS WS-BrokeredNotification (http://www.oasis-open.org/specs/index.php#wsnv1.3) standard. Publishers register with the broker to identify the topics for which they publish notices. When the broker receives the first subscription for a topic, it will notify the registered publishers to begin submitting notices. If all subscriptions are withdrawn, the broker will notify the publishers so that they can stop issuing notices, thus avoiding unnecessary network traffic.
Nonbrokered Notification
As an alternative approach, under WS-BaseNotification (http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm), a subscriber can request notices directly from a publisher. Fig. 8.2 depicts a nonbrokered notification topology. A notification directory identifies sources of events. Publishers need to register with the directory, and a subscriber then uses the directory to identify sources of events of interest and subscribes directly to those sources. A subscriber can define restrictions on the events of interest through specification of a constraint that operates on the attributes of the event notice.
This removes the event notification broker as a potential bottleneck. Before the general availability of Internet technology, a broker was necessary to eliminate a multitude of point-to-point connections; now with point-to-point connectivity and standard exchange protocols, a broker no longer simplifies the network. Note that Publisher C sends notices to Subscriber L and N, directly, whereas in the brokered notification, Publisher C would send a single notice and the broker would forward notices to Subscribers L and N. Subscription requests should be recoverable so that if the publisher fails or is shut down, notices will resume when the publisher returns to operation.
This mode is good if publishers stay the same. If there is a change in publisher, or if publishers come and go, subscribers would need to subscribe for each new publisher.
The absence of a notification broker makes management of event notification totally decentralized. It may be preferable to at least use a notification broker between internal subscribers and external providers to monitor the activity and contractual compliance for purchased services. A broker also provides a central point of control for directing notices to subscribers so that publishers can be replaced when necessary without searching out all subscribers. As an alternative, the event directory could function as a broker of offers and requests, while the publishers each send event notices directly to subscribers.
Access Control
An event notice can be a source of confidential information. Consequently, subscriptions for event notices must be authorized. The authorization must be granted by the source of the desired event notice. This is further complicated by the fact that authorization may be based on specific content of the event notice, such as data about a specific patient or a customer.
If the authorization is applied to the subscription request, then there must be a mechanism to remove the subscription when the authorization is terminated. Note that authorization may be quite dynamic as where different professionals may be authorized to receive notices for a particular hospital patient at different times, potentially at every shift change. There should not be a delay between authorization and the ability of the professional to participate in providing services nor termination of access when the professional is no longer authorized.
The nonbrokered approach enables authorization to be managed by the publisher since the publisher can validate the delivery of each notice to each subscriber.
Polling Service
Some sources of events, particularly external sources, are not designed to provide notification of changes but maintain web services with current information. A polling service can function as a notification publisher that obtains notices by periodically polling various sources for current information and comparing current state to prior states to identify changes.
This service, like other publishers, can have polling turned on or off depending on the presence of subscribers. This allows the polling services to maintain the possibility of providing notices on many topics, most of which are not currently of interest or may be of only occasional, brief interest.
Moving Forward
Event processing has a significant impact on the timely and efficient operation of the business and the mitigation of failures and destructive circumstances. In the next chapter, we will consider the ability to respond to circumstances that require a change to the business in order to remain competitive and pursue threats or opportunities in a timely manner.