Business-process automation has typically meant defining a well-established business process and automating each step so that human intervention is no longer needed to see that processes are completed.
But linear business-process automation isn't enough. What's needed is the ability to monitor the stream of small events that make up a set of business processes, including the events that precede a business transaction and those that come after it. Such an approach is known as "complex-event processing," says Stanford University professor David Luckham, author of The Power Of Events: An Introduction To Complex Event Processing In Distributed Enterprise Systems (Addison Wesley; 2002).
For example, trading goods across national boundaries is a business process that consists of a whole series of events that end with a currency-conversion transaction. In complex-event processing, the focus is on the many steps that make up a process, both those immediately connected to it and those one or more steps removed from it. By monitoring such events and aggregating a record of them, patterns emerge that help define normal and abnormal processes and improve the ability to monitor business activities. Such monitoring would be useful in guaranteeing compliance with new regulations, such as the Sarbanes-Oxley Act, and preventing fraud.
A complex-event-processing system, for example, would have caught Nick Leeson, the Barings Bank futures trader who in 1995 racked up $1.3 billion in losses before being discovered. At the time, Leeson was both trading manager and manager of back-office systems at Barings' Singapore office. Holding both positions made it possible for him to illegally hide his losing trades in an inconspicuous error account. But the simplest analysis of his activities--by human auditors or automated systems--would have quickly revealed how Leeson's trading was deviating from established processes and raised a red flag, Luckham says.
"One of the most basic elements of complex-event processing is being able to spot patterns" and determine whether they fall inside or outside expected or accepted norms, he says.
If business-process analysts could see all the processes running in their operational systems, they would realize that such processes, especially ones that respond to changing markets, are "composed of lots of lower-level events," which call for automated systems that can recognize, aggregate, and correlate related events, Luckham says.
Business-process-automation systems can do part of the job by automating defined steps. Business-rules engines enforce norms over a business process. And high-performance databases can keep relevant data in a system's main memory for rapid checking and analysis. Event-stream processing, such as a system monitoring the flow of stock-ticker information, is a specific form of complex-event processing.
But few IT systems today really perform complex-event processing across multiple systems. Nevertheless, some companies are using rules engines, databases, or customized systems to take the first steps toward complex-event processing.
Complex-process monitoring helps American Electric stop overpayments, Sullivan says.
Since January, American Electric has been using what Sullivan calls a silent auditor from Oversight Systems Inc. The Oversight Controls Library links American Electric's accounts-payable system to Oversight's audit tests. A second product, the Secure Audit Lockbox, logs all activities on incoming invoice transactions, captures anomalies and alerts, and stores them in an encrypted database.
Instead of viewing invoice payment as a single, rigid business process, American Electric treats invoice processing as a set of complex interactions that may require double-checking with systems outside those doing the processing. Two invoices for the same amount may, in fact, be one payment owed to a vendor that has submitted two invoices. By checking a master-address database and an archive of the previous locations for sending payments, Oversight can determine whether the two payments are legitimate or if one should be canceled.
Such a system also helps prevent fraud by an employee who could circumvent safeguards in American Electric's accounting system. "Did someone enter a vendor, then enter the name again under a different address?" Sullivan asks. Finding a double entry would trigger a review of who was involved by analyzing the data in the Secure Audit Lockbox.
"All that information is very reportable, very auditable, rather than searching for it through a set of separate system reports," Sullivan says.
In one case, the system caught a $75,000 duplicate payment. Reconciling such discrepancies used to be the equivalent of a full-time staff person at American Electric. With Oversight performing checks on the systems, it's now a half-time job, Sullivan says. Such precautions also reduce the costs of turning suspected duplicate payments over to an overpayment-recovery firm. Sullivan expects those recovery expenses will decline from $300,000 a year in the past to between $100,000 and $150,000 this year.
The Oversight system also provides greater assurance of meeting Sarbanes-Oxley and other regulations, Sullivan says. In a large IT organization, many staff members might understand the rules of database and accounting systems, and one could manipulate them for personal gain. "With Oversight, I have a system that detects what's going on independent of the accounting or database system. I'm in a much better position if someone in my technology group is manipulating the data," he says.
Complex-event processing also can be conducted using business-process-oriented middleware such as IBM's WebSphere Business Integration Server or Tibco Software Inc.'s BusinessEvents.
To manage its annuity accounts, Guardian Life Insurance Co. of America uses the Transcend system (it was originally sold by TriMark Technologies Inc., which was acquired by PeopleSoft in 1999, and later discontinued). Transcend administers individual annuities by drawing on multiple databases and back-end systems. It performs dozens of checks on new accounts, such as when an annuity is sold by a broker, and connects to a customer's personal-account interface known as My Account Manager.
Transcend uses WebSphere, including Integration Server, to respond to individual customer requests, conduct fund transfers, and allow customers to set triggers that automatically trade an equity when the price is right, says Shelley McIntyre, VP of business technology. Transcend includes an event engine that can immediately apply new rules and execute transactions when clients juggle their portfolios and set new investment goals.
When a stock is approaching a target price, Transcend doesn't just prepare to execute the transaction. It checks to make sure the money is available in the client's account and sends an alert to the customer that a transaction is about to happen. It lets the customer say, "Oops, I changed my mind," says Rob McIsaac, senior business-systems officer for equity and Park Avenue securities at Guardian.
Complex-event processing also is needed in the financial-services industry when customers want to act on a target stock price with the least possible delay. With information flowing into it, a standard relational database can detect when the price of a given stock has reached a prescribed level. But it's difficult for it to detect the instant when the same stock has traded at the same price three times in the last hour, triggering a major trade by an investor, says Michael Stonebraker, a key figure in the development of relational database technology and now chief technology officer of startup StreamBase Systems Inc.
The StreamBase processing engine, which analyzes streams of data in real time, adds a time window to a stream of data and analyzes aggregate data over a given period. The result is complex-event processing closer to real time than data-warehouse systems and other archival systems can perform, Stonebraker says.
Such stream-processing engines will find greater use watching for patterns and key information in streams of radio-frequency identification data and other forms of sensor feedback in supply chains, he says. "We see a sea change coming in microsensor data. Everything will be sensor-tagged, producing a fire-hose [stream] of data."
Stanford's Luckham says stream-processing engines are one means of complex-event processing, but "events created in a distributed enterprise don't come in a nice, orderly stream." Other means of complex-event processing will have to appear, he says. Luckham himself invented a complex-event processing language, Rapide, but it was never commercialized and hasn't been updated for five years. Another declarative, high-level language will have to emerge to handle complex business processes, he says. A business process expressed in such a language would be directly translatable into executable software code.
Business Process Execution Language, backed by IBM and Microsoft, has been adopted as a standard by the Organization for the Advancement of Structured Information Systems. But BPEL deals almost exclusively with turning business processes into Web services, says Jeanne Baker, president of the Business Process Management Initiative, a user and vendor consortium that's merging with the Object Management Group. With its focus on Web services, BPEL has no means of expressing business logic or allowing human actions in a business process, which makes it "challenged" for complex-event processing, Baker says.
"A true execution language would be a first step," she says. Such a language might lead to business-process-modeling tools with rigorous diagrams and precise notations, like software modeling's Unified Modeling Language.
For complex-event processing to become a reality, "we need a bridge between the business-process analyst and the IT staff," to tie it into the software infrastructure, she says.
Business-process automation specialists such as Luckham and Baker say IT vendors are moving the state of the art of complex-event processing technology forward. "But are we moving rapidly enough to keep up with demand?" Baker asks. "No, we're not."