Monday, September 28, 2015

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

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.

Monday, September 21, 2015

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 job – we 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 Code"

He 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

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

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.

Tuesday, September 8, 2015

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.

Overview:

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 salesform.com 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.

Tuesday, September 1, 2015

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 –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