We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

A key rule for business process: When crossing a street, worry about the last step, not about the first one

Vote 0 Votes

I've read a brilliant white paper "As-is and To-Be Process Modelling: a Flawed and Failed Paradigm," authored by John Owens, which I highly recommend for your reading. John finally uncovers the argument that modeling a business process "as-is" does not make sense unless you plan to keep it as is. Sorry, but modeling an as-is process also does not make sense because it works already, without your model; the only useful thing you can do with it is to document it.

If you plan to charge the process, and you have documentation, the only things you need to know for the modelling of a future process are:

1) Input of the current business process and its triggers.
2) Expected outcome of the current business process.
3) Business functionality realized by the current business process.

You need to know all these elements to answer only one question: When you create a new business process, will you need to maintain the current one--i.e., is the business function realized by the current process still in use or still needed?

Knowing how the current process works does not help you at all to understand how to move into the new/target process. That is because the work of the process does not identify what the process had been expected to do. I fully agree with John on this.

The white paper points out that the first useful model for business process design is not a process model but a business function model--that is, the one that defines aforementioned three elements.

If a business analyst raises his or her head, it would not be difficult to notice that those elements actually form a model of a business service. This is what I have continually repeated for several years now: If you want to manage business process-based solutions, forget about process details. Look at it as it is a service and you will know whether the current process is what you really need and what you might want instead.

To design a business process "to-be," the first thing to know is its business function and the position of this function in the business function model.

Nevertheless, I cannot agree with John on three points he made in the sphere of functions/services:

a) Differentiation between preferred and non-preferred outcomes: obtaining "Non-preferred outcomes in case the preferred outcome cannot be attained."
b) "A business process is merely the definition of the order of execution of selected business functions in response to a specific business trigger, in order to arrive at the specified preferred outcome for that trigger."
c) "Trigger to Outcome" versus "Outcome to Trigger".

I believe that there may not be a preferred outcome as well as preferred process path: all direct/indirect/alternative paths are equal in the process logic. As well, no business rules between process steps can be "preferred " or "second-hand;" they can be only correct or wrong (or absent). It is a matter of perception; what is a rainy day for one may be a sunny day for another. A substitute teacher is happy when a permanent teacher cannot give a lesson.

I have a different understanding from John's of what a business process is. Yes, a business process is an order of steps; whether anything else is executed beside the rules/decision-making is always an open question. To move along the business process logic from step to step, certain rules have to be satisfied. This may require a number, information about a particular event, a certain action or the like.

Whether this information is prepared and just waiting to be requested by the process or should be produced on the fly upon a request is irrelevant to the process. Moreover, who, where and how produces this information (or "intermediary results") is immaterial to the process.

Thus, in general, we cannot assume that a business process is just "the order of execution of selected business functions;" we might be unaware what was executed, when and where. The only things we know are the "intermediary results" and immediate provider of these results. One business process differs from another business process only by its business logic; the same business function can be used in multiple processes simultaneously and no combinations of particular business functions can uniquely identify the business process. The process business logic is the only substance that adds new business values that no business function has on its own.

In the white paper's definition of a business process,the trigger plays a role of the execution context propagated throughout all process steps till the final outcome. This may be true--but not necessarily true in all cases: There are a lot of business processes where the trigger initiates only the first step, while the second step does not care about an external trigger.I think it is cumbersome to link a trigger to the exact process outcome in all cases. Another matter is an input to the process: The process outcome is certainly a function of the inputs for the business process.

Finally, the white paper proposes using two methods for modelling a business process: starting with triggers and defining to-be used business functions and "related" outcomes ("Trigger to Outcome"), or starting with the desired outcomes and defining what triggers and business functions can lead to them ("Outcome to Trigger"). Talking about the former, John writes that a business analyst "... will look at the trigger and ask, "What function does this trigger initiate?.. They then ask,"What happens next? After we have executed that function, what then happens?" With this approach, they keep adding appropriate business functions to the process until they arrive at the preferred outcome."

In my opinion, this is an absolutely faulty approach.

Because different business functions can result in the desirable outcome, no business analyst would know which trigger to begin with and which business function should be started by that trigger. How anybody would know that something is a trigger? Even if a business analyst takes a random trigger and the first function, how is it possible to find what the outcome of the execution of this function would be if the outcome depends on a particular implementation of this function? Simply, a business analyst does not have enough information to solve such a task.

By the way, when we design services, our starting information defines inputs, desirable outcome and business functionality to be realized. How it is realized is a different matter and the task for the implementation design.

Another story takes place when we follow John in the "Outcome to Trigger" approach. Now we have a chance to solve the design task. John writes that this, "... asks the question, 'What must occur immediately before this preferred outcome can be deemed to have been reached? What business function must have been executed in order to bring about this state?'"

In the book "Architects Know What Managers Don't," scheduled for publication in March 2013, I describe a method called "Cause-Pyramid". This method starts with the goal/objective/outcome at the top of the pyramid. Each lower level contains all fundamental answers to the question "What must be done in order to deliver every entry in the above level?"

Every next level is functionally more granular than the previous level. The construction of the pyramid stops when no other fine-granular business functions or features may be identified for given business domain and only an implementation and execution of the lowest level functionality is possible. Then the process reverses and climbs up to the previous level, implements its entries based on already built implementation beneath, executes it and moves further upward.

Using this Cause-Pyramid, you will be guarded from omitting important logical steps and functionality much better than just trying to construct a process diagram with all logical details. The Cause-Pyramid gives you an observable picture of what is needed to be done (what functions need to be engaged or created), in which order and in which information/value stream.

So start your journey in designing business processes with what you want to achieve in business value. Define what business functionality can help you to achieve the desired results and identify what inputs this functionality requires. If you move in the opposite direction by defining your first step first, you can easily end up in the situation where the second step would be unavailable to you. Bottom line: When you walk across the street, always watch where you want to go and whether you have a clear path to that point.

If you are interested in taking a service-oriented view on business, watch for the Orbus' white paper "Transition of the mindset: Business Processes Meet Business Services" that is expected to be published soon.



Website counter

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives