Jet Blue's Recent Woes

Jet Blue's recent troubles with a poor response to extreme weather reflect a lack of agility in substitutability. National Public Radio posted a pretty astute analysis here. It seems like a cascade of poor decisions lead to the catastrophic event. Agility in substitutability means accurate business delivery during periods of overload or failure. Flight scheduling decisions should have been guided by decision analytics that using weather scenarios and its impact on the network. You can incorporate analysis such as integer programming into active decisions and workflow. The cost of these systems can be high, yet the likeliness of a reoccurrence also seems high.

Jet Blue now has a unique perspective on the ROI of a system like this.

A passenger’s ‘bill of rights’ obfuscates Jet Blue's substitutability issue. You do not hear any of this thinking in Mr Nelleman's thinking. Investors and Competitors will be watching to see what technology they bring to prevent this.

The Agile Core

Considering Business Agility and the concepts of SOA, and the converging maturity models of BPM/Rules. Firms should strive for an 'agile core' I would suggest it looks something like this:



Over time, companies that incorporate agility into their process/policy
(rules) strategies will need to build an agility 'back bone' or agility core.
An agile core is a collection of common process/rules/information structures
that business agile processes will require to operate on a simple level. These
underpinnings, including vocabulary, product/services, organizations, and
personnel and training data structure should be critical to every process, and
therefore every BPM/Rules initiative.

I will explain how I developed this diagram. There are 17 basic type of business agility. You can read about these in this blog.
Reconfigurability
Improving reconfigurability requires maintaining an adequate portfolio of
goods and services without large-scale investments. Are you loosing customers
because of a flaw in your product/service mix? The point of this agility is to
leverage existing business production systems. The feature of this agility is
that an adequate range of products serves customers are served with the
existing business delivery systems Core agile services for reconfigurability
provide information and data about existing products and services and a list
of customer categories that purchase these. Customer profiling is often done
with 'analytics' and this service should provide its output.
Modularity index
Improving the modularity index correctly broadens the range of goods and
services without large-scale investments. The point of this agility is to
easily add something to the firm's product/service mix. The feature of this
agility is that more customers are served with the existing business delivery
systems. Core agile services for modularity provide 'virtual' information
catalog of products and services' and suppliers for these. The agile ordering
process should sense the need for more products and services and add these to
the catalog.

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

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:



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.