Mixing Process Design and Implementation Details is Evil

Scott said:

Sebastian-
I don’t think this is a debate between good and evil :) It isn’t quite so epic in proportion. Although it does feel like a debate between the ivory tower and the real world implementation of processes.

i’ll go by my points since that is the structure you chose as well:
1. you claimed my first two points were invalid because you said technical detail doesn’t belong in the process. Well, what if the process depends on something that is a nightly batch. that’s a technical detail. in or out of the process? what about inputs to a process activity or step? outputs? are those technical details or not ? (it isn’t clear what counts, so its hard to say whether your line in the sand is correct). It is fair to say that not all technical details belong at all levels of a business process (in my world, business processes may be nested, like a Russian doll), but at some level of abstraction, those technical details will make sense (especially if we’re in an implementation rendition of the process). Based on your exclusion of exception handling and data manipulation, it simply sounds like you are advocating for a “cleaner” business process diagram. In fact, to a point I agree with that - you hide these details at a lower level of a process definition (at a level that you would likely not even call a process, but a level that OMG would still describe as a process), because the implementations details of exception handling rarely, if ever, effect the top-level or two of a process.

2. you said you invalidated this point, but i didn’t see it in your argument…

3. i have done work for companies that have mainframe systems that are 50 years old that are still a core part of their business. the business processes have changed substantially, but the core technology is still there… IT assets that are core to the business are difficult to change. The risk associated with change is high, and the cost associated with switching technologies is VERY high. BPMS solutions provide an opportunity to further leverage those assets while introducing a more agile process-oriented layer above them that allows the business to reconfigure their interactions with such back-end systems. BPMS doesn’t replace all those technologies, but allows you to put them to work in ways that suit business processes that are new, modified, or evolving. As for IT selecting a new service to implement some back-end function. you’re right, the business experts shouldn’t necessarily care, but it doesn’t mean that that element isn’t part of an IT process that should be represented in a process-oriented (but executable) diagram. And they might care if that new service fails to meet previously expected SLA’s or ToS…

4. I realize that you never brought up stable performance indicators. I’m pointing out that this is the stability that really matters. to further illustrate that stability of business process is not really a goal that customers should or even are attempting to achieve. They are attempting to achieve STANDARDIZATION of process because it helps you then achieve division of labor, apply theory of constraints, and improve the process more effectively. But you presume wrongly when you assume i’m not dealing with heterogeneous environments. The environments of our customers are very much heterogeneous. However, our customers have chosen a BPMS to help them navigate that heterogeneity and extract a common (standard) process across it all. You sure as heck don’t want to implement the same process in two different middleware layers. That path leads to madness in IT. You implement one process and at its integration points, integrate it to the appropriate systems. The integrations can be “smart” - knowing that in some cases you integrate to system A and some places to system B, rather than always assuming system A. But these decisions are based on the context data of the process instance you are running… If someone said “here are these requirements, now go and implement them in java and C++” people would think it was crazy. Even though we’re talking “process” and not “code” - what you’re saying amounts to the same thing! Moreover, if the process did need to be reimplemented, the BPMS tools I have used support enough documentation to represent business requirements - the implementations at the BPMN level would be substantially the same. And the differences would only be nods to the differences between tools - which would have to be there anyway if i implemented the process twice…. (Moreover, I would never suggest you just “change on the fly” - although by comparison to traditional 18-month development cycles for IT, a 3-4 month cycle for BPMS will feel that way - requirements are still a valid thought process, but model-only isn’t necessarily a valid part of that thought-process).

Having participated in the implementation of over 100 production processes, the “problem of explaining to business experts” the strange constructs of implementation have been minimal. However, I HAVE had to spend significant time explaining BPMN. It has some complexity to it, especially with respect to splits and joins - and this has NOTHING to do with the implementation subsystem, just the modeling notation itself. And most business experts aren’t familiar with petri nets and concurrent programming. So I give them some rules of thumb to use around those elements, and fully expect that I’ll have to refine them to get to an executable model representation. My use case is different - I’m worried about how to get customers’ process ideas implemented in production (using whatever technologies make sense), and I just don’t see the model-only paradigm as adding lots of value to the process. A company can spend a year modeling all of these things… and then start implementation… only by then the processes have changed… now what? And we’ve postponed the ROI that we could get by implementing quickly and starting the continuous process improvement cycle…

Hi Scott,

my colleague Olaf took up the topic with another post. I’m a little bit in a hurry at the moment, so I hope his post clarifies some points. About your first point in your comment: We say, don’t mix technology specific details in your business process model. So of course you need to add input/output to your model, but not the specific XSDs, because XSD is a specific technology.

Sebastian