sstein's picture

HazardIn my previous post I provided an overview of business to IT transformations. I pointed out that most tools actually do not provide a transformation, but instead push technical details to the business level and misuse a business process modelling language like BPMN as a visual representation for BPEL. Now, I got a lengthy response saying that this is not a problem, but a feature. So was I wrong in my initial post?

I received a lengthy answer to my previous post from Scott Francis, which you can view online. For those not in the mood to read this long post, here a short summary of how I understand Scott’s line of argumentation:

  • He starts by saying that I’m looking for no technical details in the business process model and that such a model should be stable with respect to technological changes.
  • He points out that BPMS tools support a pure business oriented modelling, so that not every process must be executed.
  • He says, usually business processes change faster than technology, so the business process won’t be stable.
  • He says, key is having a stable set of performance indicators to evaluate if the business processes improved over time.
  • He says, it is better to have a business process model with technical details, because otherwise a business expert can’t verify that the process was implemented correctly.
  • He concludes, if one has to choose between a modelling and an execution tool, one should go for the execution tool, because the implemented process rules!

Well, first I like to thank Scott for those arguments, because they give me a nice way to illustrate my point. However, let me first clarify some things. I never said that a business process, which should be automated, should not be informed by technology. I just said that such a business process should not contain technical detail. Of course it doesn’t make sense to design a process meant for execution with an ambiguous control flow, which can never be executed on a machine. Also, if some kind of IT support is envisioned for a function, this should be detailed in the business process model, too. But technical artefacts like exception handling, data manipulations, and variable definitions don’t belong in a business process. They are technology specific and don’t provide any valuable information to the business expert. So the first two points of his arguments are invalid, because I never said that.

I agree with Scott that business processes might evolve faster than IT. I don’t think this is a general rule, but it really depends on the company context. Still, evolution of a business process and an implemented process must be divided, but a synchronisation is needed between both. So if the IT implementations removes a business function because the functionality is already covered by a service invoked before, this must be communicated to the business experts! However, if the IT implementation adds a new exception handling routine to select another service instance in case the default instance is not available, I don’t see why business experts should care.

I also agree with Scott that measurement of process performance is important. However, my original post was not dealing with that point, so not sure why he brings up this topic. Now my general feeling is that Scott is not dealing with processes implemented on several different technologies on the same time. He suggests an agile approach where user requirements are turned into implementation on the fly neglecting the need of a requirements specification. Such an approach is fine if you later don’t need the requirements specification again. But it will fail if you have to implement the same process on a different middleware some months later (while the one implemented before is still deployed and used). In that case, you will have to reverse engineer the requirements from the implemented process.

So it might be that Scott’s use case is just different. If you are just using a single execution technology and you know for sure that it won’t change, it is ok to add platform specific details to the business process model. However, you are still facing the problem to explain to your business experts why strange constructs like fault handlers, correlation sets, and copies between different variables are needed.

Tags: soa