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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘Big-P process’

The Procedural Paradigm Won’t Scale: We Need Configuration Agility!

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:
  • business rules 
  • operational business decisions 
  • structured business vocabularies (concept models, also known as fact models) 
  • business goals and risks 
  • business events
From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

Continue Reading 2 Comments

To-Do Items, Checklists and Out-of-Tolerance Business Events … Business Process Problems?

Does a to-do item constitute a business process? No. Does a checklist constitute a business process? No. Does an out-of tolerance event constitute a business process? No. Analysis of the following case study illustrates. The take-away: “Process” shouldn’t be force-fit to every aspect of business operations. That kind of ‘Big-P process’ perspective as I frequently call it puts blinders on you. Case Study: An organization runs public conferences. In reaching an agreement with a hotel, it must commit to a room block of a certain size. If the conference does not fill the room block, it must compensate the hotel. The amount of the compensation is roughly equivalent to the cost of the number of room nights not filled. So it’s prudent to always guesstimate on the low side. Sometimes conference attendance exceeds expectations. If the hotel is already heavily booked for the conference dates (e.g., for other conferences), attendees will not be able to secure a hotel reservation. Not having a hotel room may naturally discourage them from coming. So it’s wise to constantly monitor the number of hotel reservations vs. the size of the room block. Once exceeded, provisions should be made immediately to secure more hotel rooms for attendees, often at a nearby hotel. Analysis: Business process problem? No. This is really an operational business event – in particular, a spontaneous event.
  • The operational business event is when hotel room block is exceeded
  • A business rule could be specified defining the appropriate conditions producing the operational business event. 
  • An appropriate response to the operational business event might be Notify conference organizer.
If detecting the spontaneous event via testing of the business rule and notifying the conference organizer can all be automated, fine. If not, monitoring the hotel room block should be assigned as a job responsibility for staff, possibly just one of many ‘checklist’ items to perform daily. Does a to-do item constitute a business process? No. A to-do item – or even a whole checklist – is not a business process! Each item is what it is, simply a job responsibility. Simply notifying the conference organizer is not a business process either. A business process needs to be something more substantial, like Secure additional hotel rooms. Tip for Business Analysts: To be a business process it’s not enough for someone to be informed, something must be transformed. After-the-Fact Settlement: What happens if the hotel registration overflow is not detected in real time? Nothing good! Suppose the hotel continues to accept reservations knowing they can be accommodated at near-by hotels. Now you need an additional business process: Handle hotel registration overflow. It’s a business process you’d rather not have(!). Transferring registrations to other hotels entails significant work and communication, leaving some registrants inevitably unhappy. Clearly you need a ‘fairness’ rule for who gets transferred – probably first-come, first-serve. The bottom line: Failure to detect operational business events in real time can result in highly undesirable ‘settlement’ problems downstream. Use business rules in real time to detect out-of-tolerance business transactions whenever you can. Tip for Business Analysts: Stay alert for business processes involving after-the-fact settlements. Could real-time reaction to operational business events eliminate them? ~~~~~~~~~~~~~~ This post excerpted from our new book Building Business Solutions: Business Analysis with Business Rules. See: http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment