Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Business Rules and Expert Systems/AI … Friends or Foes?

There are very important differences in the traditions of business rules vs. expert systems. Perhaps that’s why business rules had a completely different origin. In any case, they didn’t start finding each other until the late 1990s. (The first Business Rules Forum Conference was in 1997 … and every year since except in 2000.) The general goal of expert systems was broadly to mimic intelligent behavior – any kind of intelligent behavior. As a colleague put it, that’s like trying to read the mind of God. Human behavior (even the not-so-intelligent kind) is exceeding complex. The goal of business rules was always to capture the rules of organizations, not individuals. That’s one or two or more orders of magnitude easier – those rules have to come from somewhere … and that ‘somewhere’ was originally knowable (even if an arbitrary design decision by some programmer). So the issue with business rules is as much about business traceability (rule management) as it is expression. This problem goes right to the very heart of business governance and business agility. Continuing to embed business rules in procedural code (a) makes the business rules very difficult to trace, and (b) very difficult and expensive to change. It’s like setting the rules in concrete. It also precludes the possibility in the future of supporting specification-time detection of anomalies and intelligent dialogs to help Business Analysts remove ambiguity. For business rules, it ultimately comes down to the words you use and ‘remembering’ the interpretations made of them. There’s no way to demonstrate compliance without words, and no way to support transparency and accountability without traceability. The solution to all these problems, which are problems of business governance and therefore business engineering, leads inevitably in one direction. That’s why I’ve put so much time into researching business rules since the early 1990s and before. (Originally we thought in terms of databases and integrity constraints, another difference in origin from expert systems.) It’s also why I’ve spent so much time on the SBVR standard over the past 6 years or more. (At the risk of oversimplifying hugely, SBVR is about words and sentences.) The bottom-line: The way we do things today simply has to change. Change does take time. It also takes false starts and trial-and-error. But we’ll get there. Hey, business automation is barely one human generation old. That’s incredibly fast in the big scheme of things. ~~~~~~~~~~~~~~~  Read more about the history of business rules: http://www.brcommunity.com/history.php    

Continue Reading

The Traffic in India: No Rules … or Something Else? And is It Safer?!

If you’ve never been to India or Latin America, take a look at the following short video. Is what you’re seeing the absence of rules … or something else? http://www.evolvingexcellence.com/blog/2011/11/control-or-chaos.html In my travels in Latin America, I long ago perceived that there are two fundamental kinds of driving and traffic: 1. Obedient. In this style, drivers usually follow the official rules, or some approximation thereof. Accidents occur when road conditions are bad, drivers aren’t paying attention, or somebody thinks the rules don’t apply to them (chooses to violate the rules). 2. Positional. In this style, nobody pays much attention to the official rules. Instead, a driver is generally allowed to proceed in the direction he/she wants if the driver’s vehicle has better physical position (or is significantly larger in size) in relation to other nearby vehicles. Accidents occur when road conditions are bad, or drivers aren’t paying attention. Why aren’t there continuous accidents in the positional style of driving? It’s not because there are no rules. There are – the rules of ‘position’. You’re not really looking at anarchy or chaos – i.e., the absence of rules. If you were, everyone you see would be running into everyone else all the time. A good analogy is a flock of birds or school of fish. How do they all suddenly seem to turn in the same direction? The rules of position. Each bird or fish must always maintain its distance from his neighbors. Is the positional style of driving/traffic safer than the obedient style? Theoretically, I suppose you could argue it is. All drivers know the rules of position apply to them and that the sanction for violating those rules can be immediate and injurious. In practice, I wouldn’t bet on it. Flocking birds and schooling fish are probably equipped genetically for positional maneuvering. They’re been at it for millions of years. Humans have been driving for what – maybe a 100?! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Acks to Roger Tregear, Leonardo Consulting, Australiawho sent me a link to the video post.

Continue Reading 1 Comment

How Business Rules, Decisions, and Events Relate in True-to-Life Business Models

What is operational business know-how? How can you model it? What results can you achieve by doing so? The answers lie with creating true-to-life business models based on behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. Find out what ideas and techniques you need to create know-how models: http://www.brcommunity.com/b623.php

Continue Reading 1 Comment

Business Analysis with Business Rules: See the Elephant! at Business Rules Forum conference @BBCapability Nov 2 Ft Lauderdale

Business Rule Forum Keynote – Wednesday, November 2, 2011 – 9:00 AM I am giving a keynote next week called Business Analysis with Business Rules: See the Elephant! at the Building Business Capability (BBC2011) event in Florida (Nov 2, 9am Eastern). If you’re there, I hope you’ll come. If not, our new book, Building Business Solutions: Business Analysis with Business Rules explains the ‘elephant’ part in the Preface. See http://www.brsolutions.com/b_building_business_solutions.php. Here are some clues … Why doesn’t every organization in the world do business rules? Doesn’t every organization have them? A great many of the ideas and tools have been around for years, all tried-and-proven. What’s the problem? It’s not that there aren’t successes – there are, lots of them. It’s not that successful techniques haven’t been written up and talked about for years – they have. You could argue that many people who think they understand business rules, actually don’t. There’s some truth to that – but consensus among experts has existed for years. The real reason is simply that the problem is so pervasive. It’s everywhere, like air, making it hard to see. Exciting things happen though once you stand back and take a look at the big picture.
  • Engineering highly dynamic, definitively aligned business solutions
  • Order-of-magnitude improvements in business capabilities
  • The pathway from gridlock to business agility
  • Not just requirements development by another name
  • The process for business rules – and a fresh look at governance

Continue Reading

The Debate Continues … Business Rules in Zachman 3.0 … and the Upcoming Business Architecture Summit at BBC2011

At the Business Architecture Summit in Ft. Lauderdale (BBC2011 – Oct 31 – Nov 4) I will be joining John Zachman and Roger Burlton for one of our rabble-raising 3Amigo sessions. The session is only an hour long, so I’m sure there will be some fast talking(!). One of the first questions I want John to address is: “Where are the business rules in Zachman 3.0?” The following recent exchange represents my current understanding on the matter. I plan to come back on the record after the event to say what I got right and what I got wrong. Question: Can rules address more than one primitive (column) in the Framework? My Answer: Yes, atomic rules can address multiple primitives – e.g., An accounting must be given by the CFO in Delaware on March 15, 2012. (By ‘atomic’ I mean ‘can’t be reduced into two or more rules without losing meaning.’) In this rule you have a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). So even atomic rules are composites, not primitives. Question: Does rules not being a primitive mean that business rules shouldn’t be treated as a first-class citizen? My Answer: What ‘first-class citizen’ has always meant in the Business Rule Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) and elsewhere is that business rules shouldn’t be subordinate to other kinds of requirements for system design in general, and to what I call ‘Big-P’ processes in particular. Big-P processes are not primitive (think ‘input-process-output’), but rather they amalgamate (think ‘mash-up’) some or even all the other primitives. In other words, Big-P processes are also composite. Composites are about the configuration of the enterprise at any point in time. Business rules are one candidate for that capacity. I believe business rules are a far better choice in that regard than Big-P processes (think ‘business agility’). In any case, business rules being a composite in no way diminishes their importance. The enterprise is not built on primitives alone. If you had only primitives, there would be no configuration, and literally no enterprise.

Continue Reading 1 Comment

Is Agile Development of Business Rules Possible? … And What Would You Call It If It Is?

I’ve been exploring the meaning of ‘agile’ with respect to business rules. In our new book, we say:

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to.”

In response, a practitioner made the following deeply insightful observation about agile development of business rules.

Practitioner: “My perception of the intent of agile software development is to try to have the underlying development process track better to the realities of the business process change. Rather than the good old days where the specification and implementation of the solution ran so long that the problem trying to be solved had changed so much that the delivered solution was irrelevant.  So, if you reach a point where ‘The only constraint is how long it takes business leads and Business Analysts to think through the change’, then, to me, you are already doing agile development.”

Just to clarify: Our underlying assumption is that business policy and business rules can be and should be specified and analyzed independently of traditional software requirements (i.e., functional and non-functional requirements). That’s rule independence as the Business Rules Manifesto calls it. Business rules can and should have an independent life cycle. Then yes, there could be two kinds of ‘agile development’. Agile development of business rules and agile development of software. (I’ll leave it to others to decide whether agile development of requirements makes sense.) But here’s the rub: If you did reach the point where ‘the only constraint is how long it takes business leads and Business Analysts to think through the change’ in business rules – and I do believe that’s possible – business managers almost certainly wouldn’t (and shouldn’t) call it ‘agile development’. That’s an IT buzzword. When you talk about development of business policy and business rules, you are really talking about governance. Here is the Merriam-Webster Unabridged definition of “govern” …

1a: to exercise arbitrarily or by established rules continuous sovereign authority over; especially : to control and direct the making and administration of policy in

Note the prominent appearance of ‘rules’ and ‘policy’ in that definition. Hey, I didn’t make it up, it’s right there in the dictionary(!). So the bottom line is this: Instead of ‘agile development’ of business rules, at that point I’d say you’d be talking about agile governance. Indeed, I believe that’s exactly what we’re getting at here. Very exciting once you see it! ~~~~~~~~~~~~~~~ Our new book (Oct, 2011): Building Business Solutions: Business Analysis with Business Rules – See:  http://www.brsolutions.com/b_building_business_solutions.php By the way, we call the “it” in “… once you see it” an elephant. Have a look at the book to find out why.

Continue Reading 1 Comment

Scary Estimate about the Correctness of Business Rules in Legacy Systems … Are Yours Better or Worse? Do You Even Know?

A business analyst at a major insurance company recently said this: “When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong. That’s a very conservative estimate: the actual figure was probably much higher.” How does that estimate compare to yours? Have you ever done an assessment? I’d like to hear about it. The replies can be anonymous … like this one … DM me or use LinkedIn. By the way, the business analyst went on to say, “ IT told us they couldn’t solve the problem because it was a business issue not a software issue. And they were absolutely right about that.” Yes indeed they were. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Text excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading 1 Comment

Bots “Communicating” (Funny!) … What about SBVR and RuleSpeak?

If you want to hear state-of-the-art machines (bots) talk to each other, see: http://goo.gl/LEIMI Funny! Rude and petty … just like humans sometimes. I don’t think we’re quite there on Star-Trek-style communication with machines(!). If you want to see a suitable set of guidelines for writing unambiguous business rules that machines should be able to understand, see www.RuleSpeak.com (free). RuleSpeak was one of the three reference notations used in creating SBVR, the OMG standard Semantics of Business Vocabularies and Business Rules. (SBVR doesn’t standardize notation.) Don’t try to read the SBVR standard – it’s for logicians, linguists and software engineers. For insight into what SBVR is about, see the SBVR Insider section on www.BRCommunity.com. SBVR itself is a structured vocabulary – essentially a concept system. Clause 11 provides a structured vocabulary for creating structured vocabularies. Clause 12 provides vocabulary for business rules. ‘Structured’ in this context means it includes both noun concepts (nothing unusual about that) and verb concepts (highly unusual). You need verbs to write sentences (propositions). Try writing a 100 business rules without standard verbs. Well, you can do it, but what you’ll get is spaghetti logic and hopeless, bot-like(?) communication.

Continue Reading

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’

Business Process Models and Business Rules … Separate the ‘Know’ from the ‘Flow’ Conditional flows are one of the most important features of a business process model. For example, a business process model for handling claims would include multiple conditional flows – e.g., if valid claim, if claim approved, if fraud suspected, etc. A conditional flow simply means that work follows the given path only if the condition is satisfied for a given case. The secret of effective business process modeling with business rules is never embed the criteria used to evaluate a conditional in the conditional itself. Instead, just name the conditional using an adjective (e.g., valid) or past participle (e.g., approved). The criteria for evaluating conditionals should always be expressed separately as business rules. Fortunately there’s nothing particularly hard about that. Example: A claim may be considered valid only if it has an incident date. Following this best practice is how you keep a business process model simple – often by an order of magnitude or more! Frankly, most business processes aren’t nearly as complicated as people think. What’s complicated is the know-how needed to perform the business process correctly. That know-how should be represented by business rules. P.S. I first heard the phrase ‘separate the know from the flow’ from Roger Burlton on 11/30/1999. I immediately made a note because it was so memorable and on-target.  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading

Rules in the Zachman Framework … Get Ready for a Burst of Architectural Rethink

As it turns out, rules have been one of the hardest things to figure out in the Zachman Framework. From a purely selfish point of view, that’s been a good thing, because it’s given an excuse for John and I to have many long dinners over the question in places that have really, really good food. I think the emerging answer is an exciting one. Think ‘gray lines’ in 3.0. Rules turn out to be composites. As John likes to do, roll the Framework into a cylinder, then look through it like a telescope. The gray lines arching through the space inside represent the current configuration of your enterprise. Traditionally, those gray lines have been implemented by procedural means … and we know the pitfalls of rules hardcoded into application code. It’s like setting the business in concrete. I think what 3.0 really points us toward is a new vision for the composites; a highly innovative burst of rethinking about configuration based on the primitives. I’ll be having more to say about this in the near future … It’s the topic for my 15 minute 3Amigos session with John and Roger Burlton at this year’s Business Architecture Summit (Oct 31 – Nov 4, Ft. Lauderdale) … http://www.buildingbusinesscapability.com/ P.S. Try to picture John being able to say anything in 15 minutes. That will be interesting in itself!

Continue Reading

Our Clients

[cycloneslider id="our-clients"]