Monday, September 28, 2015

Many Faces of Rules in and Around Processes

Rules have been in the shadow of process for over a decade, but it is time to give rules their due. If we make the rules, particularly business rules, transparent, explicit, easy to understand and easy to change, we can possibly cope and flourish with the speed of change that is only accelerating. I'd like to explore some of the more common faces of rules that face us today and will emerge in the future.

Deep Frozen Logic:

As long as there have been computer programs, logic has been deeply embedded within them and programmers have been the gatekeepers of business change. Where the logic is complex and deep and static, this is a perfectly good approach.  However, today, less and less of the business logic represented by rules really falls into this category. It is a dying breed in a world hungry for change.

Explicit Rules:

Instead of deeply embedding, many savvy business and IT professionals have figured out what rules change the most and separated them from the deep frozen logic approach. This allows for quicker change and in some cases, less deep testing for some logic (look and feel for instance).

Visual Rules:

A key to making rules understandable and easy to change is to make them visible. The three most common representations are decision trees, decision tables and decision flow models. These have been used in combination in some implementations. An emerging standard that plays well with process modeling (BPMN or BPMN like) is decision modeling (DMN).

Flow Rules:

These are specific types of rules that guide the flow of a process instance inside a process, a process snippet or sequential portion of a case. They are about deciding where the instance or case is going to go next. It is a next step or action thing.

Orchestration Rules:

These are specific types of rules that determine which logic is being called upon to complete a step or action. These are often deep and tight logic portions of business or technical logic. Often the results of the code or service called are captured for the flow rules to make their determination for the next step.

Interface Rules:

These are specific rules about the look and feel of a particular process application. They can also help decide the next portion of the interface to bring up (sub screens in the UI). They are often key in helping the customer experience and exist in the engagement portion of processes or applications. More and more these are being exposed to customers for customization on a large scale. These also apply to dashboards and scorecards related to process performance and business outcomes.

Data Syntax Rules:

These are specific rules around protecting the accuracy of data and include data domain definitions, data relationships and cross data field editing. These are critical rules for data accuracy .

Transformation Rules:

These are specific rules around changing the format, domain, context and relationships around data and their formats. These are quite necessary to get systems to talk to each other and certainly for systems to talk to people.

Notification Rules:

These rules are for when certain people or systems need to know when something(often an event or a pattern of events) is worth noting. For instance when a set tolerance is violated.

Context Rules:

These rules are telling the process or portions thereof, what conditions and patterns might do to their particular behavior. If they are being used in a on demand situation versus a routine scheduled situation. This allows the same rules to behave a bit differently. This is often used in geographical and countries that need a local variation. There are other variations, however.

Constraint & Governance Rules:

These rules are about keeping process or application actions away from conditions or situations that could cause harm (for instance if an emerging process would act badly). These rules also keep process participants (humans or machines) from doing something undesirable or,worse yet, illegal. These are sometimes referred to as boundary rules.  

Net; Net: 

There are many kind of rules in all sorts of formats. This is not a complete classification, but this list will help you and your processes. The key is to promote them for easier change as close to the parties impacted where possible.

Thursday, September 24, 2015

Blog Activity for 3Q 2015

I thought you might find it interesting what folks are interested in reading about process related topics on my blog.The hot topics were business rules, fast data, security and dealing with legacy in the digital world, but that might have been influenced by the fact that I did a series on each topic. I would sure like to hear what topics you would be interested in, so I can more meet your needs. Please post a comment, if you think there is a need for a particular topic. 

Direct Links Below in Ranking Order:

Where in the world are the hits coming from?  The US is always number one by a wide margin and is not shown here. There is no surprise that France, Russia & Germany are at the top, but I am surprised that Sweden jumped on board displacing Turkey.

Monday, September 21, 2015

Just Say "No" to Hard Coded Logic

This is a blind case study about how a large US bank switched it's mode of operation under the pressure of forced governance changes. This new approach of leveraging explicit rules is now a new and growing habit for this bank. The story below, written by Paul Hessinger, CEO of InRule, shows the power of putting business rules in the hands of the business folks.

Scene I  The Legacy Problem:

Circa 2008, large USA bank is about to deploy a new, BRMS based BASEL II Risk Analysis Compliance System – The Source Code Control Governance staff informs the IT team that they consider the business rules authored by the Risk Analysts to be source code. As such, they need to be stored and managed by the bank’s standard tool, the even then venerable (read old) PVCS. The Source Code Control staff said that TFS would be the new standard at which point the “source code” would need to be “managed” there.

To put it mildly, a spirited (real heated) debate ensued. The IT team asked if the previous Risk Analysis Compliance System which was a group of complicated (a real  cluster %^*#) group of XL spreadsheets had been subjected to ‘source code governance”. There were quite a few blank stares but no answers beyond a “good question” shrug of the shoulders. Much of the logic had been written by quants (financial jargon for a quantitative analyst -a person who specializes in the application of mathematical and statistical methods – such as numerical or quantitative techniques – to financial and risk management problems) as underlying (real hard coded, hard to find let alone understand and certainly to update) formulas. The XL files were then put to use.

Scene II Big Change Hits the Fan:

Funny thing happened – BASEL I was replaced by BASEL II (remember those ‘May You In Interesting Times” in the economy  with the dot bomb crash and then the 2007-08 recession? The “code” had to be changed and the quants said “not our jobwe only write new stuff".  The Risk Analysts went to IT and said “we need you to update these.”  IT did not even know they existed. The Banks’s Chief Risk Management Technology Officer (CRO) stepped in commissioned an RFP for an Systems Integrator (SI) to build a new “user friendly” system.  The SI proposed a multi-million Dollar “solution” that would in effect build a custom version of what COTS products called Business Rule Management Systems. The CRO was exasperated. The bank was facing regulatory pressure if not sanctions. He took it upon himself to google “rule solutions for risk management” and lo and behold on the first page he found what seemed to be a viable solution.  While at Starbucks he called the CEO of one vendor directly.  He suggested that the CEO have his team come visit ASAP.

Scene III The Solution: 

Within weeks, the CRO directed the IT team to use that product as it clearly would allow the risk analysts to author and maintain the rules.   He personally learned how to write rules, pretty quickly. The IT team breathed a sigh as it appeared they would be spared “harvesting” the XL “rules.” (see the PS foot note below). They also knew there were other essential components of the new system that required their passionate competencies, hard coded or not. There is no suggestion of a ‘silver bullet” here. but the SI had in effect been suggesting a propagation of the custom, hard coded logic problem, be it Cobol code or XL formulas. A spirited project (in a good way, the risk analysts were excited by light at the end of the tunnel) kicked off.  The CEO of the BRMS vendor had been asked by the CRO to provide personal some oversight to the project that include best practices guidance by his ROAD (Rules Oriented Architecture and Application Design/Development/Deployment) crew, in Agile/Sprint efforts.

Scene IV The Big Resistance:

There was an “uh oh” moment in one SPRINT review meeting pretty late in the effort. A very senior (being “PC” here) risk analyst exec who actually like the old system asked – “this new system really looks great but can I still use my XL files.” There were sighs, OMGs and a few fists formed under the table. The CEO’s response was a diplomatic but emphatic “FRIENDS DON’T LET FRIENDS HARD CODE LOGIC.”  The CRO added “AMEN, Let’s Git-R-Done!”

So when it was almost “go live” time, we return to the source code control get together/mandate (you know the difference between process bigots and terrorist? – you can negotiate with a terrorist).  The CRO got wind of the challenge and joined the discussion.  His “mandate”? “If you folks can harvest the XL formulas that I am sure you also treated as source code and migrate them to a new format in PVCS that my risk management team can maintain then your policy will be followed. Can you do that? And oh by the way, we need to go live next week.” Case closed.

Scene V The Bottom Line:

One week after the deployment, the CRO got a FedEx package – a baseball t shirt that said

On the front and on the back "Friends Don't Let Friends Hard CodeHe wears it often and “walks the talk.”and new habits are forming at this bank and it's all good !!!

PS Footnote

There was another challenge that went largely unaddressed here, due to the complexity and non-transparency of the logic written in XL. It would have been close to magic if that logic could have been harvested and somehow migrated to or at least leveraged by a COTS BRMS.  Visit here soon for some thought leadership if not a a viable approach to Rule Harvesting and Migration

Thursday, September 17, 2015

Executive Insights Delights the Audiences

As a new track at the IT/Dev Connections conference, the Executive Insights track, designed and run by Aragon Research, created a strategic path for the developer dominated conference. There were 1000+ participants at the IT/Dev that traditionally have had access to unvarnished and detailed development content, but little strategic content. Executive Insights drew from both the Aragon customer base and the traditional IT/Dev participants. This seems a good marriage based on my experience in this inaugural combination. The theme for the track was the challenge of the digital transformation, which many organizations are facing.  Below were some of the highlights of the conference for me.

The keynote featured Roy Firestone who drew parallels between the sports world and life itself with a technology twist. Roy is more than an interviewer and proved it with his singing and dialog impersonations that kept the audience on the edge of their seat for 40 minutes. He was truly inspirational. Roy then interviewed Debby Landers the general manager of Kenexa and Smarter Workforce for IBM, where the discussion revolved around the transformations that are on deck for us as we move into the cognitive computing era.

The Detailed Agenda had rich content for organizations facing "big change" challenges. Respected speakers were chosen to give each topic the respect it deserved. Jim Lundy deserves kudos for is content and selection of  presenters for this rich track.

Since I was too busy presenting through out the duration, my highlight was a full room working through the implications of the Internet of Things (IOT) where I presented the implications to the designs of processes, applications and systems with real live examples that ranged from shop floor healthcare, retail and smart logistics.

The track completed with a panel on the next generation CIO where Jim Lundy interviewed two accomplished CIOs with strong future visions for their respective organizations. Sheila Jordan of Symantec and Rob McGillen of Grant Thorton shared their past and current challenges and how they solved them. More importantly they shared where digital was taking their respective organizations.

Net; Net:

The Executive Insights Track at IT/Dev Connections was a great success and promised to get better and draw more of the technically inclined crowd. Now Aragon has a great experience for their customer base. I was privileged to participate

Monday, September 14, 2015

Art Projects for 3Q Quarter 2015

I picked up the paint brushes again and did some fun projects as well as some new digital compositions. I hope you enjoy these pieces :)  It was exciting for as one of my pieces was shown in the Lourve. I should be so lucky again with one of these pieces. Pardon the handheld pictures of the paintings. I have yet to scan them.

2Q 2015 Art

Web Presence:  &


Ice Cave




Light Night Silhouette


For more of my art see my website:  for traditional paintings  for digital art

Tuesday, September 8, 2015

Rules for Legacy Modernization and Entry to New Markets

As the economy has improved and competitive pressures highlight antiquated systems along with the dramatic need to support dynamic, online customer experiences global enterprises are looking for the “right” technologies and architectures. One might almost hear Bill Maher with one of his “New Rules” bits. But the rules here are not funny. Indeed make or break to both acquire and keep customers with either modernized legacy systems and or new platforms for doing business. Case study written by Paul Hessinger of InRule Technology. 


This is a brief summary of how a global heath insurance company chose thinking in rulesTM and BRMS technology to do both. In a thought-full approach an innovative Proof of Concept for how CRM and BRMS along with other technologies such as Azure for cloud based delivery and operation of systems was undertaken.  Microsoft Consulting Services and BRMS “ROAD” (Rule Oriented Architecture and Application Design/Development/Deployment) experts collaborated with the company’s IT team. Simply – put it proved the concept and provided a pro forma architecture for leveraging rules to get decisive results.

British United Provident Assurance (BUPA) Ltd is based in London. It establish a compelling if not visionary program called Vision 2020. It laid out a challenging transformation agenda. It faced the penultimate requirement that a rules based approach addresses – “just say no to hard coded logic.” BUPA had legacy systems in its Bupa Health Funding (BHF) business part of its UK Market unit based in Staines, outside London that used a number legacy technologies including an old BRMS. Changing rules in the claims adjudication and processing systems was difficult at best. Starting in early 2014, the system began a migration to a MSFT DYNAMICS CRM (with a dash of as well!) based system for sourcing data.

Legacy Results:

A BRMS that puts the logic in the hands of those who know it best, is used now to validate claims (aka filter invoices), adjudicate claims (eligibility, pay limits) and a consumer focused cost estimating.  Business personnel rewrote updated rules and the initial deployment was completed in 5 months processing 45000 claims per day. Rules allowed the ability to aggregate and pinpoint nuances in reimbursement amounts. There is an analytics benefit with more decisive decisions about how logic changes will affect future payouts to customers. By June of 2015 over 50% of the legacy rules had been modernized and migrated from the old rules to new rules with a rallying cry of both IT and the BRMS vendor “friends don’t let friends hard code logic.”

New Market Results:

Vision 2020 also called for entry into new markets. Under the direction of a senior global IT exec who also carried a title of Business Transformation Director a partnership with the largest bank in Hong Kong was established. Rule authors in London adjusted core rules for pricing, quoting and onboarding that allowed for an Azure, Dynamics CRM OnlIne and BRMS portal to cross sell health insurance in the banks retail branches when a customer wanted to open credit card account. The original POC was leveraged as the design starting point The system went live in less than 6 months and dramatically accelerated the time in which a new customer was set up with the bank’s credit card business and healthcare insurance from Bupa.

And then that system allowed Bupa’s first entry into a massive market – China. The bank partnership was extended. Rules were again quickly adapted to the Chinese market and the system is going live as these words are typed.

Bupa has established the BRMS as its global technology component when modernized or new systems will benefit from “new rules”/thinking in rules.  Another project is underway in the Kingdom of Saudia Arabia and Bupa Australia built its own comprehensive POC that was done in 3 weeks (using better approach to rules majority of POC claims where within 10 cents of expected coverage and rules had queries embedded that were able to execute directly with SQL Server for faster performance) as it now begins a legacy modernization project with far reaching implications for its realization of Vision 2020

Net; Net:

Proof that thinking in rules can rule as you consider legacy modernization  or entering new markets with systems that have dynamics if not complex logic that is best handled by subject matter experts.

Thinking in rules is a register trade mark of InRule Technology, Inc.

Additional Reading: 

 Information About InRule:

Tuesday, September 1, 2015

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.

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

Information About InRule: