"Business rules are everywhere" — they are one of the key dynamics in the new digital world.  Rules play an even bigger role than just guiding logic (think fraud detection), governing organizations (think ACA and HIPPA), and making sure organizations stay compliant (think Basel II).  The new roles for rules are around the growing control that customers have on their own user experience and around becoming constraints on emergent and evolving behaviors in processes, applications, and the internet of things (IoT).  This is going to require some new thinking about business rules — how they are authored and by whom, as well as how they are managed and most efficiently executed (think a cloud-based decision service or an enterprise class version of IFTTT).

In this series, "Business Rules are Everywhere", Paul Hessinger^[1] and I identify the opportunities and threats of getting business rules right as they permeate the processes, systems, resources (human or otherwise), and applications.  In this first segment we illustrate how rules can be 'cool' or they can be 'cruel'.

The notion of having control over the rules that affect personal or business results is a strong driver for the need for explicit rules in traditional or new digital programs, systems, applications, and processes.  Business rules are often the forgotten essential puzzle piece in being able to keep pace with business change. 

Here, in his charming story-telling style, Paul Hessinger relates his view on why rules are cool and points out some nastiness with rules as well.

Rules Are Cool

Rules — a word that can cause a visceral, rebellious reaction — particularly if you had a Catholic elementary education, with the memory of a ruler appearing out of the arm of a nun's habit to remind you of a rule or to enforce it with a quick snap.  Not so cool.  At the recent British Open Golf Championship a player in contention violated the slow play rule and was given a one stroke penalty.  Cruel rule.  But certainly in a business context, rules provide needed structure, if not the possibility for effectiveness or even agility.

In a nostalgic return to my hometown and early IT days, I visited what was once a thriving part of America's economy, Bethlehem Steel's Lackawanna Plant on the shore of Lake Erie, south of Buffalo, NY.  In 1983 economic forces caused the company to close most of the facility except for a 1975 addition, which used technologies that few might recognize today — DEC PDP11 process control computers and IBM 370/168 mainframes running IMS.  It was an almost-100%-automated steel production facility. 

I recalled a 1975 overnight shift when the Plant's CMO (back then, Chief Metallurgical Officer) — 6'6" Helmut Krannenberg — stormed into my DBA cube.  The rules in a COBOL program and a mainframe database that directed the process control computers to configure the metallurgical content of steel bars for specific customers were not producing the expected results.  He wanted them changed now and he wanted to do it himself — or at least watch me do it.  Suddenly, the specter of that nun with a ruler back in grade school was not so unpleasant. 

The relevant COBOL program had many complex, heavily-commented IF THEN ELSE rules embedded in the overall logic.  It read data from Metallurgical and Bar Specification databases to generate a production order that was then communicated to the PDP11 in the Bar Mill, five miles away.  The CMO read the comments, and looking at some database records, he spotted the likely error in the logic.  "Let me change it," he directed emphatically.  "It's not that easy, but I'll do it for you."  "I'll wait right here so you get it right."  Some COBOL rules were changed (and the notes, which Mr. Krannenberg authored on a chalk board so I would get them right, were added as further documentation).  The program recompiled with a unit test error that revealed a minor issue with the database structure; IMS DDL/DML rules were updated and the databases reconfigured.  After a few hours, a new test was ready. 

The CMO waited with me and asked the control room for the test results to be sent to him.  He inquired about the process we just went through, and while frustrated he could not change the logic himself, he was impressed with the rules architecture that the project design team had used.  The test results arrived and the new bar of steel was perfect!  Helmut proclaimed "RULES ARE COOL!"  Sorry Outback Steakhouse, "rules, just right."

On a recent airplane trip, inflight WiFi delivered an email from the airline to my iPad:  "Hi — Sorry, your checked bag did not make it on your flight with you."  I sighed, I guess quite audibly as it caught my seatmate's attention — his empathetic look said "anything seriously wrong?"  I let him see the email:  "But don't worry.  We see you're flying to a city where you have a residence address listed, so we're going to deliver your bag by 8pm tonight.  It's already on the next flight to Chicago."  My seatmate also noted the email told me I could "change the rules for baggage delivery by logging into my account," and with just a bit of explanation about "rules" he proclaimed "RULES ARE COOL!"

Indeed.  Scenarios such as these illuminate the power of separating rules from the inner workings of IT systems, so that those that define or even consume rules can make changes to them.  That makes business decisioning and event processing systems more agile.  Once you start looking, rules are everywhere — as are the opportunities to make systems more agile with rule technology.  Mobile rules for patient care in an ambulance, onsite maintenance of an HVAC system or insurance claim reviews, fraud detection, public and private Health Insurance Exchanges, or optimum use of frequent flyer miles for a dream vacation.  So many examples where cool rules are the rule, not the exception, nor an oxymoron.  Sure, the devil may be in the details.  But once you start "Thinking in Rules," the possibilities seem endless for rules that drive better, decisive results and that is — cool.

Rules Are Cruel

There are rule-intensive systems that border on "life and death" or, if not the latter, then "health."  Electronic Medical Record Systems (EMR) are based on essential rules so that proper care is provided, treatment and test results recorded in one place, and lives made healthier.  But who authors the rules?  How are the rules adapted to specific deployments of the EMR?  Here is a real-life example of how the inability to configure rules can have a profound impact on the customer (here patient) experience.

Cruel rules — a person just had a very difficult spinal tap procedure.  Three rules governed the post-op: 

1. blood work right after the procedure;
2. drink a Coke (no, really!  for a Coke lover, a cool rule — it could be Pepsi as well, so a "configurable" rule);
3. pretty immediately lie down for at least 8 hours.

But another EMR rule was that the attending physician had to certify that the procedure was done before blood work.  The lab orders could not be produced; the MD was on vacation that day.  The EMR did not have a 2nd rule as to how somebody else could fulfill the 1st rule.  So the patient sat in a waiting room as IT was called.  This quickly became cruel.  Finally, IT called and reported that they had gotten in contact with the ISV for the EMR and had been told that "those permissions for the EMR site to set rules for who could change rules would be in the next release; we'll have to Webex into your system to provide a work around — but the new release will only let IT change those rules."

The "easy" solution?  Embrace the theme of this article — thinking in rules.  Allow subject matter experts to manage their own rules.  Use rules to configure software, rather than code to customize it.  Make business user ownership of configurable decision logic and rules for customer-facing application an architectural requirement.

Net; Net

Business and technology rules are everywhere so Paul Hessinger and I exhort you to think in rules and to make them separate from systems — easy to define and understand and change in a manageable way.  Next time we will present an actual business rules case study, so you can see rules in action and see how many legacy systems with hardcoded logic can be modernized via a "think in rules"™ mindset.

References

[1]  Let me introduce Paul, with whom I have collaborated with for a ungodly number of years.  He is secretly one of my heroes, but don't tell him. :)

Paul Hessinger is an accomplished technology and business strategist who brings 30+ years of experience and effective leadership to Chicago-based InRule Technology, where he has been the CEO since 2004 . He has functioned with a broad span of responsibilities:  as a Chief Technology Officer, Chief Marketing Officer, Chief Operating Officer, or a Chief Executive Officer in the professional services and software industries.  Paul spent 16 years with Computer Task Group, the first professional services firm to be listed on the NYSE.  He has acted as executive counsel with leading IT vendors and Fortune 500 firms, assisting with long-range IT strategies, acquisitions, leveraged buy-outs, and fund raising.  

# # #