One group wants to give the graphical process modelling notation executable semantics. In that case, a BPMN 2.0 diagram would specify exact (and hopefully portable) semantics and it can be executed on a computer system. On the other hand, some people raise concerns about the simplicity in that approach.
This again shows that today the dual nature of BPM is not enough recognized by BPM vendors. BPM tries to make the bridge between non technical business analysts and the implementation of a business process.
A business process analyis can contain a diagram and it expresses how people and systems work together. Such an analysis is targetted at other people so it can include free text and a diagram. It's description of how things work in the real world. Analysis can be done without even automation. An analysis is always an important input to express the requirements for the automation of a business process. Some analysts use very expressive diagram notations, while others just use boxes and arrows. But even in case a lot of details are expressed in the diagram, they are not necessarily expressing runtime execution semantics in the software sense of the word.
In case a business process is automated with a Business Process Management System (BPMS) , an executable process needs to be created. An executable process serves as input to a BPMS, after which it will be able to execute the process. Executing a process by a BPMS means a combination of monitoring progress and performing automated tasks. Executable processes can also be based around a diagram. But in this case, the diagram is a projection of a software artifact. The executable process will in most cases contain technical details outside the scope of the diagram. Whatever way you look at it, an executable process is software.
There are some aspects that cause some fog around this clear picture. In practice, it turns out that the roles are not that clearly separated. In fact, a lot of business analysts have technical knowledge so they already are able to think in terms of what it means to execute the software. Also, there are different levels of process languages. The more a executable process language targets to be general purpose, the more complex it will be and the more technical it will become.
If a diagram notation (like BPMN) wants to be used for both the analysis as well as the executable process diagram, it should limit the number of details that can be expressed. As analysis details don't match with technical details necessary for making the process executable. The more details that are exposed in the graphical notation, the conflicts will arise because of this dual nature of the process diagram.
More and more vendors start to see that the gap between the analysis process and the executable process can not just be eliminated. But still quite a few target round tripping, which means that the analysis model is kept in sync with the executable model. I have seen multiple vendors come out with features that support this. Still I think that is a waiste of time. Building tools that synchronize automagically between the analysis and the executable diagram is too hard. Using those tools effectively will only succeed in environments with a lot of discipline cause changes in the executable process will often require an analyst to incorporate those changes into the analysis diagram. Furthermore, those tools impose too much assumptions on the analysis language and the executable process language. FWIW, such an approach never did fly with UML Class Diagrams, and I don't see how the situation is different for processes. In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.
Instead, I think it is much more practical to create an executable process language that can build the executable details around a given diagram structure. That way, the executable process diagram will be very similar to the analysis diagram. The better the executable process, the less the diagram will have to change. But a conversion step cannot just be eliminated. Even if the executable process languages was 'perfect' in keeping the same diagram, some parts in the analysis diagram might not even be automated.
Once a business process gets automated, the diagram in the analysis document can be replaced with the executable process diagram. This has as a consequence that the analysis diagram becomes read-only for the analysts once it has been converted to an executable process.
Instead of embracing the dual nature of BPM, the InfoQ post outlines very well how two opposite camps have formed around analysis and implementation. Previously the focus of BPMN was on analysis only. It's much easier to reach consensus in that more limited scope. Now, the big vendors got involved and expressed a clear vision to make BPMN executable. That opens up the whole discussion of the environment. BPEL clearly chose for an ESB environment based on WSDL. But (just to give another example) jPDL is defined in a Java environment. I don't yet see how you can define an executable process language without selecting a concrete environment in which it operates. This is exactly why we support multiple process languages on our Process Virtual Machine.
The way things are moving now, the move towards executability of BPMN is starting to become clear. But looking further in that direction, I can only see quicksand. As indicated above, the vision of making BPMN executable could quickly be dragged down by many technical "details". It will be interesting to see how that is going to play out, but my fear is that it's not gonna be a smooth ride.
One thing puzzles me, though. Why is everyone talking about a new file format for BPMN 2.0, while there is XPDL ? The WfMC guys did a lot of effort to get XPDL synced up with BPMN and they made a lot of noise about it, so it cannot be an oversight. Still everyone seems to be silent about the possibility of using XPDL as the file format. Does anyone know more about the motivations for this silence ?
This is a great post! I have often found it silly that vendors in this space have continually pushed in a direction, trying to eliminate developers. The dual nature of BPM, as you point out, requires expertise that developers have, to make a process executable. There is also testing of the business process that has to take place, and this again requires traditional QA approaches. It gets old listening to vendors tout the ability to bypass developers and testers with their products, when it simply is not possible.
ReplyDeleteAbout XPDL:
ReplyDeleteXPDL is used in a lot of enviroments, but big market players do not like it, maybe it's NIH sindrome. But silently XPDL making it's way in the market, for egzample IBM WebSphere Business Modeler now includes XPDL import/export. On other way, whole industry (especialy big players) need to realize that is BPMS and BPM, and BPMN 2 lets them do this, by anauncing new emerging standart and giving time to realize thats is all abuot (create their vision).
@Andrig:
ReplyDeleteIndeed. But some of the vendors start to be aware of the dual nature of BPM. But the only solution that they come up with so far is to create tools that synchronize between the analysis model and the executable model. In the current situation with BPMN and BPEL, this is practically impossible.
regards, tom.
@Tang:
ReplyDeleteBig players treat XPDL as a checkmark. But they do not push it forward. In BPMN 2.0, I see a huge opportunity for the big players to put XPDL forward as the file format. Yet they don't. I'm not saying I would like that (i see pro's and cons). It just puzzles me.
Unless XPDL gets the same momentum as e.g. BPMN, it will stay in the corner where it has been for the last 15 years.
regards, tom.
This is a good posting, but has a very strong leanings towards old schools of thinking and ways of approaching solutions.
ReplyDeleteAs a developer at heart, I tend to agree with the premise that the modeling basis be kept independent of the execution space, so that sanctity of the model is maintained. However, a lot of water has passed under the bridge and lot many mindsets have resulted in a plethora of similar sounding diverse technologies. The number of formats and techno jargonery , these days are amazing.
We ( read business, end-users ) are slowly moving towards a "Cut-The-Crap-AND-Show-Me-The-Benefits-In-Clear-Terms_And-NOW" kind of expectations. And it is understandable, considering each new offering has got its own paradigms,rules,methodologies,constraints, people are fast realizing that they do not have the time to digest to all this to get something done.
At the end of the day, whatever formats and technology proposed/adopted, must be adaptable to the business need for it AND not expecting the world to change for them. Technology and technocrats need to understand this clearly. Or is it creating the hype and hoopla and ensuring that developer jobs do not get eliminated.
So what is wrong with models becoming intelligent? Architecture is moving towards intelligent object based execution ( example Autocad Revit ).. It saves a lot of time and effort... Change is here..
All the best to you if you think otherwise..
Btw, I have loved jboss since it started off as just an app server and have been following the developments on jbpm to address process automation in my organization.. I am still watching with hopeful eyes.. :-)
Krisna,
ReplyDeleteFrom your comment, I didn't get why you think that this post leans towards 'old school thinking'.
I tried to show that current tools and technologies don't realize enough the fundamental difference between analysis and implementation. As a result, most solutions don't serve both the analyst *and* the developer.
Someone (or sonething) has to translate between the analysis model and the executable model. In the general case, it can not be expected that any analysis model can be automatically translated into an executable model.
regards, tom.
Tom,
ReplyDeleteMy observation of old school thinking, stems from the belief expressed as "if processes need to be defined and executed, then there must be a BPMN followed by a BPEL essentially in that order". New age frustrations are stemming from these kind of rule enforcements and an increasing tendency for intuition based thinking-realisations.
I agree with your joting that there exists current implementation gaps in model translation into block based BPEL executions. But such constraints need to be viewed as opportunity as Cordys has already done.
To be honest, the roles are fast changing expecting professionals to transcend between analysis and quasi/meta-implementation, seamlessly. And technology needs to get there to simplify not obfuscate.
To give an example, if I don a business thinking hat and I look at the jboss product architecture diagram, I am telling myself, I need to do this function, now what all do i need from this. Technical answer -" Uhh Sir, we will hv to study ur requirements and u will need this, this, this ,this and this..." Biz - "Well How am I going to get there?" - Tech - " Well sir, we sell products , there a lot of SI who u can engage to study and configure and give u a plan for implementation" Biz thinking "$$$$$$$ flying already and getting nowhere so far..."
See u get the picture... When they need to see things happening to justify the cost-to-function allignment". That is one of the reasons, that IT-Business Allignment has become the most significant problem that CXOs are finding it difficult to deal with..
So when tech-provider guys come by with solutions which easily depicts business AND convinces the ease of translating their thoughts into easy/quick implementations, its a kill.
From my personal experience trying to get process automation, into a business context, most tech providers are after the hype, utopian sale pitch and after the product sale , with not enough consideration given to the root cause of the matter - the business need and its perception of that need.
I have been a longtime developer,analyst, manager and now business facilitator to conclude, that as providers, we have a long way ahead and bright future as long as we don't lose the fundamental reasons out of the focus.
Thanks and Have a great day
regards
Krishna Iyer
LinkedIn - http://www.linkedin.com/in/krishnaiyer
**********************************************************************************
However far we have come, We can ALWAYS go further.....
Let's make systems better !!
*********************************************************************************
"
ReplyDeleteMy observation of old school thinking, stems from the belief expressed as "if processes need to be defined and executed, then there must be a BPMN followed by a BPEL essentially in that order"
"
i agree that is not good.
"
New age frustrations are stemming from these kind of rule enforcements and an increasing tendency for intuition based thinking-realisations.
"
Indeed. There is a lot of hidden limitations to the magic of typical BPM products. We want to do less magic and support both ends of the dual nature: the business side *and* the tech side. In this story, don't promise so much, but at least we are able to deliver.
"
I agree with your joting that there exists current implementation gaps in model translation into block based BPEL executions.
"
With BPEL the gap is huge. With jPDL, the gap is already a lot less. The aim is to reduce the gap so much so that business can still read and discuss the diagram of the tech models. That is feasible. Automatic production of software from by non-technical person is not feasible IMO.
"
And technology needs to get there to simplify not obfuscate.
"
Exactly. IMO, the automagical stuff in BPM and the overpromising is often creating confusion.
regards, tom.
TIm et all,
ReplyDeleteI am sure you agree that there is a lot of value in what you draw is what gets executed.
The difference in understanding stems from the fact that you overlook the fact that the process design (by business analyst) and execution (by IT users) can be two views of the same shared metadata.
If you start looking at the picture from this perspective, you would see the advantages of this approach.
more here: http://vishals.blogspot.com
Thanks
Vishal
Vishal,
ReplyDelete"
I am sure you agree that there is a lot of value in what you draw is what gets executed.
"
My point is that this works if automation is the goal of the modelling and that the business analyst has some notion of a computer system. But even then there are a lot of glitches and potential pitfalls to slide into complexity.
IMO, the round trip should be on an executable process language. Currently, BPMN has a big attraction for non tech business analyst. I'm convinced that you can't keep that attraction if BPMN would be an executable.
This post tried to show that I see the roundtrip only feasible on the executable process model. The analysis model only is the first input. Then it is converted to an executable process as a one shot translation. Then the business analyst will still recognize the diagram (in case the executable process language is flexible enough). From then the iterations should happen on the executable model only without an attempt to synchronize the analysis diagram.
UML class diagrams tought us that sustained synchronization between the analysis models and implementation models is just not done in practice. I don't believe BPM will be different in that respect.
regards, tom.
Tom et all
ReplyDeleteCurrently I'm studying on the workflow language YAWL, yet i cannot immediately determine whether it lent to the analysis field or executable field. As a system called YAWL is provided to support this language running, it seems to be a executable process. Yet it claimed to support most workflow patterns, from which i see analysis or business more or less. How will you comment on that? Glad to hear about your ideas.
Thanks
Hongchao Nie
Thanks for this great post, Tom.
ReplyDelete"Some analysts use very expressive diagram notations, while others just use boxes and arrows. But even in case a lot of details are expressed in the diagram, they are not necessarily expressing runtime execution semantics in the software sense of the word."
I especially agree with this part. One just has to think of annotations used in BPMN.
"In practice, it turns out that the roles are not that clearly separated. In fact, a lot of business analysts have technical knowledge so they already are able to think in terms of what it means to execute the software."
This is another good point to mention. I recently took a look at a diagram somebody from a non-technical perspective but with some knowledge of the systems going to perform the actual tasks came up with. The roles he used weren't wrong but could not really be used to make the diagramm an executable process.