More on BPMN
Sunday, July 23rd 2006 | Assaf Arkin
Assaf Arkin’s recent article on BPMN generated some of the most interesting discussions I have seen on this blog in a long time, so I asked him to write a follow-up to his controversial piece. He came up with a superb article only he could write. Enjoy!
Why Implementations Matter
Any time we do something that requires thinking, we end up making mistakes. And business software requires a lot of thinking to get right. In this industry, we spend a huge part of our R&D budget testing software so we can find those mistakes and fix them. And we spend our PR budget calling them “issues” and “undocumented features”.
In fact, we’ve learned that the best way to develop software is to test before you code. Test Driven Development (TDD for short) is on the rise because it gets us to working solutions faster by finding mistakes earlier.
As spec authors we have the same human tendency to make mistakes. It’s not intentional, just a fact of nature we can’t avoid. We come up with ideas that end up not working as well in practice. We make assumptions that prove false. We miss on details that end up being important. Miss subtle points.
Implementations is how we catch those mistakes and fix them. A spec without implementations is going to be full of holes because it was never tested to find and fix all these mistakes.
But even one implementation is not enough if you care about portability. There’s always some subtle point that the spec author forgot to cover in detail, sometimes it’s one to different interpretations. Any two people implementing the same spec may correctly arrive at different results. It all depends on how you decide to fill in the missing holes.
If you have two or more implementations, then you can test them against the spec and find out where they differ. You can then fix them, and fill the gaps in the spec. Make it more explicit and precise.
I intentionally did not talk about the details that make BPMN un-portable, because they don’t matter. They exist for the simple matter that they were never identified or fixed.
All Abstractions Are Leaky
The only abstractions totally independent of implementation details are abstract enough that they don’t do anything. We don’t like how implementation details affect the higher levels, but they do.
I want to design a process where I decide to buy a digital camera and it ends up on my desk. Those are two simple steps, it’s a very simple process. But cameras don’t happen, so now there’s an inventory somewhere. And they don’t hand them out for love, so now there’s a payment step involved. The geographical distance between me and that inventory is an implementation detail, but now there’s a few activities dealing with shipment tracking.
That’s the nature of software. How you do things affects what you do. If things are easy, you’re going to do more of them, and maybe change your entire business model. If you could build computers fast you’d compete with Dell, if your forte is design and marketing, with Apple.
If you have an execution language that can do compensation easily, you’re going to take advantage of that. If you have an execution language without compensation, you’ll find different ways to handle exceptions. If you can’t easily cancel and undo an order, you need to double check with the customer before accepting that.
And at the high level of modeling, business people do worry about that, because those details affect customer satisfaction, and customer satisfaction affects the bottom line. How you do things determines what budget you have to keep doing those things.
The idea that high level models are independent of execution capabilities has no parallel in reality.
Is BPEL Enough?
Some people will argue that BPEL is not good enough because it doesn’t support all their use cases. But often the point is, BPEL by itself is not enough. We know that.
WSDL is not enough because it has no way of expressing messages on the wire to get the from here to there. For that I use SOAP in combination with BPEL. But even SOAP is not enough because it can’t transport those messages from here to there. For that I use HTTP in combination with WSDL and SOAP.
Business software is built on different layers that solve specific problems and are designed to work with each other. That’s not specific to SOA.
BPEL takes the same layered approach. Describe data types with XML Schema, services with XSDL, expressions with XPath/XQuery. What’s left is a spec that deals with the logic and the flow. And other layers that address other capabilities.
I don’t want BPEL to do human workflow because the subject is too big and broad to deserve its own specification. I want to be able to focus on access control and delegation in one place, deal with assignment and compensation elsewhere. Breaking big problems into independent specs helps us solve them faster.
We call those Domain Specific Languages (DSL for short). BPEL is a domain specific language for expressing the flow. XPath for expressions. We need a language for expressing the human workflow parts. It needs to integrate well with BPEL, because all abstractions are leaky, but it needs to be a separate thing. So it can focus on that specific domain.
When I say BPEL, I don’t literally mean just one spec. I’m talking about the anchor point around which we get specifications that deal with data, services, flows, and human interactions. I’m thinking of that one place where they all connect, and that would be the BPEL process definition.
In Conclusion
So to summarize my points. To get from ideas to deliverables we need implementations. We can get BPEL engines to interoperate because we have enough of them to move processes from one product to another and test how well they work. And tuning BPMN to BPEL we can achieve interoperability at the notation level.
If we start with one execution language, we get something that works. Then we can worry about adding other execution languages. The illusion of abstraction is just that. The same model cannot represent two different executions, because how you do things does affect what you do.
And no, BPEL is not the entire stack. We need more layers and BPMN needs to address all the relevant layers. And BPEL is the anchor point on which to assemble that stack.
Entry filed under: BPM 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No-it-u-love?
When you talk about “portability” of BPMN, it seems you mean that 2 different BPMN-to-BPEL “compilers” will generate either the exact same BPEL, or perhaps indistinguishible behavior when run on the same BPEL engine. But I don’t think that’s what most people mean when they say they want their process design to be portable.
A BPMS is more complex than a programming language. If all BPMSs were identical in functionality — differentiated only by runtime scalability or coolness of their design tool — it wouldn’t be a very interesting software market. The ways in which 2 different BPMSs handle human task delegation has nothing to do with process portability. Nor does whether an activity is invoked via SOAP over HTTP vs some other protocol. In my view those differences exist beneath the portability threshold.
I think if you would clarify the actual result you are trying to achieve with your proposal (and condescend to provide examples of the problem), people might agree that your approach is the only way to get there. But they might not agree that this is the right question to ask of BPMN.
-Bruce
I couldn’t help thinking that this reminded me of that old worklfow concept… I used to ask a vendor how XYZ would be accomplished and they would invariably answer that “you have to write a program to do that” (I am talking 1990s workflow here). So I would counter with something like, “well in which case this C compiler is a workflow tool too”.
And in the same way I would argue I don’t really care about the low level implementation details of a modern BPMS, if the answer is that you have to write a program to do that, I am not really interested. However, I am interested in what the tool does for me out of the box, what does it achieve without having to resort to programming.
Now when we get into modelling at a high level the business process, and seeing that translated into effective execution, I am not interested in whether BPEL is under the hood, or some other proprietary implementation of executable processes (or even a proprietary extension of BPEL).
If the model itself is transportable, across products, then it removes the vendor lock in. And if we were to quote John Evdemon from the last BPM Think Tank, “BPEL was never designed to be portable.” (Must admit I did a bit of a “wow, didn’t expect to hear him say that”).
If the BPMN model is transferrable, via a robust set of semantics and a serialization mechanism (BPDM), the reliance on BPEL as a programming language just becomes a mere implementation detail. How it is achieved is promoted to about as much importance as how I get mains water out of the taps at my house. I don’t care about the pumping stations, the treatment plants, the aquaducts… all the things that transport the water. All I know is that it comes out the taps and I can heat it with a boiler, or put it in my swimming pool.
So bringing this back to the world of business processes, if the business person can model the domain he/she is interested in and have it execute, then they don’t care about the plumbing, about SOAP, about HTTP, about… all they are interested in is the utility that it delivers.
Derek,
I like the poetic value of the analogies you’re making, but they totally ignore Assaf’s points as far as I can tell. Also, where is this BPDM thing you’re talking about? Is it available today, or is it just a pipe dream? And what about portability across BPM product? Can you give me a reasonably-complex process (say 25 activities) that is portable from one product to another without using BPEL, while remaining executable? I’m curious now…
[…] When you’re deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, BPEL 2.0. But he doesn’t really defend the assertion with arguments that the undecided can understand. […]
Derek,
Your arguments about workflow are dead on!
Workflow tools do the flow easily, but you need to write a whole lot of code to get anything done. The flow is just not enough.
BPMN has the same problem. Just because you can write a flow of activities doesn’t make a process you can manage.
You need services, data, expressions, and that’s a lot of work that needs to be reinvented, and I wonder: why?
Wouldn’t it be easier to reuse existing specifications that already went through the pain of doing all that work, and are widely supported?
Just a thought.
Folks,
This new thread revived older discussions following Francis Ip’s article.
Definitely worth checking!
[…] Recent discussions on BPMN and BPEL have created a level of activity rarely seen on these pages. The quality of interactions is outstanding, and I strongly encourage you to read through the comments of this post, and this older one contributed by Francis Ip. In the meantime, let me use the opportunity of our weekly BPM 2.0 post to shed some light on why BPMN and BPEL nicely complement each other, and who really needs a complete BPMS. Disclaimer: this post might upset some readers, especially towards the end, but I need to get some messages across, loud and clear. Consider yourself warned! […]
[…] After I posted re the piling-on Assaf Arkin was taking over his assertion on IT|Redux that BPMN belonged to BPEL, the man himself posted a thoughtful response on BPMS Watch. I was waist-deep in real work at the time and didn’t have time to think through an appropriate continuation of the thread, so I dashed off a quick response by email. That began an interesting out-of-band conversation that, if nothing else, narrowed the gap between the BPEL-si and BPEL-no positions, and shifted the debate from lofty analogies and name-calling to things reasonable people can at least discuss. […]
I want to catch some points in order to add some thoughts based on Assafs statement “I don’t want BPEL to do human workflow because the subject is too big and broad to deserve its own specification”:
First, whether we include or exclude human workflow in our focus is a key point in the discussion on the relationship of BPMN and BPEL.
As already mentioned, BPEL is not designed for human workflows. By the way: I was quite shocked that companies like SAP and IBM spend several pages on their argumentation why human beings might participate within a business process; it’s 2006 out here. OK, SOA blinds sometimes, but wasn’t there already some work at Xeroc Parc (where else…) on office automation started in the mid ’70s by Skip Ellis and Gary Nutt? But that’s another point of frustration. Derek, beam me up…
However, BPMN does not make any assumption whether a business process consists of manual (human) or automatic (system-executed) activities. That’s good. As with any traditional definition of workflow, “business processes” consist of activities (or process steps, or whatever you like as your preferred notion) which might be executed by humans or by some IT system. And you will never ever find any business or process analyst using a modeling language limited to the orchestration of some computational statements and operations (also called Web services if wrapped by XML and SOAP).
Consequently, we always should keep in mind that BPEL has evolved from WSFL (Web Services Flow Language) — and this is exactly the correct acronym for BPEL (which even starts with WS-BPEL or BPEL4WS — when did we lose the WS?). Since BPMN has just another focus, there will be no easy mapping between BPMN and BPEL, and vice versa — the same holds for mappings between petri nets, CSP, statecharts, event-driven process chains (ARIS EPK), and so on. I guess tha’s particularly frustrating when implementing a BPMN designer on top of a BPEL engine, resulting in all the errors and misunderstandings in the mapping of BPMN and BPEL — but it’s better than implementing XPDL 2.0, which just adds highly-specific and sophisticated BPEL attributes to the XPDL 1.1 specification, crazy…
The gap is naturally based on abstraction. A high-level model typically requires some step-wise refinement in order to add missing details needed for execution (well, abstraction means hiding details). However, adding data variables, scopes, catch blocks and so on in a BPEL designer is quite equivalent to programming the same in Java. Implementing transactional workflows by drawing shapes and lines will remain a myth — I’m sorry to say that since I believe in modeling, modeling, modeling!
I have a second point: though I agree with Assaf that BPMN should have a more precise and executable semantics, I disagree that we need spearate languages for human and transactional workflow. Of course, both scenarios need different language constructs (ever talked about compensation spheres with your colleagues?); but at the heart of business process modeling is the flow (not variable assignments and catch blocks). Separating human from automated business processes is not a good choice in terms of domain specific models. We still need a core business process modeling language. BPMN is a good step in that direction.
Gregor,
“We need spearate languages for human and transactional workflow.”
This statement has two different meanings. One implies two languages that are alternative to each other, like Java and C++. The other implies two languages that are complemantary to each other, like Java and XML.
The point I’m making is that two complementary languages that work well with each other is the best way to get the results we want. For the reason that it will do both automation and human workflow, and because slicing the solution in two separate steps would make it easier to author, implement, and refine each part to maximum effect, without losing the capabilities of the whole.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment