Call to Action

Attend an upcoming SMARTS Product Tour webinarRegister Now
Home » #1 Pitfall in Decision Management

#1 Pitfall in Decision Management

Written by: Carole-Ann BerliozPublished on: Feb 16, 201013 comments

Decision Management is an up-and-coming discipline as described by Carlos in an earlier post.  We truly believe in its potential and what it will bring to Enterprises.

That being said, the road to greatness is paved with pebbles.  We have seen over and over the same errors in its adoption and implementation.

I want to discuss one of the main issues I have seen first hand at some of our customers’ site.  Many start Decision Management with a Business Rules implementation, mostly with Automation in mind.  In order to process applications, claims or more generically transactions, new systems are built on top of Business Rules Management Systems (BRMS).  Efforts being driven by IT, even if built for the Business side of the house, a few aspects are often overlooked.

User Interface…  In your face…

Mike Gualtieri from Forrester has been stressing quite vocally this past year the importance of user experience.  Good design could make the difference between success and failure.  He is totally right.

Over and over, we have seen IT groups overlaying some business words on top of a rules language and calling it a business user interface.  As a result, the user interface looks like a technical interface, where business users must create technical rules, following pretty much a technical syntax but with some business veneer.  Some go as far as exposing IF-THEN point and click rule building screens with very little concern for the core concepts they map to.  What follows?

In the best case:

  • Frustration finding stuff
  • Clumsy navigation
  • Intellectual confusion

In the worst case:

  • Incorrect codification of business concepts
  • Rigid Business Rules that can’t express the nuances of the business
  • Terrible performances

When the effort to design good rules  is put on the shoulders of business users, their user interface adoption and success both end up being poor.

First they do not want to be turned into programmers.  Not mentioning that they should not be turned into programmers…  Business expertise is invaluable, why spend time teaching those guys how to write code?  They do not like it, they will likely write sub-optimal routines.  As a result only a few technical-minded business experts make the transition.  Most others resist.

Second, if they can’t easily express their concepts, they lose faith.  They deal day in and day out with product definition, pricing schemes, or legal regulations.  Mapping those concepts to an IF-THEN format can be challenging.  In many cases, one product definition will result in a bunch of business rules that may scattered in a project (eligibility criterias, product characteristics, etc.).  In addition to the initial set up challenge, breaking down the elements of a Product into scattered business rules naturally adds complexity to the maintenance of those business rules.  Finding those elements down the road might be difficult if not impossible.  Business Rules capture should not be such a mind game.

And lastly, Management’s endorsement is a critical aspect for success but it may not last when codification mistakes and errors turn into very costly expenses.  When codification of business rules is a mind game, it is unrealistic to expect that all business users will be able to perform consistently without tripping.  Some verification or simulation tools might help catch those early but mistakes are bound to happen in this environment — like they are bound to happen in a business user / developer paradigm by the way.  When business users have direct access to the Product box those (granted with Quality Control processes), there is an extra element of risk, new paradigms to get used to, new processes to set up.  Complex mappings as jus described make this approach error-prone.  It is bad enough that Enterprises mis-adopting BRMS do not rip the benefits of business user management as promised when well-designed, but they are at risk of pushing incomplete or incorrect business rules into their systems, errors that could translate into missed opportunities, terrible deals, or violation of legal regulations.  All of them costing missed revenue or hefty compliance fees.  One of those might be reason-enough for management to pull the plug on the technology when unfortunately technology is not the use, design is.

Are all BRMS implementations doomed?  Of course not!

I want to bring your attention to the importance of a business user interface.  Do not treat it as an afterthought.  Do not focus 80% of your time on the technical implementation with a small effort to map that to the Business.  Start your design with your Business in mind.  Mapping to an implementation that works can always be done, the opposite is not true.

In some project we went as far as starting the implementation of the business user interface with no regard whatsoever for the back-end technical implementation.  It provided a lot of flexibility for Agile development: fast feedback cycles, incremental approach, etc.  The traditional rules first approach proved inflexible.  I wish I got a dollar for every failed project that started “with only a technical interface”.  The transition to a business interface almost never occurred.  The Business Rues-first approach seems more effective although less understood out there by the vendors.

When focusing on business users, IT is forced to consider their concepts in a manner that makes sense to them.  That is a great way to handle requirements, from the source.  As a result the user experience is more effective for sure but also the quality of the underlying rules will be automatically improved.  User experience includes many aspects though and all should be considered:

  • The way business concepts are represented – different metaphors like decision tables or decision trees could be used for specific parts of the decisioning logic
  • The way business rules are grouped together – packaging by ruleset, although natural to the IT implementor, is often foreign to the business user.  There is no good business reason to display one rule at a time in the user interface and/or to co-locate business rules based on execution grouping.  Grouping, linking and overall organizing should be done with as little focus on implementation in mind, only thinking about the actual user and his/her day-to-day activities
  • The way users navigate through the business rules – Business rules are hardly isolated.  It is very common that one rating table is selected as a result of some portfolio segmentation.  It is also common that business rules are logically connected.  For example, some rules may be State-level overrides to Nation-wide business rules.  We see this pattern of additional non-structural navigation everyday as part of every system.  As data gets huge, users need to navigate more dynamically. empowers shoppers with all sorts of links for fast access – product bundles, accessories, discussion forums, etc.  Linkedin strings operations to preview a member profile from the invitations received in the inbox.  Google gmail goes all the way to enabling structuring by tagging.

Regardless of the need, those kinds of user interactions are becoming natural as part of the web sites we interact with on a daily basis.  They will become expected of the Enterprise systems as well.  Per Mike’s recommendation, do not alienate your audience, design for them.  Create the user experience that will make your project successful,  Decision Management or not.

13 thoughts on “#1 Pitfall in Decision Management

  1. Great article and I completely agree that the real power behind Decision Management has yet to gain momentum in the business community.

    There seems to be so much focus on the technical side coupled with strange IT jargon that confuses rather than preach the potential benefits of BRM.

    While BRM empowers the business to take control of certain mission critical rules, I completely agree that programming will lead them to become non-believers quickly. There’s a need to have a high level discussion in layman’s terms related to successful implementation of BRM as well as pitfalls.

    Dencie Mascarenas

  2. You are so right to draw attention to this issue, Carole-Ann. The naturalness of the business knowledge maintenance interface is crucial for long-term success. (I must confess I have come to this realization only in the last few years.) It should be a major focus in requirements gathering and should be delivered incrementally to allow feedback and improvement.

    The only comment in your excellent article about which I have reservations is this: “There is no good business reason … to co-locate business rules based on execution grouping”. I would say one of the reasons that business rule maintenance can get overly “technical” is that the original decision analysis has not cleanly partitioned the rules; if a ruleset makes only one clearly defined decision the interface for maintaining it can be much simpler and more business-focussed. This means the functional areas of the interface should tend to mirror the sub-decisions made by the services. I do however agree this in itself is not enough, and that non-structural navigation will be an important facility.

    I wish you and Carlos the very best of luck in your new ventures, by the way.

  3. Very good point, Alan.

    Let me try and phrase it slightly differently though. It may be a sound architecture decision to group business rules maintained together into a single decision service. You might end up with a collection of decision services that contain little segmentation inside.

    I would venture to say then that the Business side dictated the IT implementation.

    We are splitting hair though 😉

  4. Carole-Ann

    Great post.

    I fully agree with the points you make, and with the overall assessment that getting the business analyst interface properly designed and built with their concepts and workflows in mind is key to the sucess of decision management applications.

    I added a few notes in – hopefully they will contribute to keep this essential pifall in the minds of all decision management implementation specialists.


  5. Refreshing! We need more people from our industry saying just this, Carole-Ann.

    I agree with you more than Mr. Fish concerning the need to manage knowledge at a higher level than its utility within a snapshot of dynamic business processes. Carlos and I debated this at the Business Rules Forum (and eventually traded posts –

    Another thing possibly worth mentioning is that Ron Ross and others are on the right track in emphasizing capture, vocabulary, semantics, and logic, albeit not adequately progressed with respect to implementation (as by rules engines).

    Best, Paul

  6. I agree with you guys on the importance of the UI. If the business is to truly own the decision strategies, this will be critical to success. Too often the “IT” guys choose the tool they will use because they don’t understand the importance of usability for the non-IT user. The successful large banks deploying decision management understand the importance.

  7. Thanks for this, Carole-Ann.

    This is a very valid point, that to me is not specific to decision management, but rather general to any type of software.
    What people look for is a way to solve their problem, they do not care about the technology. The way the solution is implemented has no relevance to them.
    So if you build your decision management solution (or any software solution) solely on the actual technology, you lose.
    Back to good old principles: create a set of use cases with the business analysts, prototype them by showing them the UI, and once it is validated, build the solution from the UI.
    Unfortunately, it is usually very hard for IT organizations to do this, as resources are limited, and the support for decision makers is not always there (does an internal solution really need to take that much time? cost so much?). Unless of course when the solution to be built is business critical.

Please share your thoughts on this post:

Your email address will not be published. Required fields are marked *

 2016 SparklingLogic. All Rights Reserved.