I was struck by Jim Sinur’s latest post about how far “customer control” in B2C relationships has yet to run. Jim talks about how a bank decided to change its policy on overdrafts from:

• accepting payment events on overdrawn accounts, hence increasing charges

to:

• refusing payment events that would make an account overdrawn

This struck me as odd. Surely, if banks have controls like this (and they do), then they can have account settings to allow either of these options, to suit either the individual (or the bank!).

Better still, they could allow the adjustment of event controls to suit the individual and their needs. This is what personalisation is about. I should be able to specify whether the bank lets me go overdrawn for payment events based on payee, timing, and so forth… The bank might want to monitor my income spending profile and make suggestions (or specify defaults) to account settings and behaviors. For example if it detects my income changes then it might suggest, or set defaults to, rules / service levels that have suited similar customers.

Compare and contrast to current bank accounts, where occasional (but seemingly regular) marketing initiatives “invent” new banking “packages” providing certain services and entitlements (such as low cost insurance, discounted overdraft facility, credit balance interest rates etc).

Bank IT departments might complain however that their mainframe batch operations cannot possible handle individual business rules for each user. To do that they might need to move to… event-by-event processing, using something that can join customer parameters with customer transaction events… like an event-driven rule engine, perhaps? Possibly some banks are already moving in this “event-driven process” direction…

Over the next few weeks James Odell, known for his work on OO, UML and agents, will be offering some thoughts on agent technologies on this CEP Blog. Over to Jim…

The notion of event processing agents (EPAs) is quickly becoming a topic that more and more organizations are considering. We’ve been building systems that employ event processing without agents for quite some time. So, why agents and why now?

One of the primary reasons is that we are no longer in the era of mainframe computing, when both companies and applications were typically command-and-control oriented and organized in vertical silos. With the combination of the Internet, fiber optics, and PCs, the business and technology playing field has been flattened. No longer primarily top down, it has changed to more side by side-as individuals, small groups, and organizations interact around the world. In other words, the events around us are based on complex web of activity that is less command and control and more horizontal connecting, collaborating, and competing.

When the events among requesters and providers are few and change is not an issue, agents are not needed and conventional IT techniques can be employed. However, when the links require complex, dynamic binding and are subject to rapid change, agent-based approaches should be considered. Prior to the demand for global collaboration, we developed a centralized controller to ensure that all interactions would be appropriately managed. Now, this is no longer possible. The world is too big and a central bottleneck would paralyze the effort. As a result, the access techniques now require a more horizontal style of interaction-rather than one that is centrally administered.

Agent technology is a primary enabler to support this new direction. In fact, without agent technology, our current technology will not scale to support the ever-increasing global interaction. More importantly, it will enable us to create and support a whole class of IT applications and approaches that we previously could not have developed-this especially includes complex event processing.

In the next installment, I will address the question: “What is the relationship between agents and events?”

There was an interesting discussion on LinkedIn recently about Expert Systems versus Business Rules (and, my contribution, versus CEP). This was posted on the BPTrends discussion board by business rules guru Ron Ross - probably not coincidentally as not only are business rules and decisions related to business processes, of course, but also one of the better business books on Expert Systems in the 1980s was by one Paul Harmon (presumably the one and same Paul Harmon who runs BPTrends… ).

Expert systems were in-vogue in the 1980’s as decision support systems. The term was most popular in the US, as I recall, whereas the Europeans preferred the more defensible term “knowledge based systems”. Nonetheless, expert systems were usually given a set of criteria, not least of which was the first:

• expert levels of performance (comparable to a human expert)
• ability to explain its reasoning
• ability to learn new knowledge.

Technologically, these tended to use features like CBR , or inference rule engines that were backward-chaining (goal-driven) -  they tried to prove relevant hypotheses through questions and answers. Usually they were connected only to a console to support interactive “conversations” with end-users.

Such decision-support systems were ideal for technical support call centers, where the operators interacted with the expert system on behalf of callers. This also had the side-effect of training the operators. Indeed, one call center (if I recall correctly) found that after some months use, all its expert system operators were qualifiable as “experts” in the specialist domain they were dealing with!

Now fast forward 2+ decades, and we find ourselves dealing with vast amounts of information and events, automating and optimising business systems to save costs and improve performance. Here we see parallels with between expert systems and CEP implementations:

• best available expert knowledge encoded from the available Subject Matter Experts
• take expert event-driven decisions (and, if needed, log the rules used for monitoring offline or in a dashboard)
• use rules to determine whether goal states are achieved…

This is a long way from the interactive expert systems of old, but nonetheless shows similarities in both use cases (e.g. providing expert decision-making) and technologies (e.g. TIBCO BusinessEvents uses at its core an inference rule engine of the type used in many such expert systems).

I don’t advocate resurrecting the term “expert system”, even though I see an ex-colleague sports the  job title of “Director of Expert Systems” at a well-known media company! But “expert performance” - obtaining results equivalent or better to what a human expert would achieve - is still something to strive for.

A recent question came up regarding the difference between “events” and “data”. After all, to a DBA, an “event” is just another data record but with a timestamp! Of course, that is the “static” view of an event - useful only for archiving and “post (-event) processing” activities like data mining, BI and analytics.

However, a more technical answer is that data is derived from events. Customer data? Derived from customer registrations and associated checks - all events. Amount owed? Derived from purchase events. And so forth. So a better answer for the DBA is that “data” is just “information collected from, and associated with, prior events“.

In Complex Event Processing, of course, we are processing this “event data” as it occurs (within the limitations of our system latency, of course!). Typically this event data is correlated with previous events which can be either “relatively recent” (and considered as stored events or event objects) or “historic” (and considered as traditional data), although these are necessarily imprecise concepts. Access to historic data is typically carried out in CEP tools through good-old-database-services: calling the operational data store associated with legacy systems, for example. Another approach is to “event-ise” the legacy applications, extracting new events from logs and data sources as they occur.

TIBCO examples of the above approaches to data access in event processing are TIBCO BusinessEvents’ database interface (what we call DBConcepts) and TIBCO Adapters (e.g. for ERP and HR systems).

Notes:

The EPTS glossary does not define “data” but does mention that event objects contain data…

Thanks to TIBCO’s Patrick Sapinski for some news on a CEP-driven Twitter application (albeit not public yet) that used location awareness principles to “tweet” people depending on where they were (e.g. passing a certain location). The Twitter side of the story was apparently the easy part. Patrick writes:

“We did not do any Java coding to accomplish this. We just used the TIBCO BusinessWorks HTTP activity to send tweets to Twitter. It was pretty easy once I configured the messages, URL, etc.”

Of course, for corporate applications / private tweets there are also services like Tibbr, which I signed up for this week… meanwhile I’m happy sticking with iGoogle to monitor “the real thing” via RSS feeds!