Blame the Computer: A Business Process Modeling Anti-pattern

re: Blame the Computer: A Business Process Modeling Anti-pattern

Jean-Jacques Dubray — Sat, 28 Jun 2008 16:10:15 GMT

Nick:

Never, ever, BPMN was intended to be used that way. I don't know how Microsoft manages its processes, but in most mature organizations processes are simply and only modeled from the "people's view", i.e. it tells people what to do. There is never a system's view either baked in or inferred from the people's view.

As you rightfully say, this is a "business continuity" problem. If something bad happens the business has to go on and a user would know what to do, capture, communicate and act.

Now it is very unlikely complex rule sets (pricing engines,...) could be manually run in a business continuity event. Another set of rules will have to be applied.

The problem that you can't seem to grasp is that there is no formalism known to man that would let you transparently express business logic spread over humans and systems. It's like saying I could generate "Word" from it's user manual. Have you tried that? Has anyone ever attempted this? Strangely enough this is what people are trying to do with BPM.

One of the key problems (as I told you many times) is the programming model. How can you ever think you would succeed in achieving some of the things you are talking about in an MVC world where the programming model has no understanding of activity boundaries? When a developer writes a line of code, he has in general just a very vague idea about what the user would be doing or what activity will be performed.

You seem to constantly think that you will fix IT by a better, more refined methodology. You even went as far as asking wsper "to go away", when indeed, this is the only viable way forward (not wsper, but the underlying service oriented, process centric, model driven programming model behind concepts such as wsper).

Now, the other issue is of course to think that there is something called "The" process for doing something. How many times have you heard users complaining about the systems preventing them to do something that would be perfectly logical to do (specially during exception management).

In reality, what you call "the" process, is a "common" way of doing something. It does not have to always be that way. The tragic mistake system designer make is that they are trying to map "the" process and by default eliminate large amounts of valid paths that at some point a user will want to take to solve a customer problem.

This is why business object lifecycles are so critical to this programming model. Systems should be designed based on the activities that can be performed from any given business object state. A pricing activity could then be automated or not, from the lifecycle perspective, it does not matter.

As long as, as an industry, we will perpetuate a corny programming model, deeply and totally misaligned with the way information systems operate and the tasks that are performed to change their state, IT will deliver less and less value to the business. It is not a question of boxes, arrows or ownership.

re: Blame the Computer: A Business Process Modeling Anti-pattern

NickMalik — Sat, 28 Jun 2008 20:28:12 GMT

Hi JJ,

For a moment, it looked like you were going to say nice things to me... and then you added in this statement, "The problem that you can't seem to grasp is"

Why do you insist on responding to my blog if your responses include insults? There is no problem that I am unable to grasp.

The programming model is always open to innovation. Feel free to demonstrate the power of that innovation, JJ. Once you demonstrate value, everyone will join you. Until you do, you are sharing opinions... and we ALL have opinions. WSPER is a nice try. Get it adopted. I'll come around if there is value there.

You are suffering from the "golden hammer" pattern, my friend. You have a solution that will fix all problems... a golden hammer.

But your solution will do nothing for business process engineering. There will still need to be BPM, even if you get the world to change the programming model. Because, in my world, people matter more than computers. BPM is about PEOPLE.

People need to be trained... they need to have the correct tools, and their organizations must have policies and practices that favor positive results.

People count. So does BPM. The programming model will not fix that.

Lastly, you suggest the following "Systems should be designed based on the activities that can be performed from any given business object state"

What are those activities? Where do they come from? I'll answer: from the BUSINESS PROCESS. Until a business understands their business process, and agrees on the opimal approach to it, the intended activities cannot be developed... and your precious programming model will deliver no value.

Trust me on this, JJ. Your model, which is an innovation over and above SOA, cannot succeed without people who understand the business processes. SOA and BPM are joined at the hip. In the final count, one will not succeed without the other.

re: Blame the Computer: A Business Process Modeling Anti-pattern

Syed Qadri — Sat, 28 Jun 2008 21:08:08 GMT

Actually, I believe that responsibility lies with multiple departments / people not one department. For example, the responsibility of the database going down because of power failure etc should go only to a specific group (DBAs in this case).

While some other issue with data should probably go to the Accounting department. It is simplistic to suggest that only one department/group should be responsible for an activity.

re: Blame the Computer: A Business Process Modeling Anti-pattern

NickMalik — Sun, 29 Jun 2008 07:57:26 GMT

Hello Syed,

Responsibility for maintaining the IT infrastructure remains with IT, but the responsibility for actually pricing a special order remains with the order accounting department. Just because we automated that function, that does not mean that IT is EVER responsible for performing it.

IT is responsible for computers and databases. Business is responsible for business functions.

Is that more clear?

--- N

re: Blame the Computer: A Business Process Modeling Anti-pattern

NickMalik — Sun, 29 Jun 2008 16:56:47 GMT

Upon rereading JJ's criticism, it occurs to me that he may be under the mistaken impression that we are attempting to use a process engine to execute business process automatically.

Nothing could be further from the truth. It's a dumb idea. Yes, I'm aware of the work at QIT to map BPMN and BPEL. Yes, I'm aware of all the people and vendors hyping the idea that we could, should, or would ever want to, create some kind of automatic path so that a mapped business process auto-magically becomes software. I'm aware of the concept and have, internally, discarded it outright.

Just like JJ, I have been involved in the development of process engines. I, too, had been one of the folks calling for process automation as some kind of holy grail. But I don't believe that is a useful endeavor any more.

My approach these days is radically different. The BPM models you see are BPMN only, are stored in a repository for other business teams to see, learn from, and perhaps use, but not to automate.

I work with teams that model human behavior, not for the sake of automation, but for the sake of improving customer satisfaction and communicating across diverse teams of people.

So, JJ, and all of the other folks in the BPM community who may chance to read this blog, please consider that I am not attempting to automate these processes. I'm using them to describe requirements. I'll post in another blog what I mean.

I hope that clears things up.

--- Nick

re: Blame the Computer: A Business Process Modeling Anti-pattern

Bill Poole — Mon, 30 Jun 2008 08:10:12 GMT

I agree that it is vitally important to ensure that you leave the business logic with the department that has responsibility for defining and understanding it rather than with IT.

When it comes to modelling your business services that will be the basis for a common understanding between your business architecture and information systems architecture you will want to ensure that the logic is implemented in the appropriate service.

In order to guarantee high cohesion and loose coupling between services, we must have our related logic together in the same business service.

A business service contains not only IT systems, but people and process as well. Thus business logic pertaining to a given business area must be defined in the same place whether it be automated or not.

Automating a task creates a dependency to an IT system - it does not restructure the process model.

re: Blame the Computer: A Business Process Modeling Anti-pattern

NickMalik — Mon, 30 Jun 2008 17:07:57 GMT

Well said, Bill.

re: Blame the Computer: A Business Process Modeling Anti-pattern

Flournoy Henry — Sat, 05 Jul 2008 19:34:42 GMT

As a process practitioner myself, I too often find myself looking for a better way to model a "Business" process. However, there's a fundamental point in your argument Nick that I don't fully agree with.

Just because an Activity is in a System swimlane does not mean that IT owns the activity. I agree with all your points about BPMN is for communication and understanding; Swimlanes are for responsibility and ownership, etc.; but the key point is that the entire process is own by the Business, not just a swimlane.

Swimlanes are also very useful in depicting boundaries of roles/groups. One can quickly denote who's doing what. If a Get Pricing Activity is in a user swimlane, does the reader think a human is involved in that step, or are they supposed to understand the technologists rendering of a dotted line dependency to a "system box". And does that dependency mean the user is interacting with that system or does it mean that system is actually performing that activity with no human interaction? These complexities in the model begin to reduce the communication value I think.

Again, I totally agree with your opinion that the Business must continue to own the process and the process improvement efforts, but I don't think moving a box into a System swimlane changes that responsibility. It should be the case that IT does not really own any system (outside of infrastructure and enablement technologies of course), rather, the business commissions IT to produce solutions which often involves technology and the construction of systems. But it's always the business that owns (and should pay for) those systems.

Oh, and one other note. I think it's totally possible to take a BPMN model and actually turn that into an executable, run-time business process that renders high value to the business and the enterprise as a whole..... but that's another blog.

Process and IT budget... owned by the same person?

Inside Architecture — Mon, 07 Jul 2008 03:51:47 GMT

In a prior post, I described a process modeling antipattern which I called " Blame the Computer

re: Blame the Computer: A Business Process Modeling Anti-pattern

Max Pucher — Mon, 07 Jul 2008 10:17:35 GMT

Exactly: Someone THINKS that it is possible to take a BPMN model and turn that into an executable the renders high value to the business. But it is no more than a thought. There is NO PROOF. I have been bugging experts, analysts, universities and whoever I can find to come up with the empirical evidence that BPM is actually good for a business. It does not exist!

I fully go with Nick Malik. Business is about people. Automation is not about people it is about cost. I see a lot of people pulling the quality card out when discussing and they completely forget that normal business activity is not like manufacturing where you need to nail down the physics. Yes, on the factory floor automation and robotics have dramatically increased quality - along with miniaturisation, but that is not transportable to services. People are individuals and every relationship is special and can not be modelled. Trying to do so kills the business.

Automated BPM is a service quality killer. We need support systems in the collaborative sense that allow us to run processes as they are needed in real-time but not as they are modelled. People - employees and customers - need to be enabled and not cost has to be reduced. We need some basic semantic models to structure the activities as without metadata there is no information content, but that should be it.

Large scale BPM will NEVER work.

re: Blame the Computer: A Business Process Modeling Anti-pattern

Ramesh Paturi — Mon, 07 Jul 2008 13:07:04 GMT

Nick - good point made. There is an additional concept known as swimpool area - it contains multiple swinlanes. The swimpool gives the name of the department normally and relating to your example - it can be accounts department and the swimlanes in that can be that of accountant, clerk and an IT System. This would solve the problem we are talking about.

re: Blame the Computer: A Business Process Modeling Anti-pattern

NickMalik — Tue, 08 Jul 2008 10:39:54 GMT

Hi Ramesh,

The problem goes MUCH deeper than the use of swimpool areas. See my recent post on Process and IT Budget.

It's a complex problem, but it sits at the core of why this pattern is so bad... activities with no owners = baaaaad.

--- N

re: Blame the Computer: A Business Process Modeling Anti-pattern

fhenry@bp-3.com — Wed, 09 Jul 2008 17:51:10 GMT

I can't resist the proverbial "head in the sand" comment here.

As for implementing BPMN in a run-time model ... I understand your resentment to jump on the BPM hype curve, but it's no longer theory. I not only talk about, I've implemented several BPM solutions that delivered high value and return to the Business, IT, and the Enterprise. Unfortunately, it's not at my discretion to share with you examples of proprietary solutions, ROI and project plans as "proof"... but believe, I'm not the only BPM soldier with a success story.

Furthermore, it seems the gist of this thread is about "automation".... BPM is NOT just about automation. In fact, I will submit that automation is often a bi-product of the business process discovery that happens in a BPM project. BPM is all about people and the way people work in concert with one another. The problem is that all too often, the business loses site of the relation ships between groups, roles, departments, even worker to supervisor. That's were BPMN brings value in the documentation and enlightenment area. Then, the ability to execute on that BPMN model brings value in quality control, process improvement, capability measurement, statistical analysis ... and more.