Time for the next generation of knowledge automation

In preparing for my workshop at the Business Rules Forum in Las Vegas on November 5th, I have focused on the following needs in reasoning about processes, about events, and about or over time:

1. Reasoning at a point within a [business] process
2. Reasoning about events that occur over time.
3. Reasoning about a [business] process (as in deciding what comes next)
4. Reasoning about and across different states (as in planning)

Enterprise decision management (EDM) addresses the first.  Complex event processing (CEP) is concerned with the second.  In theory, EDM could address the third but it does not in practice.  This third item includes  the issue of governing and defining workflow or event-driven business processes rather than point decisions within such business processes. 

Business applications of rules have not advanced to include the fourth item.  That is to say, business has yet to significantly leverage reasoning or problem solving techniques that are common in artificial intelligence.  For example, artificially intelligent question and answer systems, which are being developed for  the semantic web,  can do more than retrieve data – they perform inference.  Commercial database and business intelligence queries are typically much less intelligent, which presents a number of opportunities that I don’t want to go into here but would happy to discuss with interested parties.  The point here is that business does not use reasoning much at all, let alone to search across the potential ramifications of alternative decisions or courses of action before making or taking one.  Think of playing chess or a soccer-playing robot planning how to advance the ball on goal.  Why shouldn’t business strategies or tactical business decisions benefit from a little simulated look-ahead along with a lot of inference and evaluation?

Even though I have recently become more interested in the fourth of these areas, I expect the audience at the business rules forum to be most interested in the first two points above.  There will also be some who have enough experience with complex business processes, which are common in larger enterprises.  These folks will be interested in the third item.  Only the most advanced applications, such as in biochemical process planning, will be interested in the fourth.  I don’t expect many of them to attend!

The notion of enterprise decision management (EDM) is focused on point decision making within a business process.  For enterprises that are concerned with governing business processes, a model of the process itself must be available to the business rules that govern its operation.  I’ve written elsewhere about the need for an ontology of events and processes in order to effectively integrate business process management (BPM) with business rules.  Here, and in the workshop, I intend to get a little more specific about the requirements, what is lacking in current standards and offerings, and what we’re trying to do about it.

As I’ve written previously, the distinction between business process management (BPM) and CEP is not well principled but arises from somewhat arbitrary, historically distinct emphases on technology and market segmentation.  Any modern business process system must handle events and discussing events processing without considering processes is a limiting perspective.

Most people would intuitively agree that events trigger business processes.  For example, a business receiving a payment or a letter from a customer or vendor is an event that triggers the process of crediting and depositing that payment or considering and responding to that letter  Hopefully, we are moving beyond academic arguments about the distinction.  (I am ignoring here the algorithmic applications of streaming event processing as in trading in the capital markets.)

So, in current BPM, which should include CEP capabilities, we want decision management that is less ignorant about where it is in a business process and that is aware of events that trigger processing.  That is, we want policies that talk about the state of a business process and the occurrence of events.  The surprising thing is that current business rules management systems (BRMS) and related standards are of no help.  Tools from the leading business rule management system (BRMS) vendors, including Oracle and IBM / Ilog, have no intrinsic understanding of processes, events, or time.  And, outside their integrated BRMS, tools from BPM vendors don’t let us “talk” about anything.  They help us structure flows and code, but they rely on integrated BRMS to manage rules.  The rules include the policies, in which the business “talks”.  The BRMS is where English sentences (or something that increasing looks like English) are managed as the enterprise repository of policy. 

Note that there is nothing special about English.  It’s just easier to read than “natural language”.  Another limitation of current policy management systems is their lack of language independence, which requires automatic translation, which is much simpler if the sentences are unambiguously interpreted with logical rigor, but I digress from the point of this missive…

Some examples will help here.  Suppose we check the credit of an applicant at various points within the collection of processes that constitute how our enterprise conducts business.  We might have policies that are concerned with how we consider or act based on credit information in originating a loan (or policy) versus in renewing  or re-pricing one.  In effect, our policies want to talk not just about evaluating credit or pricing risk, but to do so in the context of a larger business process.  To be more specific, business policies that sound like, “if evaluating credit in the course of pricing a renewal…” or “if evaluating credit while considering a new policy…” are quite natural.  These statements define or govern the business process.  They also talk about where the decision is being made within a business process.  

• BRMS need to understand the context of the business process in order to make context-sensitive decisions.
• BPM needs to tell the BRMS what it is going on from the top-down for the BRMS to understand the context of a decision.

So, we need the BRMS to be told things like:

• I am considering a new applicant.
• I am considering the renewal of a contract.

In these statements, the pronoun “I” is the overall enterprise system contemplating its own actions.  If you find that awkward, just substitute “while”  to obtain what you might “say” in a business policy.  Ideally, the language your policy management system would not be overly stilted but would understand any of:

• while considering…
• during consideration of …
• if considering…
• if an … is being considered for…

and so on.  Otherwise, users will find authoring such statements cumbersome.  Reading and understanding English, even if it is a bit stilted, is easy for people.  We’re built to communicate, after all.

Now consider what you would want to say if you were writing policies that involved events.  In this case, the event has already occurred, such as “we received a letter from a customer…”.  You do not want to say, “if I am receiving a letter from a customer…” (which could only be true for an instant that passes quickly unless it was stated as “… I will be receiving…”).  But if we can only refer to events in past tense, how do we talk about a current event that needs to be handled versus another event that we have already handled?

Many business to consumer (B2C) applications, such as pharmacy benefits have this problem, for example.  To a pharmacy benefit manager (PBM), like Medco or Express Scripts, the swiping of an insurance card at a retail pharmacy is an event to be processed.  Any individual beneficiary has a history of such requests.  We can try to model the current one as a request and the prior ones as transactions, but this becomes awkward for less formal or technical people who want to talk about how many requests someone has submitted over a period of time, for example.  The truth is that there is a history of requests per beneficiary and technical limitations should not obscure this fact.  We should be able to distinguish the current request from prior requests, as in the following:

• a request that has not been processed is current or pending
• if processing a request…
• if a request for … is being considered…

Note that “request” is a deverbal noun, which is to say that the root form is the verb (in this case “to request”).  A request is a reference to an act of requesting that may be in any tense.  The sentences above reflect this in the use of an additional verb that carries the tense.  Of course, this is all completely natural since every sentence has a verb.

The most dangerous expression might be:

• if … requests …

and yet this is the form that almost all BRMS would handle today!  This is dangerous because it is too ambiguous about when the request occurred.  It would be better to say:

• when … requests …

provided that the system understands that, unlike “if”, “when” involves time, but even “when” is less than ideal since an event has always occurred in the past by the time it is processed.  On the other hand, we might define when a request occurs as in:

• a request occurs from the time it is received until it receives a final response.

This assumes that “when” combined with a verb in present perfect tense means during the period of time in which the process referenced by the verb continues.  And this is an important point:

• An event can be an occurrence of a process.
• An event may have a duration.
• “When” may refer to an interval of time.

Events are not necessarily processes, but may refer to instantaneous points in time, such as in the following:

• When a request is received…
• When the processing of a request begins…

but these uses of “when” refer to a point in time before any action can be taken in response to the event, therefore the sentences should only conclude with statements of implied, necessary, or modal logic and should not include any statement of action. Of course, a competent BPM/CEP/BRMS would understand all this and advise the author of a policy that suggests taking action in the past.

As we proceed through these examples our intuition should be building the understanding of the first three points made above.  Processes and events and reasoning about or over time are completely intertwined in nature and separating them between BPM and CEP and BRMS systems is completely artificial and hopelessly limiting.

So what is the solution?  I suggest it is a knowledge management  system that understands the following:

• 1. Policies that use tense.
• 2. Policies that refer to events using deverbal nouns.
• 3. Policies that refer to occurrences of processes as events.
• 4. Policies that refer to potential action using future tense, possibly by way of modals.
• 5. Policies that refer to occurrences of processes using verbs such as “begin”, “end”, “start”, etc.
• 6. Policies that refer to occurrences of process using words like “during”, “while” and “when”
• 7. Policies that refer to events using prepositions like “by”, “before”, “after”, and “when”

The natural language technology to parse such sentences is widely available using many approaches.  I am happy to discuss that with interested parties.  The second step that needs to be addressed is transforming the logical interpretation of such sentences derived from the natural language system into the underlying execution architecture, which includes a process engine and a rules engine that must be appropriately integrated.  That integration involves the informing of the BRMS about the state of the business process and the actions that may be taken which may be expressed as processes in the BPMS.  I’ve written elsewhere about this in more detail and am also happy to discuss it in more detail with BPM or CEP practitioners, product managers and architects.

Understanding events and occurrences of processes as events adds a great deal of power to policy management.  It allows statements of policy to reference and consider the context of business processes.  It allows statements of policy to reference and consider how to handle events in the context of business processes.  And, if it is done with adequate natural language understanding, it accomplishes this integration of BPM and CEP within a single policy management system.

Although I had hoped to cover the fourth point made first above here, I now prefer to conclude with a brief discussion about reasoning over time.  I will strive to cover reasoning about potential states of a process another day.  It is interesting but rigorous material that requires (in my opinion) architectural support that is lacking from current rules engines, whether production rule or logically based, even if the situational or event calculi are good formalisms.

Reasoning over time is pervasive in CEP.  In the pharmacy benefits management domain, for example, coverage is commonly limited based on the history of transactions.  For example, a policy might limit the amount of refills over a period of time.  This involves aggregation over a number of events, each of which is the result of handling a prior request.

Very few knowledge or policy management systems understand that transactions are processes, occurrences of which can be viewed as events.  For example, is “order” an noun or a verb in your enterprise applications?  Our technology has biased us to thinking about objects, which drives our modeling towards nouns and away from verbs.  Our technology biases us against modeling events and processes well!  And it shows up, insidiously sapping productivity and accessibility.

The lack of ontology of process and event in current BRMS not only precludes the kind of integrated BPM and CEP I am discussing here, it also limits the ability of current BRMS to automate policies that consider what has happened in making decisions in the present.  For example, a statement like:

• if a medicine has a maximum therapeutic dosage over a period that is less than the total dosage of that medicine requested by a member over the same period then…

is beyond the capabilities of current offerings.  Authority understood some grammar about time but did not understand that events, such as a request, occurred in any deep sense.  So it could automate a sentence like:

• if the total dosage of a medicine requested by a member on a date within the last 90 days exceeds the maximum quarterly therapeutic quarterly dosage for the medicine then…

but understanding why it understands one sentence and not the other is too much for many authors to tolerate, let  alone understand.  The essential reason is that we sold the company before extending Authority’s ontology to include events and revising its parser to understand that both verbs and their deverbal nouns referred to events (including occurences of processes).

The bottom line here is that a quantum leap in natural language processing of business rules is needed.  Fortunately, this is not a quantum leap for natural language processing itself.  It is well-established that sentences are parsed into representations of events in which noun phrases play semantic roles, such as the following:

• agent or counteragent
• donor or beneficiary
• patient or “experiencer”
• causer
• instrument
• locative or time
• source or destination

where quite a few prepositions relate to more refined aspects of time and location, such as at, on, during, by, before, after, in and so on.   The critical thing for processes and events is that they occur in time.

Realizing this quantum leap in policy management and knowledge automation is really pretty simple.  Take an approach such as Authority and extend its core, upper ontology with the semantic roles and the concepts of events and processes.  Then extend its relation-centric parsing with even-centric parsing (both are needed).  A few more steps, notably handling metonymy, and the next generation of knowledge management and automation that provides the integrated understanding of time, events, and processes discussed here becomes a reality.

That’s what we’re patiently working towards.  And we’re doing it in as engine-independent a manner as practical so that we can leverage standards like RIF and SBVR.  It’s all about the knowledge.

Finally, we are looking for collaborators who would like to learn more or help, and, perhaps, get involved in leveraging the solution or its underlying technology.