• The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling
    The MicroGuide to Process and Decision Modeling in BPMN/DMN: Building More Effective Processes by Integrating Process Modeling with Decision Modeling

The Rules Revolution

My friends and associates at KPI have made their recent book "The Rules Revolution" available on Amazon. And I must reccomend all those interested in BPM, Business Rules and Enterprise Architecture purchase, read and reread this book:

The Rules Revolution

Business Rules is a grass-roots movement that has little support from the BSchool community. Yet, it seems that effective it should be critical to a modern approach to business. At the beginning of the book Barbra and Larry state:

"Business rules are an under valued asset at most organizations today." ... " may hold the key to organizational agility, consistency and organizational knowledge"

With out a grand digression into the history of business rules, the books authors have arrived at these conclusions from the view point of practice. The organizations they serve have experienced such pain in creating reasonable change that they are willing to look beyond stale management practices.

You do not need to look far to find this in the literature. My friend, Art Tortolero, from Sungard recommended this book, a product of MIT research:

I have been reading this text carefully and I have many comments. It is well written and the language is clear. The premise of Enterprise Architecture as Strategy is that companies should develop a 'foundation for execution'. Next they should select an operating model for the levels of Process Standardization and Process Integration.

Early in the book (page 5) the authors list some of the characteristics of a company that has an Enterprise Architecture that is weak and did not support strategy:

"Different parts of our company give different answers to the same customer questions..." I guess these parts do not know where the policy or constraint is, or where to find a policy to answer the customers question.

"Meeting a new regulatory or reporting requirement is a major effort for us..." Where are the old policies? Again, here emerges a strong argument for business rules.

"Our business lacks agility-every strategic iniative is like starting from scratch" If your foundation for execution does not include agile processes, those with the characteristics implied by my earlier posts (here and here), how can your foundation for execution be expected to be agile?

There are other characteristics and each one points to the need for a rules approach in the enterprise architecture's foundation for execution. Certainly, business rules is not the only factor. Business process is also critical, yet Ross, Weill and Robertson have not touched on this critical topic.

On page 28 the authors state:

"The biggest challenge of integration is usually around data. End-to end integration requires companies to develop standard data definitions and formats for data that will be shared across business units or functions."

To me, this is naive. Take for instance the customer discount in a sales transaction. A simple database table with the discount column does not reveal the manner in which the discount was applied. Without business rules integration, systems integration is a delusion.

Businesses operate through Business Processes. Policies control business processes. Period. Unless the foundation for execution defines the roles of business rules in the enterprise architecture, it is unlikely that organization will achieve business agility. Your management will not have a process for articulating and changing critical elements of the business. Technology will bury business rules, either in Java Code within legacy business process tools, or in code such as in PL/SQL in the database.

Agile Links

Agility is still a pooly defined term, perhaps it is something you 'know when you see it'.

I would like to think that agility can be classified in to one of the 17 types and that if you can identifiy the type of agility you need then you can identify the way to achieve it. Processes that incorporate agility types are agile processes.

I will use this posting to collect links. There is some very interesting stuff out there:

William Dunk, Incorporated is a management consulting firm and an investor relations counselor. They have a list of agile companies here. The criteria for getting on this list seems vague, like the term agility, but there is some good stuff there.

J. Sifri, another C-Level consultant in the banking has a good post on high performance companies. It is here:

Of course there is the CIO agile 100 List which is published here.  But I am uncertain the list define agile companies, rather it lists some 'agile' things that companies did with IT technology.

New York, a great town and a great meeting

Times Square in the Rain

On November, 7 and 8, the BPMinstitue held their last conference of the year.
By any measure, it was a success. Hats off to: Greg Rock and all the hardworking organizers of the meeting. They have created a great place for everyone to gather, speak, listen and learn about Business Process Management, Business Rules and the service oriented architecture.

I want to thank all of these folks plus my good friends, Barbra von Halle and Larry Goldberg of KPI, plus James Taylor of Fair Isaac (see I spelled it correctly, James), Jacques-Alexandre Gerber, of Intalio for taking an interest in my book and my thoughts on these topics. I have been deep into an integration project for the past month and I have been neglecting my blog. I have several thoughts on the conference and my training session.

On the training and the conference…

On Thursday I gave my one day training on Business Process Management with a Business Rules Approach. The students were extremely bright and attentive and I think I ended learning as much as they did. The topic that resonated best was my discussions on the four c’s.

The four C’s are the basic components of a business rules implementation, from the perspective of business process management. Here implementation is distinguished from requirements definition; it occurs after the rule is defined in something like KPI-Step. The 4 C’s are:

  • Categorize, sort out the flavor, class, or type of entity of the rule

  • Compute, derive, calculate, or look-up the data needed to set up the rule

  • Compare, the values of the computed data against thresholds, redline or ordinal values

  • Control, develop a decision to control the flow of a business process.

An example is useful. Consider the business rule ‘Deny requisition from direct delivery contracts when the period of performance ends within 15 days of the order date.’ (This is a rule from a project.)

Categorize: Identify the contract is a direct delivery type
Compute: look up the date for the end of the period of performance for the contract
Compare: Compare the difference between the requisition data and end of the period of performance with the redline value of 15 days
Control: return the Deny message to the calling process, if the threshold condition is reached.


Latest Article

My latest article with the BPMInstitute is published here.

I discuss Wil van der Aalst's work and relate it to BPML. Wil has written several books on this topic, while they are advanced reading. BPM Practitioners should have Wil's work in their library. I suggest the title here.

In addition to Wil van ser Aalst's work on work flow, in June, he also was lead author of an important  work on the  round-trip between BPML and BPEL. The work is published here. The formal methods mathematics will be beyond most readers; however, you can glean the difficulty of the problem of translating a graph-oriented language (BPML) into a block-style programming language (BPEL). The bottom line is that any BPM tools is not only tricky to build, it is tricky to learn. Let us hope that research like this will simplify the modeling of business processes.

BPM versus SOA (There is one)

At a recent meeting, I listened to a proponent of SOA tell war stories about the complexities of coordinating transactions among various systems. I presume he was referring to the challenges of coordinating the state and consistency of multiple systems. I think this touches the larger solution that BPMN is trying to solve.

A compensation is a path in a business process that restores one or more systems to a state before the transaction. For instance in the diagram below, if the calls to systems one or two cause a business exception or a calling system exception, then the activity 'Align Systems 1 & 2' will be raised. The compensation is shown as two arrows enclosed in a circle. The activity that is connected to the circle performs the complesation. The beauty of the BPML-BPEL solution is that this coordination comes at no the developer.

A pure-play SOA approach might recommend developing compensations as another service. Because each service must accommodate a series of local updates across isolated systems, transaction can be very challenging in a SOA environment. Technical and business errors can occur and fault conditions can arise. The SOA developer must design and code programs that undo the partial work.


This approach seems shaky to me, I would rather depend on a BPEL engine like Pixi or Colaxa. In my view, PI-Calculus approaches to distributed, mobile processes offers a technically superior way to create long-running transactions. A transactional capability is inherent in the BPEL 2.0 spec. Because of this native capability of the BPEL engine, developers need not design and code these characteristics into their SOA environment.

While at the same conference an attendee asked me about my favorite programming language. After my standard answer (FORTRAN, I am a child of the 70's), I said 'no programming language'. I think we should be able to build system with a little SQL, XML and perhaps XPATH. I wonder what complex measures SOA developers are taking to develop the compensation style that is needed to set up the processes described in the diagram.