Business Rules! or is that Business Rules...

Gartner BPM Conference - Day 2: Marc Kerremans Presentation on Business Rules Management - State of the Art

I'm often critical of industry analysts, often because they are not practitioners (or at least have not been in years).  Marc does not fit this mold and comes to the table with strong real-world experience.  His presentation was spot on from this authors perspective.  He discussed the use, need and value of business rules.  His best quote summarizing his recommendation was "if you don't have a rules strategy - get one".

 

Notes from Marc's Presentation

Rules are a start, but Agility requires a Business Rules Management Strategy.  But still business rules remain a second class citizen.  And this is a problem.  Like an ingredient in a stew, it is difficult to effect that ingredient without changing the whole stew.  When rules are buried within BPM and applications, you can not effect the rules appropriately.  Key message - you must externalize rules.

Rules should be externalized and you need a different rules layer.

Topics..

1. What is BRM and who is responsible
2. How does BRM add value
3. How can BRM can transform Enterprise Decision Making
4. How to get started.

Where are your rules: In your applications, in your business intelligence, with integration tools, in governance systems, with business process and sometimes within BPMS (as in work management or routing).  These should all be centralized within a BRMS.

What is a rule: Implicit and explicit business policies that define and describe a business action.  This is the Gartner definition.  Marc also presented other definitions by Ron Ross and from Wikipedia.

What is Business Rules Management: a structured discipline guiding business rule definition, categorization, governance, deployment and use though the enterprise lifecycle.

Marc went to the next level to discuss that rules vary.  Example: work week hours differ by region.  So you need a rules taxonomy.  Best practices suggests you need an enterprise BR strategy, but with BR, one size does not fit all. 

Who owns and manages business rules? 

• LOB Manager - determines which rules are volatile, define those rules and can author/change the business rules
  • Mark indicated they have evidence that rules can save 60-80% over other maintenance methods.
• IT - Manage/author complex rules, test rules to assure system health, administer/maintain systems
• Business Analyst - Monitor business health, discover/author rules, create/simulate rule scenarios.

Authors Note: I disagree with Marc that IT must author complex rules.  I believe this would represent a failure in the authoring tools if complex rules CAN ONLY be authored by IT.  It is great if IT chooses to do this work, but assuming they must do this represents a failure in easy to use and declarative rule authoring.

What is a Business Rules Management System (BRMS) and How Does it Add Value

In the last few years the Business Rules Engine market was evolving to the Business Rules Management Systems.

Key Components

• Rule Repository: Enterprise rules database where rules are stored and called for design-time and run-time use.
• Rules Modeling and Simulation: Graphical rule simulation tools to conduct what-if analysis and to analyze rule firing behavior.
• Rules Monitoring and Analysis: Historical and run time rule usage reporting and analytic tools.
• Rules Management and Administration: Facilitates to deploy rules to target environment, manage security, promote new rule sets, and track system modification and performance.
• Rules Templates: Out of the box, pre-built rule sets to accelerate customers time to value.  Vertical, Horizontal, and Industry standards templates.
• Rules IDE: Graphical model-driven development environment to author, sequence, test and debug rules.
• Rules Execution Engine: State and event based engine that executes and manages how rules get called in a proper and efficient manner.

Marc indicated that customer should not  expect one vendor to be stellar in all categories.

Marc showed a chart of rules vendors cut into Open Source BRE, BRE and BRMS with some small overlap from BPMS.  Comment from Marc on BPMS that most vendors can only deal with simple rules.

Marc provided a great chart on Agility.  He identified 4 key elements and showed the incredible alignment of business rules

• Awareness - Knowing what's going on (Data and Event Monitoring)
• Flexibility - Confronting expected change (Rules Modeling and Simulation)
• Adaptability  Confronting unexpected change - (Rapid rule modification)
• Productivity - Executing well day-to-day - (Automation)

Other reasons beyond Agility...

• Decision making, revenue opportunities, customer satisfaction, regulatory compliance, governance (authors note: interestingly Marc didn't talk about tremendous opportunity to cut both operational and IT costs).

Marc discussed some best practices to consider...

• Conduct Volatility Analysis
• Establish roles
• business ownership and IT support agreement
• Express rules in clear structure business language
• Provide tools for business people to manage rules
• Establish a process on how to implement change
• Acquire BRMS that aligns well to your needs
• Select a rules representation format that fits your needs.

Marc then provided some patterns for Business Rules solutions

• BPMS  - Limited capabilities, simple rules, etc.
• Inference-based BRE - Moving beyond procedural scripting to using an algorithm to deal with rule firing order and dependency management.
• Event Based BRE - Event Listeners and fire based on events or correlating events.

Recommendations

• if you don't have a strategy - get one.
• determine the right rules/decision to externalize
• determine the downstream effects on rule change
• assign rule stewardship
• build a single rule strategy, but don't focus on a single vendor
• select a BRMS, but start small and go after "'low hanging fruit"

Gartner Prediction: Due to complimentary synergies between BPM and BRM Gartner believes there will be convergence.  That was a nice way of saying Gartner believes that over time some set of the rules vendors will merge with BPM vendors.

Gartner BPM Session: Governing End-User Development

A research track dating back to the 90's looking at end-user development.  A 'situation' born from end-user frustration with IT backlog and lack of agility.  Much of this was IT or near-IT roles hired within the business unit.  Basically technology savvy people.

This trend is not slowing and with new tools that are model driven, drag-and-drop, etc., is in fact increasing.  This is about enabling safely and creating a bridge between business and IT.

Drivers

• Frustration with agility, Cost, Time for results from IT
• Increasing sophisticated business users
• Availability of tools to automated but without classic programming

Key issue with end-user development.  End-user don't understand or focus on key ideas like

• Security
• Data Access protection
• Service Levels
• Architecture

Matt broke this type of development into two streams.  One being opportunistic (short term, limited scope) and Systemic (strategic long living, high impact). 

Key changes from Functionally Driven to Process Driven (this is the bridge to end user development)

• Most observation were very soft (roles are functional, moving to roles are process centric or Hand-offs are implicit to hand-offs are explicit),
• Only one was hard.  Business rule changes rely on the IT department to schedule changes to application code - moving to - Business rule and process steps are changes by business process owners.

Key observations - when should end-user development be enabled by IT

• Service level characteristics - EG if the system goes down you lose revenue
• What does it do - what does it access - Security, privacy, data protection, etc.  If the application presses on these topics - MUST be done by IT.  COMMENT: Matt's discussion is almost End User Developed VERSUS IT Developed.  I think this fails to talk about how IT should enable End User Developed applications which create protections from these issues.

Matt then talked about end-user developed applications and really framed these an small internal department focused projects.  He then moved to how BPM shifts from these silos to jointly owned Business-IT projects.  He started by talking about BPM based 'opportunistic' projects and then moved into a discussion on 'systematic' projects.  Here he offered a few ideas on key issues (again) like service levels, compliance to architecture, etc.   In fact my observation was an IT centric viewpoint on the issues that need to be addressed to get IT involved. 

I'm awaiting the next slide, but Matt hasn't discussed what tremendous benefits come from coordinated business/IT project in which each as a role to play and how that justifies supporting these critical initiatives.

That last slide never came....

Authors Note: See Sandy - Real time post!

Gartner BPM Conference - Opening Keynote Observations

Tuesday morning, 2/5 was the official kick-off for the Gartner BPM Conference.  I'm sitting here as a Business Rules vendor, checking out how Gartner views operational decisions within business process (and the business rules that model/describe those decisions).

Observation from Gartner: BPM is in the top three of the CIO's agenda.  Key question: Is this BPM as a conceptual methodology for understanding, measuring and optimizing how work moves through the organization, or is BPM a technology to automate business process?

Keynote by Janelle Hill

Summary NOTE: As a Business Rules vendor, I didn't like Janelle's failure to discuss operational decisions within process.  Understanding and optimizing how work moves is critical, but BPM moves work between operational decisions (up to 70% of the process activities).  But taking a step back as a business manager for over 25 years I believe Janelle's presentation was probably at the right level to help organization move into a sophisticated shift in how business is organized and implemented.

JH discussed 5 Stage BP Maturity Model - Poster Available, Diagnostic tools which assesses an organization maturity.  Key Question: How does Gartner deal with operational decision understanding and maturity.  I'll look into that.

Key points from JH Keynote;

• Processes are a key component of how an organization delivers value to customers and partners.  Again, what is the definition of process?
• Started by indicating that process improvement has been a topic since the 20's.  Lot's of different handles - TQM, BPR.  Meta elements are Scientific mgmt, computer automation, best practices through packages applications, to Flexible and Adaptive process.
• In economic slowdown, process improvement is still a critical element in cutting costs today and preparing for the upturn later.
• Janelle does separate BPM as a management discipline from as a technology foundation.  Her presentation followed these two different ideas. 
• JH observed that software is being seen as an inhibitors of process and business agility.  I thought I heard JH indicate this is a recent observation from industry.  My personal experience is that this has been a trend since I started in MIS way back when. 
• Organizations are starting to move from intact processes within an organization to cross-boundary process management.  Cross function and even cross companies (process networks).   I find this to be an interesting observation.  I'm interested in knowing how nascent or broad based this is in industry.  I'd assume pretty nascent.
• Moving to a knowledge based economy and the focus on people are moving center stage in the coordination of process.
• People Empowerment moves center stage - Process of Me, Process of We.
• The benefits of BPM compound over time.  The first benefit wave is around Productivity and Efficiency, the second wave is about Visibility (end to end perspective on contribution, costs, bottlenecks, etc.), and finally Innovation (based on visibility, opens opportunities to change and innovate).
  • Interesting observation on visibility - a Canadian insurance organization, once they had visibility realized that 70% of the data the collected as a part of the claims process was never used.
• Why Technology Matters...
  • Make process explicit - free it from underlying technology
  • Enable business driven change.  NOTE: JH discusses this in broad terms with clear focus on the process workflow changes (execution flow).  Our observations is that execution flow does not change as often as decisions (Business Rules) within the process.
  • Visibility - Get immediate feedback in context of process
  • Process + KPI forms the foundation for information based improvement
• BPM stack (UI, Workflow, Middleware, Rules, Data).
  • BPM suite vendors - Relatively new players focused on this stack.
  • Middleware Vendors - Particularly integration focused (TIBCO, etc.)
  • Application Vendors - Building this stack into their applications
• JH showed a very busy map of players coming at this problem from different angles.  Corticon showed up along side of ILOG and Fair Isaac as the key players in the Business Rules Management Suite space.  
• Gartner continues to position business rules as a component of BPM.  Another blog here - I believe this is wrong.  Operational decisions are not Context, they are CORE!
• KEY POINT: BPM is facilitated by technology, but is much more about the organization.  Enlighten, Organize and Train, Recruit, etc.
• Key Organization Shift - Movement from a functionally driven organization to a process driven organization.
• A significant number of her final recommendations were management, organization and organizational change discipline focused
  • Business: Governance framework, BP analyst to work on each major end-to-end process, BPM competency center, experience person to head this center, establish real-time management culture
  • IT: IT enables BPM, IT is not the leader.  Look for entry points to bring in BPM (e.g. corporate governance, application integration, compliance, etc.).  Prepare groundwork (SOA, BPM, Rules and Repositories)
• JH Concluded with Value of BPM
  • Cost/Efficiency
  • Time/Adaptability
  • Risk/Compliance
  • Revenue/Innovation

For another great discussion on this opening keynote, check out Sandy Kemsley's blog post

"Living in the House" or So What's in the Demo

Our VP of Sales recently reminded me of an old joke.  A guy dies and is asked if he'd prefer to go to heaven or hell.  He asks to see both.  Heaven is tranquil and beautiful place where everyone is well dressed, enjoying themselves and discussing great thoughts.  Hell, is one big party.  Music, dancing, drinks.  He chooses music, dancing and drinking.  He is then escorted to hell and it is cold and wet with people dressed in rags and looking forlorn and tortured.  He points out that this isn't what he was shown, and is told; "That was just the demo".

Now I'm in the software industry, so you could suggest that I'm not a reliable source in discussing this topic, but I believe customers need to dig a little.  To get beyond the demo and figure out what it would be like to 'live in the house'... 

From that perspective we often suggest to our prospects that they not allow the vendors they are considering to build demo's or proofs off-site (ourselves included).  I've seen prospects send us a set of rules and then ask us to demo to them at some future date.  What they get to see is the pretty house all laid out for the buyer.  What they don't get is an understanding of what it is like to live in the house. 

I strongly urge any team considering a business rules purchase to ask all vendors to come in and build out a completely tested, integrated and executing Decision Service live.  Allow the vendors to bring nothing other than their base products at the start of the day.  Give the vendors their demo or test scenario without any ability to 'prepare'.  Spend a day living through the lifecycle of using the vendors product.  From inception through the build, test, deployment and maintenance of your business rules.  A business rules management system is an important purchases, so this small investment in time is actually very cheap.  Once you have bought the house and are living in it for real, it's not so easy to change addresses.   

Why is the Business Rules Market so Focused on Rules?

20 years of behavior can lead to some bad habits.  The one that I'm discussing is the focus the business rules market has put on the rule (versus the decision).  I will dig into why, if readers are interested.  But the rule as become the focus of design, storage, management, etc.  So why do I think this is a bad habit.  Because a rule (even a few rules) is rarely the basis of a decision, and in fact decisions are the reason we are utilizing business rules solutions in the first place.  In almost all other technologies, we focus on the higher level business outcomes, not the artifact to implement that outcome.  In programming we focus on programs or functional sub-routines, not lines of code.  In business process management we focus on processes, not tasks and routes.  These are of course important.  They are the artifact to implement.  But when was the last time during a business process discussion did someone ask to have the team randomly discuss tasks that occur within the organization.  Organizations start by talking about processes, about functional programs and in reality focus the discussion on decisions (not just the rules). Business rules, like tasks in processes and lines of code in functional programs come out of the discussion of decisions to be understood and eventually automated.  So when I hear people ask about capabilities to manage a rule I ask myself, when was the last time I heard anyone talking about independently managing a line-of-code.  The result of this history is that this thinking has added far too much complexity to the task we have given our business rules customers.  Instead of thinking about discovering, modeling and automating the top 250 decisions within their organization, they worry about the 10,000 or more rules that exist to implement these decisions.  That becomes a daunting task.