James Taylor's Decision Management

James Taylor

Live from Brainstorm - The vision for Business Rules

user-pic
Vote 0 Votes

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next session was Barbara von Halle (who occasionally blogs on my other blog) on The Vision for BRS: What You Need to Know In 2006

Barb starts by pointing out that rules can be developed, even though nothing has been defined by asking about baseball. She points out that a phrase like "3 strikes and your out" implies all sorts of things like what a "strike" is, who this rules applies to etc etc. She then walks through the example to show how you harvest rules e.g. all the rules for a batter being out, and that although baseball has a very complete and consistent rules most businesses will have contradictions and omissions. The end of the process should be a complete understanding of how the business operates.She goes on to talk about a recent KPI study that found 5 motivations for business rules:

  • Agility (see the blog section on business agility)
  • Knowledge Retention
  • Compliance (see the section on compliance)
  • Consistent Decisions
  • (After the fact) A stronger Business-IT partnership

and four approaches to using business rules which she illustrated with some great examples.

  • Business rules harvesting and then input to the SDLC. Often by mapping use cases to business rules as described here
  • Business rules harvesting and then input them into a Business Rules Management System
    A case study for the first two of these found that some 70% of the rules were "wrong" - the code ran wrong and was worked around, the code did what was intended but there was a mistake.
  • Business rules harvesting from legacy systems for legacy modernization (see this section on legacy modernization)
    She noted here that thousands of rules found in the code for one client mapped to just 150 "real" business rules and that legacy mining is really only a good idea when there is no alternative!
  • Business rules harvesting and business transformation by changing just manual processes or by telling IT to make changes
    Can be done very fast to show the value of focusing on rules. The case study for this showed that this worked and helped generate interest in business rules management.

Interestingly some of these involve business and IT and some only require the business. Barb wrapped up this section talking about the Rule Maturity Model and how most companies working towards Agility (level 2) and Consistency (level 3) which require both a focus on business rules and some technology. She also emphasized that rule management can fail on the business side (not the right rules) or technical side (not working right.

Barb has a model of some 10 types of business rules tools. Personally I think this is a little extreme - I would not separate authoring, analysis, testing and execution into 4 tools as I think these are all tightly coupled parts of a real Business Rules Management System. I do think that having a way to manage strategy and map it to rules and a way to map rules back into the requirements process is useful. Rule Mining is clearly a separate tool, as are analytic tools for deriving rules. I might say then that there are four:

  • Business rules management system with authoring and repository
  • Strategy and process management tool
  • Rule Mining tools (code and data mining)
  • Rules as requirements management tool

Barb went on to talk a little about how decisions, and rules, can and should be mapped to multiple processes and use cases to emphasize the importance of traceability.

Technorati Tags: , , , , , ,

 

1 TrackBack

Ian pointed me to this today: Intelligent Enterprise Magazine: Seven Trends for 2007. Doug, David and Penny from Intelligent Enterprise, with some help, came up with a nice list and it prompted me to cross-reference it with EDM: Capture Expertise... Read More

2 Comments

When I published "Business Rules the Missing Link" and its companion articles in Datamation Magazine in 1984 and coined the term "Business Rules," I was sending a message to business folks - not to IT. The "missing link" which I discussed in the first article is the link between organizational behavior and the "cognitive enterprise model" created by management. (It has little to do with IT.) In the article, I called that cognitive enterprise model an "ontology" and took much abuse from the IT world for using such an abstruse word. (Remember, this was 1984. Now onotolgies are in.) In the article, I said that enterprise ontologies are comprised of business rules, which, in turn, are propositions expressed in first order predicate calculus the subjects and objects of which are derived by means of data models. I also made the point that all business rules within an ontology must be consistent, else no rule is useful. Over the ensuing 20 years, the term business rules has been perverted and distanced from the folks who make them. Business rules have been coopted by IT and corrupted into sort of a "business-friendly" synonym for metadata.

In the 1980'S - and still today in most cases - the economic rational for IT systems was to "control" orgnizational behavior. However, businesses that wanted to be agile and responsive to dynamic market demands - and that means every business - do not really want their behavior "controlled" by IT systems, particularly if the cost and time to change them is prohibitive. Business folks truly want opportunistic behavior to be "enabled" and even "encouraged" by IT systems. In the current vernacular, they want to be agile or adaptive or flexible, or whatever. This presents an interesting dilemma for IT given that historically IT has been an inhibitor to process change. To the constant befuddlement of IT, the message from businesses is that hence forth their processes will be in constant flux. There emerges a paradox for IT. If the IT business case is based on the premise that IT systems are intended to congeal business processes and improve overall peformance by doing so, how can IT be successful if has to continually change those systems? It is already the case that all of IT's money gets sucked up in musseling around an application legacy that is coming dangerously close to costing more than the value it produces. This paradox raises its head again and again in the following IT mantra: "Why do those **##@?> users keep changing their %$#@&&^* requirements?!Don't they know what they are about?" The new answer, of course is SOA - but, hey, SOA is really an expensive solution to a problem IT created all by itself.

Some folks believe that organizational behavior is controlled by these business processes IT is so "business processes," and strive to cast them into stone using IT as the mortar. They believe to their very core that business processes are ends in themselves. But, the reality is that processes are merely a reflection of their underlying reality - rules. Change the rules, and the processes will follow. A thought from Robert Frost, augmented by me: "We dance in a circle and suppose, while the secret sits in the middle and knows. It's the rules, Stupid!"

Most of today's IT "business rules experts" work on maturity models, promulgate different types of "BR tools" - mostly for IT folks - and make pithy promises for business rules with sound bites like: increase agility, legacy modernization, knowledge retention, learning organization, predictive infrastructure, etc.. But, they continue to miss the real point about business rules: business rules are the natural language of management, the language in which it expresses, inculcates and adjusts business models. When management mixes its rules with human, material, and financial ingredients, the resultant brew is "an enterprise." That enterprise has been "purposefully designed" to play by its own rules. Its very survival and growth are a direct functions of the quality of its business rules. Management's role is to mix a brew and test it in the market place. By observing negative market feedback, management can determine which rules to change. The rest follows.

My point is that what the phrase "business rules" means is intuitively obvious to non-IT folks - even my wife gets it. But, by mincing around with the term, IT gurus turn off the very people who create and use business rules. I understand that these gurus are trying to show IT folks how to figure out what businesses are all about: "The truth of business lies in the business rules hidden in the secret recesses of application metadata. We see you." Baloney.

These gurus should leave business rules alone and content themselves with SOA and solving metadata problems - problems that IT has created for itself. Leave business rule problems to those who create them. No one knows what metadata means anyway so there is plenty of room for their intellectual sporting events - like this BPM/SOA/Rules show.

On Barbara's 10-type tool model: thinking about it, there is no reason why one SHOULD have the entire business rule lifecycle covered in 1 tool - of course you can (eg Blaze Advisor), but equally you can have components (eg LibRT for analysis). It is the same in the other s/w markets: both componentised and all-in-one solutions exist for the aspects of design / development / analysis & test / deploy (for example, the Java market).

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links

Fico

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives

    Blogs

    ADVERTISEMENT