Navigation
  • 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
Thursday
Jan252007

The Value Proposition of BPM/Rules

Here is the value proposition of BPM/Rules from a management viewpoint. Simply put, firms that utilize the Business Process Management with a Business Rules Approach:


  1. Reduce the cost of application development.

  2. Accurately and rapidly gather processes and business rules.


Without a formal, BPM/Business Rules Approach gather rules and processes through a loose tale of data models and ‘use-cases’. The core motivation of the BPM/Business Rules approach is to move application requirement from the technical team to the business team. The outcome is that lower-cost individuals get the business rules and the get them right.

I recall a recent conversation with a group of folks, when one individual said that he did not see the value of business rules (or BPM for that matter). This person believed that a solid written specification with some PL/SQL and Data Modeling could address application development. I guess, success strictly depends on the contents of the written application. You can use the BPM/BR approach to develop a very accurate specification; however, you will loose the vast capabilities of this new technology.

One example: As I work with business rules, I am struck with the weakness of data modeling as a requirements gathering tool (Look at this example.). The objective of data modeling is to develop a 'normalized' structure that retain all the instances of an entity. In reality there might be many use-cases within a single entity, even at higly-normalized forms. I do'nt think data modelers are creating tables called: 'orders_from_perferred_customers_with_medium_credit_rating'. In data modeling we might create 'types'; however, the rules that assign these type change and data modeling provides not mechanism (other than brute-force), to track these. You get this information, free of charge, using BPM/Rules technologies.
If business rules technology overcome the weakness of data modeling, then business process management overcomes the weakness of 'CRUD' development in tools such as PL/SQL, and screen generators. For instance, a number of system processes might post records to an order table. One is a screen entry. Another is a program that reads a file. Yet another moves data from a legacy system. Unless the 'CRDU' developers have decided to add the 'source' or the 'origin' of the record to their application, this information will be lost for ever.

What conservative, Waterfall or Information Engineering advocates are clinging to might be explained in terms of the Ross's 'Enterprise Architecture as Strategy'. On page 71, the book describes four stages of Enterprise Architecture Maturity. Adocates of these legacy methodologies are arguing that organization should not advance to stage 4, Business Modularity.

In addition to accurate and timely application development BPM/Business Rules:

  1. Dynamically Connects Rules, Activities and Events at no cost to the developer

  2. Positions Processes and Rules for change

  3. Creates more business-friendly artifacts, connects business requirement with technical artifacts

  4. Promotes a component-based approach
Thursday
Jan182007

Knowledge and the Wealth of Agile Enterprises

In 1990 there was a seismic shift in understanding the factors of production, away from the theories of Adam Smith. This shift is connected to the ideas we strive for in the Agile Enterprise. After all, Business Process Management and Business Rules are only lables for the tools we use to acomplish corporate strategies and tactics.

The reason I mention this was at I my last class at the BPMInstitue I met Dr James P. McGee. He drew a link between economic forces and the technologies of business process management and the business rules approach.


Dr. James recommended I read: (which I am) "Knowledge and the Wealth of Nations", 2006, ISBN 13-978-0-393-05996-0.



He also sent me a very interesting, lucid email describing the forces and factors. I share these comments with you:


As I discussed with you during class, it has taken 50 years for the mainstream economic community to recognize, accept and formally reflect in their "economic models" that "knowledge" is the key factor of production for all modern economies. This includes the modern firms in these economies. The old models held the traditional factors of production were land, labor or capital. The traditional factors of production are still important. Yet individually, or collectively, they do not and cannot account for existing growth. They will not be able to account/predict future economic growth and profit.


The book was written by a mainstream economist. As a member of the American Economic Association (AEA), Dr. Warsh is a part of the mainstream economic community. I think the writings show bias for the historical economic ideas and works of the AEA community. Dr. Warsh outlines in his book the events and stages that led to the mainstream economic community's understanding and accepting of "knowledge" (in all its different forms) as the key factor of production. Unfortunately, he only uses and makes reference to evolving economic thinking, practices and work products of the mainstream economic community- That is folks who are members of the AEA.


The book starts with Robert Solow's 1956 paper “Theory of Economic Growth, which treated "knowledge" as an exogenous factor of production. Then most of the remaining text covers Paul Romer's 1990 paper, presented at the AEA, which treated "knowledge as an endogenous factor of production". AEA members finally accepted Romer's ideas only after he and other younger AEA members figured out a way to include and represent "existing knowledge" and the "growth of new knowledge" in the AEA member’s global and national economic models. These extended, knowledge-focused models show it is chiefly available "existing knowledge" (either proprietary or non-proprietary) and the "growth of new knowledge" that is responsible for worldwide and local economic growth (GDP). It is not land, labor or capital.

Thursday
Dec282006

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.
Friday
Dec012006

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.
Wednesday
Nov292006

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.