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. Paul Hessinger relates his view on why rules a cool in his charming story telling style below and points out some nastiness with rules as well.

See Paul’s Background   http://jimsinur.blogspot.com/2015/08/announcing-new-series-on-business-rules.html

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 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 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, then. Suddenly, the specter of that nun back in grade school with a ruler was no 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, 5 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 quiteaudibly 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. 3 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 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 got in contact with the ISV for the EMR and were 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 blog  - 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 make them separate from systems, easy to define and understand, and change in a manageable way. The next rule post will be an actual business rules case study, so you can see them in action and see how many legacy systems with hardcoded logic can be modernized via a “think in rules TM” mindset

See the first invasive technique in http://jimsinur.blogspot.com/2015/08/top-three-invasive-techniques-for.html

Information About InRule: http://www.inrule.com/