• 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

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.


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.