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.
Posts
