The importance of business analyst interfaces

Carole-Ann wrote a blog about what she considers to be the #1 pitfall in the implementation of proper Decision Management applications. Her observations are based on a vast experience of multiple implementations of such applications in multiple vertical domains.

I fully agree with Carole-Ann’s position highlighting the importance of getting the user interface for business analysts well defined and implemented, with their workflows in mind, and with special attention paid to their concerns.

I have been in a position to review multiple implementations, made with both the products I have been responsible for as well as their competitors, and, in a fairly significant number of cases, what I have reviewed has amounted to little more than direct translations of implementation concepts, disconnected from the concepts and workflows of the business analysts. Some of these implementations are a consequence that the tools used insist in presenting very low level interfaces – typically, single ‘if-then-else” rules built by point and click – or a single representation – typically, a complex table-based interface, or a tree representation. But others leverage tools that can do much more, yet they fall down to low level implementations that end up leading to significant frustrations by the business users, and, worst, a breakdown of their workflow, and their ability to actually manage the decisions, contrary to the promise of the Decision Management approach.

This is serious, and I will go as far as Carole-Ann on this – the ultimate success of the discipline hinges on getting this right.

What are the two key issues I have seen in these failed implementations?

Lack of consideration for the concepts and representations used by the business analysts themselves

Business analysts do think in terms of policies, constraints, pricing structures, etc… They do not think in terms of “if-then-else” rules, or “event-condition-action”. Business analysts need to be involved in the decision on which representation to use from the onset: they should go to the whiteboard, and, with no prompting from the actual business rules or decision management implementation specialists, specify how they see their concepts, policies and workflow. More frequently than not, they will use a combination of textual form and graphical representations, and fairly well defined workflows. The role of the implementation specialist will have to be then to select the right representations in the tools to reflect as well as possible the representations and flows used most frequently.

I really cannot understate the importance of this approach. One of the key tenants of the Decision Management approach put forward in the early days and that I still believe in after all these years is that the business analyst must be able to understand the decisions implemented, and the implementation specialist must understand what the changes to the decisions need to be. Ideally, the business analyst can implement the changes directly – but even that requires the implementation specialists and the business analysts to have a proper common ground to effectively defined and enforce the boundaries of what can be done that way.

There is one key consequence of this approach, and that is that there is no way a single representation approach will be sufficient to elicit, implement and manage decisions through their lifecycle. I know that there are whole companies out there pushing to the front their graphical or textual representation as the solution to all decision logic, but on this problem, they fail. Yes, I do not doubt that they can express all possible decision logic – but that’s not the question: the question is whether they can do it in a way that is efficient for the business analyst and that will scale through their workflow and the evolution of decisions.

Let’s take a few examples:

• I am very familiar with a tool that mostly uses decision trees as the way to express all decision logic, including all potential initial states and all potential outcomes. No surprise there – the decision trees in question grow to the thousands, and tens of thousands of nodes, becoming unusable. Patch solutions, like tree simplification algorithms, are not an answer: the issue is that the tree metaphor is not adapted for all types of decision logic. The internet is full of references to studies that demonstrate that.
  
• Another tool uses a table like metaphor as its only representation for decision logic. Again, we hit a similar scalability problem, and for different technical reasons as why the decision trees don’t scale. Tables are awfully poor at representing disjointed logic, and even worse at handling exceptions. But on the other hand, there are many, many, cases in which a single decision is in fact a multi-step decision with a number of exceptions. The implementations end up with a large number of tables that are difficult to navigate through, with close-to-empty tables representing exceptions parallel to huge tables mixing multiple steps in the decision, with tables with extreme density variability (sections with a lot of content, and then sections mostly empty where the user needs to be very good at finding the relevant information), etc…
  
• Others used exclusively semi-formal languages. These present the advantage that they are closer to the way the policies would be documented in textual form, but lose the significant synthesizing power of metaphors. Explaining a scorecard in text is incredibly cumbersome compared to what can be done in a real scorecard representation.
  

Lack of consideration to the availability of context in the business analysts interfaces

This is a constant concern of mine, and something not that many business interfaces do provide: availability of context directly where the business analyst is working. Carole-Ann refers to a huge aspect of this when she focuses on the navigation issues in the user interfaces.

What the business analyst is doing when she/he is manipulating a particular representation is contextual – and to do it right, she/he needs access, directly there, and in the most up to the point form, to the overall context in order to do her/his work right.

Take the example of working on a decision step in a credit card originations decision that refers to the fact that a given customer is a high value customer. Well, it is likely that high value is an attribute of a customer that is defined by business logic somewhere else in the application, and the business analyst may have the need to understand as she/he is implementing the decision step. Similarly, she/he may need to understand where else that attribute is used and how, etc…

This is essential – and forgotten very frequently.

It actually reaches extremes not just with the single-metaphor approaches as described above which again have difficulties coping with varying context, but with single “if-then-else” or “when-then-else” rule representations. It is not true that single rules act alone – that is far more the exception than it is the rule (sorry). Those environment do not scale beyond a few tens of rules, and that, however powerful said rules are, is nowhere close what is needed in real applications.

There is much more to be said about this subject, but Carole-Ann is absolutely right on this issue being the biggest one that needs to be addressed to achieve successful decision management applications.

It is actually telling to see the difference in the implementation steps between how Carole-Ann would do it and how it is done frequently elsewhere. Carole-Ann will focus first and mostly on eliciting the proper concepts, representations and flow, then design the interface for business analysts to a point where it is functional for them and they can start using them, and then worry about the actual implementation behind. This has led to large scale implementations with complex but appropriate life-cycle, very dynamic evolution and still excellent run time performance.

Let’s avoid this pitfall going forward.

Unstructured flows

I have not blogged for a while… Too much work, too much involvement in too many decisions with too little time and information. Pretty mind-numbing work.

But it’s time for me to make some of my neurons and synapses to work.

During last couple of weeks, Carole-Ann (www.edmblog.com, www.twitter.com/cmatignon) attended the Gartner BPM summit. One of the key things she conveyed was a fair amount of discussion around the issue of “unstructured flows” and how the industry is addressing them. Besides the fact that there is no unanimity around what to name these flows, there is of course no real agreement on how important they are, and how relevant to problems they are.

I will try to give a first reaction to this in terms of the implications to decision management.

I will assume a very simple distinction between “structured flows” and “unstructured flows”
- “Structured flows” are those that can relatively easily be described in control flow diagrams, with explicit exception management – and by “easily” I mean in a way that can be explained based on a diagram in a way that does not require writing down additional details or having exceptions described through another formalism (something that tends to happen with business exceptions).
- “Unstructured flows” are those that cannot be described that way. They tend to be composed of micro-flows (pre-defined or constructed on the fly) that are stitched together at run time through the recognition of patterns in events.
This may or not correspond to what the rest of the industry sees as distinctions. If not, then just consider these definitions to be specific to this blog.

While I did not attend the conference, I am confronted on a daily basis with this exact issue. Among other things, I am currently responsible for the Enterprise Architecture group at my company, and involved in the architecture and implementation of large enterprise applications – most of which involve both “structured flows” and “unstructured flows”.

One key characteristic I see is the following:
- “Structured flows” tend to cover a large part of the automation of these enterprise applications – but focus on essentially those flows that are fairly clear, require little human intervention, and by virtue of being easy to automate, end up becoming a “must-have” but no longer a differentiator.
- “Unstructured flows” tend to focus on those difficult cases that are – at that point of maturity of the application – not fully automated, and where the interplay between humans (or at least not predictable events) and flows presents the big differentiator in the application – in terms of risk and/or value.

We can take many examples where that is the case.
Take fraud management:
- Automated “structured flows” capture the essence of the known or highly predictable fraud – and catch a large part of the fraud attempts
- But it takes “unstructured flows” to have humans intervene in helping qualify the complicated cases (high value customer, high amounts, etc…) and in identifying new fraud modes
Take insurance underwriting:
- Automated “structured flows” cover anywhere in the 60%-85% range of applications – and almost everybody has it
- But it takes humans involved in “unstructured flows” to deal with the “referrals” which is where the delicate dealing of special cases can help maximize the value/risk ratio


What is the implication of all this for decision management?

Decision management has already been largely involved in improving the relevance of “structured flows” to the business needs and constraints. Up to a large extent, the success of BPM in large enterprise applications can be traced to its ability to isolate the key business decision points, and automate the execution of these decisions in a repeatable and efficient way.
Business Rules Management Systems provide that key mechanism to separate from the flow logic the decision logic in a way that is manageable by the business and controllable by IT. They allow the “structure flows” to cope with the complexities of policies, procedures and practices specific to industries, sectors, enterprises, departments, etc.. And they are at the core at the success of many large scale enterprise applications.

In this kind of applications, the roles are clearly differentiated (even though BPM vendors will argue they handle decision management – they don’t): typically, BRMS handles the decisions, “structure flows” handle the execution of those decisions.
Generalizing it – and referring to a number of on-going discussions around CEP, BPM and BRMS (http://www.edmblog.com/weblog/2008/11/an-attempt-at-demystifying-cep-bpm-and-brms.html and http://architectguy.blogspot.com/2008/11/more-on-cep.html):
- CEP detects business events from the flow of system and application events
- Business events trigger “structured flows”
- Which delegate decisions to BRMS
- And then carry on the execution of those decisions leveraging various integration capabilities

Bread and butter stuff.

Dealing with “unstructured flows” introduces both challenges and opportunities in terms of decision management. Some of these – and I do not intend to be complete here:
- Decisions are taken by clearly outlined “decision services” – implemented through BRMS etc – as well as by less formal (in the sense of software-codified) services – humans in particular; either separately or in conjunction.
- Decisions and actions are stitched together through micro-flows that are triggered through complex event inter-play.
- Since decisions will take into account more informal steps, understanding them and managing their performance becomes significantly more difficult

The last two points are essential.

True decision management for “unstructured flows” will require:
- Understanding events, understanding event correlation and the translation of system/application events into real business events – this is what event management (I hate to try to use the CEP term) should cover.
- Making every effort to understand decisions at large: both the parts codified in BRMS, translated from predictive analytics or simply extracted from policies, procedures, as well as the parts not yet codified there and less formal.
- Including significant collaboration aspects as part of the context of decisions.
- Tracking the performance of the decisions been made to identify both potential for further automation of the informal parts, and to improve the usage made of the corresponding high cost resources.
- Simulating the decisions – including putting to work knowledge gained through the tracking of the decisions made in the informal parts of the decisions.
- Progressively optimizing the unstructured flows through experiments (champion / challenger)

Counter-intuitively (maybe), “unstructured flows” will provide more challenges and more opportunity for decision management technologies and products.

Predictions and Surprises

WSJ has this interesting series demystifying - or at least discussing - issues around numeracy, probabilities, and the corresponding impact.

I just read the following: http://blogs.wsj.com/numbersguy/the-crash-calculations-621/

A couple of key things that I feel are not really covered deeply enough:
- the quality, and ultimately the validity of predictions in a given context are a direct function of the relevance to that context of the explicit and implicit assumptions in the modeling process used to create the prediction
- decisions should never be made only on predictions obtained through models, they should include scenario based simulation and impact analysis

The reason we build models is precisely to create abstractions that we can manipulate with the tools of our mind and our technology. Tools that allow us to get out of the immediate sensor-driven reaction mode, and forecast. I believe modeling is essential to forecasting - I know some will say just crunching numbers with no a priori model is the path of the future (a Wired article I read one day) but that's a fallacy: as soon as you use the result of the crunching, you are using a model, maybe an implicit one, but you are using a model.

But who says abstraction says context-dependent simplification. And that is key. Understanding the context the abstraction assumes, and the sensitivity of the resulting model and predictions to variations in that context is paramount to being able to leverage these predictions.

That gets lost. Because it's complicated and because of the multiple psychological aspects that make understanding and leveraging statistical and probabilistic results very difficult for the average person.

See the points made in the EDM blog by Carole-Ann (http://www.edmblog.com/).

More on CEP

Obviously, the CEP / BRMS / BPM / boundaries debate remains hot and continues provoking soul searching.

My previous post on the this was a long (and complicated in the way it was phrased) ranting around the fact that CEP attempts to cover too many areas of the EDM picture, and at the same time does not do a deep enough job at solving the challenges around its core contribution - events as first class citizens in EDM apps. I do think the points I tried to make there remain valid.

I did also contribute a post in another blog as a reaction to a thread on the same subject.
Here is the essence of what I wrote there:

In this debate, we are essentially dealing with three core notions: events, decisions, processes. There is of course much more than that, but I think the confusion we are seeing results from lack of solid boundaries between responsibilities around these three notions. Getting to basics helps.

- Events are all about detecting what decision needs to be taken in a complex temporal context (essentially event correlation, converting monitored ‘ambient’ events into relevant business events that require reaction)
- Decisions (and I will use that term instead of rules) are all about deciding what needs to be done as a reaction to those business events
- Processes are all about executing the decision taken

In a very simplistic analogy,
- Dealing with events in an enterprise application is akin to the sensory system absorbing the information from all the sensors and sources it is connected to, and constructing a view for further decisioning and action, with or without immediate reaction, and communicating it through the nervous system.
- Dealing with decisions in an enterprise application is akin to the multi-step highly collaborative decision making the brain engages in, resulting in events and situational analysis, inclusion of further data, inferences, deductions, etc. and leading to conclusions on further reactions or proactive actions.
- Dealing with processes in an enterprise application is akin to the body executing the plan elaborated by the brain including the input from the nervous system.

CEP should address primarily the first, BRMS and other decision management technologies the second, business process the latter.

What I just outlined is centered operational aspects - as in the operational / improvement aspects distinction presented by Carole-Ann in her talks about the EDM vision at ORF and BRF [http://www.edmblog.com].

The improvement aspects cover how to leverage the information gathered by the operational system - as well as expertise - in order to improve the decisions. It starts by gathering the information and understanding it. All aspects above are to be covered: Am I capturing the right events? What if I decided to capture something slightly different: does that make my business events more relevant? Why did I capture this event at that point in time? What other events are captured within a given contextual distance from this one? Ditto for the decisions (the rules). Ditto for the execution (the processes).Why not just call these things "Event Analytics", "Decision Analytics", "Process Analytics"?Yes, they are connected. But different.

This is simplistic of course, but it has the virtue of being clear. Maybe we can try to reframe the discussions on these issues in that context?

State, events, time - a view on the confusion around CEP

CEP

Over the recent few months, the EDM world I work in has seen a lot of noise generated by the arrival of CEP - "Complex Event Processing" - and the impact it has had in terms of provoking soul searching in the BRMS and, to a lesser extent the EDA, ESP and other E(x)(x) worlds.
The "E" in these E(x)(x) is "events" which are of course at the core of CEP.
But so is "complex" and "processing", both of which lead more to the area of EDM or BRMS.

This is one of these situations in which a technology addressing at its core a valid set of concerns gets dropped in the middle of a complex soup of acronyms, and confusion ensues.

Of course, the CEP specialists should bear with me for the duration of the blog. I am aware that CEP has been around for a long time, etc., but it's also clear that it is undergoing a renewal through its adoption by the big platform vendors (IBM and Oracle acquisitions) and the innovative ones (Tibco, JBoss).

Why am I writing this blog? Essentially because I believe that the confusion is self-inflicted because as an industry (enterprise applications) we have not been careful to focus the usage of the terminology to its key area - events - and we've spent too much energy trying to justify the complex and processing aspect.

While some of the points below touch on semantic confusion (big words), I will try to remain pragmatic. Let's take "event", "complex processing" in turn.

"Events"

It is true that "events" and their semantics are quite important in systems that need to make decisions.

This is not new, it has always been the case. So why are we - the enterprise software world - only recently starting to give to "events" the preeminence they already have in other worlds - such as the real-time systems world I started in?

Well, simply because the enterprise world has a way to cope with a lot of the value of events by translating events into state.
Traditionally, the occurrence of events, and in sophisticated systems, even their sequencing and timing, are encoded in the state of the system, transforming the "event" management problem into the dual "state" management problem.
Take an example: a fraud detection system is of course keenly interested in knowing what happened where when in which order. It's not a surprise that most CEP vendors use fraud detection as a key example. Well, guess what? Fair Isaac's Falcon Fraud Manager, by far the most used credit card transaction fraud detection system, as well as a host of other fraud detection systems, do not use CEP as defined by the current vendors. They translate events into profile (read "state") information, and they enrich at run time the profiles using sophisticated business rules (not even production systems). This profile encodes variable values that are highly targeted precisely to capture the essence of the business semantics of the events: "number of purchases of gas using the same credit card charging less than a certain amount within a window of time and a geographic region".
You could say that what they have is a sophisticated hugely scalable (90%+ of all credit card transactions in the US go through Falcon) stateful decision management system, supported by a powerful "cache" of variables computed through complex business rules.
And there are many cases like that.
The reality is that the "enterprise" world has been dealing with events for ever. They have simply not needed to resort to any E(x)(x) notion / stack / etc.

That being said, I believe there is an important piece in "event" centric expression of logic - and that is the separation of the event processing logic from the rest, and the resulting clarity, elegance, maintainability and ultimately all those scalability, ability to audit, robustness, ..., qualities that result from clean concepts, clean designs, clean architectures.

Which brings me to the following first opinion on CEP:
(1) CEP should stop worrying about the origin of the events and focus on the events themselves. It does not matter how the events originate, and the issues of ESB, EDA, ESP, in-database generation, etc..., are all orthogonal / independent on how events-dependant logic is managed.
And to the second opinion on CEP:
(2) CEP should stop worrying about caching. Yes, caching is important but irrelevant to the power of the approach - as the fact that among the largest and most scalable event-driven enterprise apps, many handle the issue with no need to couple the event management piece from the management of caches. Right now, there are efforts to extend the Rete structures and to adapt the algorithm to build this cache in a more efficient way for the corresponding type of rules processing. Great usage of the technology, but that will not make the potential power of event centric approaches any more compelling.

Maybe it's time to be a little more constructive.

(3) CEP would do wonders in enterprise systems if it focused all its attention to the "event" part: the semantics of events, the richness of the event context (time, location, referential, ...), the clean semantics of the key contextual notions (time operations including referential management, etc...), etc.

The events semantics question is not innocent, and is absolutely not a settled question - witness the numerous exchanges between clever people than me on this subject.

I had a discussion with Paul Haley once on this subject and we went into the "what is an event" question that has the virtue of quickly getting people upset. It's a valid question: the definition of "event = observed state transition" has the bad taste of defining events in terms of state, but its key issue in my eyes is that it supposes observation of a state and lacks content.
The value of events is that they have intrinsic context that are not naturally contained in state systems: they occur at a point in time with respect to a given referential - or more generally, they occur at a contextual point (could be time+location, etc.) with respect to a given referential. Different events used within the same system may have their intrinsic context expressed with respect to different referentials - and that will be the default case in any distributed system.
Events occur, they are atomic, immutable. Their only existence is their occurrence. We may track the fact that they occurred, but an event instance only happens once and is instantaneous. An event does not last a duration. That is not logical to me - its effects or the state change it triggers may last a duration, but the event in itself is instantaneous.
Which leads to the fact that there are natural event correlations you want to express (not just discover): an event creates a state transition, a correlated event will create another state transition that will bring the state back to the original one.
This is just my opinion - but if you talk to more than one real specialist, you will get more than one view. Not a good sign of maturity of the concepts.

Clean ontologies / semantics / etc. needed.

With the clarification of the semantics of events and their intrinsic referential-dependent context are clarified, we need to focus on what we want to express about events - and for that, we need to bring on the enterprise application experts.
There is a lot to learn from the real-time systems experts - refer to the very old but incredibly good insights from Parnas' work. There is a lot to get back from the original event correlation systems - many built with systems such as Ilog's rules engine. These could even be said to be the purest predecessors to what CEP attempts to do.

What this will end up doing is giving us - the decision management world - a very powerful tool to "naturally" express logic on events, with their referential-dependant context, and to do so in a way that enables true management (things like verification of the logic included), powerful optimizations, etc.


I honestly do not think we are there, and I would really like to see the standardization world - the OMGs and others - help us get there; but I do think we need the enterprise business app drivers. We had that, in real-time systems: the military and transportation apps.

I would love the specialists to prove me wrong and to show me we are there.


"Complex processing"

This will be shorter.

As stated above, I believe that:
- CEP should narrow its processing ambitions. One approach is to focus the purpose of its processing to clear outcomes - such as what the correlation engines did 20 years ago. For example, we could say that CEP's processing is about processing / correlating events to generate higher order events: transaction events to generate a potentially fraudulent transaction event. I will call these "ambient events" and "business events": the CEP processing goal is to translate ambient events into business events
- CEP should focus the complexity of its processing to the corresponding revised ambitions.
- CEP should leave all issues related to event streaming, event transport, event communication, etc. to other layers.

I may be a purist, but I see a simple picture:
- leave anything related to transport, communication to other layers
- use this revised CEP to express and execute event-relevant logic, the purpose of which is to translate the ambient events into relevant business events
- have these business events trigger business processes (however lightweight you want to make them)
- have these business processes invoke decision services implemented through decision management to decide what they should be doing at every step
- have the business processes invoke action services to execute the actions decided by the decision services
- all the while generating business events or ambient events
- etc.

As such, CEP will include a semantically sound event-with-intrinsic-referential-dependent-context model, a corresponding language (EPL or vocabulary) to express logic, algorithms to efficiently execute (wide open field - tons of people doing analytics, Bayesian, rules, ...), techniques to verify (wide open - and fairly empty: I only know of the real-time folks), etc.

And there, the value of CEP is clear. Of course, it is lower than what CEP vendors would like, but significant anyway.

I am hoping this is controversial enough to bring on flames...