Some Background

Ten years ago, during the dot.com era, I was given the responsibility of building an online credit system to approve online b2b transactions.  To make matters even more complex, coverage had to be global, in 20 countries.  The strategy was to develop a web-based, commercial credit system allowing automation that would process a significant number of transactions, with consistent decisions, without increasing headcount or resources.  Like most projects, the system was needed yesterday with high approvals rates, high profitability, and low risk tolerance.

A brief background provides a good case study for others to follow and help to get over any hesitation to implement Business Rules Management (BRM).  My experience was on the business side, having filled multiple analytical roles in different product groups.  My technical experience went only as far as being an expert at MS Office, so ignorance was bliss when the challenge to drive this project fell into my lap.  In the end, analytical and management skills proved to be the most critical at filling the role of chief architect to translate credit models into process flows.

I endured the classic business and IT disconnect — internal and external — with the business wanting solutions quickly and the technology side requiring detailed requirements for coding.  Lack of trust and pressures to meet deadlines assured that the initial development, coded in Java, would fail miserably.  After that false start, a Proof-of-Concept (POC) was initiated to move the algorithms that drive the credit process to a Business Rules Engine (BRE).  We identified several benefits for implementing a BRE, but the advantages that stood out for this specific project included:  complete control of the rules, fast execution to adjust to market conditions, decision tables with Excel-like functionality, audit trails to track each step, and easy-to-understand code.

There's a natural evolution to BRM because it's a business enabler with an emphasis on:  business logic as well as processes and conditions that marry up with the technology side to tie into rule flows, templates, decision tables, and audit trails.  Not enough success stories are broadcast to the business community from one of its own, hence my motivation for these articles.

The goal of this series of five articles is to provide a framework — to share some of the positives and negatives from lessons learned — before diving into BRM.  While there is plenty of technical information, the terminology of BRM can be intimidating and confusing, which does not serve to educate business users.  My hope is to educate and help guide the masses in the success and pitfalls, based on my adventure at implementing BRM.

The topics I will cover are:  Identify Core Problem, Get Support & Help, Document & Code, Test & Retest, and Monitor & Adjust.  Since my opinions are based on my own experiences, the views expressed may conflict with conventional guidelines put forth by the BRM community, in terms of technical and structural implementation.  But the good news is that the project was a success!  Every business is unique, with an embedded culture that differentiates it from competitors — the most important factor in that success was capturing the essence of the business and building a capability for continual adjustments, ultimately to add value for the customer.

Identify the Core Problem

We began by identifying a core problem, which entailed these tasks:

1. Identify the problem and the cost of staying the course.
   
   
2. Perform a quick cost-benefit analysis (in business terms) to justify the project, keeping in mind that too much analysis can become paralysis.
   
   
3. Identify whether a candidate solution is dependent on technology and, if so, whether a Business Rules Engine (BRE) is the appropriate choice.

Identifying problems that impact either top (sales) or bottom-line results (profits) is the initial hurdle to overcome.  This fact-finding stage rests on the business side to determine if current technology has become a hindrance to progress or long-term growth initiatives.  Before starting any big project, the business needs to provide a best guesstimate of the cost of staying the course versus fixing the problem.

The initial development of the commercial credit system was coded in Java, with the focus tied to the front-end, as this is what customers saw first.  I joined the team to lead the effort to manage the heart of the system, which was its set of algorithms.  These algorithms employ several models that perform the critical function of approving or rejecting limits.  I quickly caught on to both the severity of bugs and the strained relationship between IT and business.  The business blamed IT for bad code, and IT blamed the business for bad documentation and memory loss.  Yet, for a majority of cases, IT was really not to blame as I came to realize that my business counterparts also had a type of memory loss and were not consistent on a lot of views.

While strained relationships can be fixed over time, bugs that actually lead to losses are not forgivable.  Losses incurred due to erroneous code more than justified my objective to explore other alternatives for housing the algorithms — without going through a significant business case proposal.

One of the biggest pitfalls for most large scale projects relates to the Software Development Life Cycle (SDLC), which requires that code undergo various stages of testing before it goes live (goes into production).  The lengthy process, combined with the need to outline detailed business requirements, ensures that any changes to code will take months to implement.

The solution that became a clear front-runner was a Business Rules Engine (BRE) — we selected Blaze — due to:  its ability to empower users to take control of key business logic, its fast execution, the support for decision tables, and user friendly code with strong audit trails.  The ability to change key parameters and amend calculations, along with fast execution, sold us on a BRE.  However, it is important to emphasize that fast execution should not be the sole consideration — also important was the actual control of key parameters, including a set of calculations, conditions, discounts, or exclusions that can boost revenues or reduce losses.  While the business side may be inconsistent and change views about front-end functionalities, any topic regarding the core business (including overall strategy, calculations, formulas, pricing, and margins) must be factual, consistent, and not debatable.

Referring to the Business Rules Manifesto, key advantages of a BRE included the following:

• For the Sake of the Business, not Technology
• Of, By and For Business People, not IT people
• Managing Business Logic, not Hardware/Software Platforms

The next step after identifying the core problem was getting support (and help) in developing the solution.  This will be covered in the next instalment.

# # #