3 Approaches To Transform Analysis Diagrams Into Executable Processes

Finally a good blog discussion related to the reason of existence for Business Process Management (BPM). It's about how analysis diagrams get transformed into executable processes.

Scott Francis' post Compliance for the BPMN Specification… Shooting the Moon? already gives real good comments on the recent blogs. That is what triggered me to put the approaches that I know of in a list.

When considering BPM as a management discipline, the goal is that the business people should be in control. So business people, which usually don't have a lot of software development skills, create diagrams to document how people and systems work together. These I'll refer to as analysis diagrams. In this context, BPMN is currently getting a lot of attention.

On the other hand, it might be decided that software support for these processes will be developed. In that context, an executable process is a piece of software that can be executed on a BPM System (BPMS) and which also has a graphical representation. The only real executable process language standard currently around is BPEL. But BPEL targets what I describe as a completely different use case, namely service orchestration.

That brings us to the obvious question of how are analysis diagrams different from executable processes and how to bridge between them. This is where *finally* an interesting debate is starting at the heart of BPM.

Here are the 3 approaches:

1) I'll start with our own approach, as of course, that is the best :-)

We believe that analysis diagrams can be created in many notations, BPMN being one of them. Then it is up to the IT department to select the best process language that fits with their needs and then produce an executable process that looks exactly like the analysis diagram. That way the diagram remains an excellent instrument in the communication between IT and business people. But as an executable process is actually software, it should te governed by the IT department. In a previous post about BPMN 2.0 I elaborate a bit more on how we see the collaboration between analysts and developers.

This approach is quite similar to those who claim that we should move to executable BPMN. BPMN 2.0 will most likely incorporate explicit execution semantics for all the diagram elements. I believe that this is a very pragmatic move by Oracle and IBM as they have BPEL products and pure-play BPM products in their portfolio. For the pure-play BPM products, the executable BPMN route basically puts the translation to an executable process under the hood and makes it therefor irrelevant. That way, the pure-play BPM vendors are not forced to use BPEL underneith as the mapping between BPMN and BPEL is basically broken.

But in our view, a naive adoption of making BPMN executable can easily lead to trouble. It's generally accepted that process diagrams need to be decorated with technical details before they can be executed on a BPMS. Most of thos technical details that do not translate to the business side.

But the same is true the other way round: be very careful with expressing too much business level details in the diagram as they might not translate to the executable process. So you want to keep those out of sight of the business analyst. In many cases a lot of those graphical notation bells and whistles are actually technical details. So if the naive way of making BPMN executable results into graphical programming, then it is not suited to support BPM as a management discipline. Business analysts should be able to model freely without being constrained by technical details.

So in conclusion, the primary focus of bridging between analysis diagrams and executable processes should revolve around just the basic boxes and arrows. That is the intersection that can facilitate communication between business and IT.

2) Another approach is roundtripping. As said above, most people have realized that this is basically broken... unless... You can develop so much tooling around it like Oracle or IBM. With a vast amount of tooling a BPMN diagram can be translated to an executable process in e.g. BPEL and then synchronization links can be maintained so that roundtripping becomes an option.

The downside of this is that the user actually has to maintain the synchronization links. A lot of effort will be spend by the developer team to feed in the synchronization information. And still the changes that are generated to the executable process when a business analyst updates the analysis diagram, will never be transparant. In most cases. the development team will still have to intervene and merge the changes and verify the interactions between the process and verify the correct operation of the process in the context of other related software components.

And IMO, some teams might spend the time to maintain 2 models and keep them synchronized, but in general, I think this is undermining a big part of the agility value of BPM.

3) The third approach I'll discuss here is expressed by Ismael Ghalimi in Why BPEL Matters.

In their approach comes down to mapping BPMN to BPEL. But he also adds that the resulting BPEL process should be considered as the bytecode.

In this approach there is a believe that an analyst diagram can be decorated with technical details to make it executable. I don't see yet how this can lead to anything else then graphical programming.

I'm really puzzled by this approach as it seems to me that it is taking the worst of two worlds. On the one hand, they create a hard link between the analysis diagram and the executable diagram which blocks the analyst from modeling freely. And secondly, why would you perform a clumsy translation to BPEL if it's kept under the hood? I could think of easier ways to execute BPMN natively then through a translation to BPEL.

If BPEL should remain under the hood, then I don't get why BPEL is so important? I agree with the standardization argument. But they are also building SimPEL, which he describes as a different syntax for BPEL.

Another point that I wish to challenge is that BPEL supports distributed transactions. Afaict, BPEL doesn't specify when the state of a process should be persisted and it doesn't state how that persistence should participate in a transaction, let alone how it should participate in a distributed transaction that spans multiple systems.

Let me know if I'm missing something.

3 BPM Blogs You Want To Subscribe To

Here are some top notch blogs that I have *have* to recommend:

1) Leadership BPM by Rashid N. Khan

Last year, Rashid retired as the CEO of Ultimus and now he started a blog in which he shares his vast amount of experience.

During this period I was involved in 100s of BPM deployments worldwide and collected a wealth of experience. Now that I have retired from Ultimus, I want to leverage this expeience and help senior executives to learn about and benefit from BPM and related technologies. I have a unique perspective and I have been very focused on the practical, nuts-and-bolts issues about BPM that senior executives have to understand if they are going to fully realize the potential of BPM.

The nice thing is that he now can give an independent, unconstrained look on things. Opinions of that skill and which can speek freely are hard to find.

In What it will take to deliver BPM as SaaS?, he already seems to pinpoint the crucial conditions of the latest BPM as a service hype.

In my judgment BPM SaaS has to have the following characteristics as a minimum. First, it must have the ability to model and modify executable processes in a hosted application. The ability to design executable processes, in contrast to simple flow diagram, is pretty challenging. ... Second, BPM SaaS must have the ability to allow customers to integrate with their inside-the-firewall data and other applications. This is crucial because BPM deals with company’s data and interacts with other applications. Without effective integration only the very simplistic BPM processes are candidates for SaaS, and CxOs are reluctant to invest money or mindshare on simplistic processes. Integration is the Achille’s heel of BPM SaaS and solutions for this will evolve only gradually. Perhaps the best approach for BPM vendors is the emerging class of "application appliances" that leverage virtualization technology to deliver inside-the-firewall solutions on a SaaS basis. This has the potential of solving the integration problem. I will discuss it in another blog as this is a topic on its own. Third, and easiest, is the ability for end-users to participate in business processes using a browser. ... Fourth, BPM SaaS must provide a means for customers to monitor and administer their processes over the Internet. Again, with the emergence of AJAX and RIAs, this is not a challenging obstacle. And fifth, BPM SaaS must provide some web-based reporting, BI and BAM capabilities.

In Is the BPM Industry stuck in no-man’s land?, Rashid starts by pointing out that BPM systems didn't get to the mainstream as they always envisioned:

Even if I take a conservative forecast and assume that the market was $1 billion in 1998 and growing at 15% per annum, it should be at least $4 billion today. But the most recent forecast continue to put it in the $2 billion range. So where does all the growth fizzle away? Second, every BPM vendor and analyst can provide a number of actual case studies of BPM deployments that demonstrate remarkable ROI and productivity benefits. And it is relatively easy for senior management to understand why BPM can deliver such results. Yet the penetration of BPM in organizations is still small and I would venture to say that less than 10% of processes are automated despite all the ROI and productivity proof points. Third, every year BPM vendors claim impressive growth and publish a roster of new customers. Yet most pure-play BPM vendors are relatively small companies and none have been able to go public despite the claims of growth and the fact that many of them have raised tens of millions of dollars in venture capital.

This is exactly what I thought as well and in my opinion this is largely due to the fact that executable processes should be part of the software applications themselves. The big problem still to date is that BPM Systems are considered as monolithic applications that are hard to integrate into a software development project. That is exactly the problem that we have focussed on in jBPM since the very beginning. And indeed it is not an easy one. Rashid seems to come to a similar conclusion:

First, BPM sounds glamorous, but it is not easy. This is because human beings work in extremely complex ways. Developing software that caters to all these ways is not easy. The “human interface” of BPM is complex and challenging. Second, the IT environments in which BPM has to thrive are very complex, varied and in constant flux. BPM cannot be successful without seamless integration with the rest of the IT infrastructure.

I hope that Rashid keeps up sharing his points of view.

What's cool for me is that when I started jBPM, Ultimus is actually the first product I looked at to see what the competition was like.

2) Small steps with big feet by Joram Barrez

Joram is a BPM and jBPM guru that I had the opportunity to collaborate with on a few occasions. For all your jBPM performance concerns, make sure you read his blog or get him involved. He tweaked jBPM performance better then we did !

His latest blog Blogs about jBPM you don’t want to miss! provides links to a lot of interesting jBPM related posts that are very informative.

3) PlanetjBPM by Ronald van Kuijk (aka kukeltje)

Ronald provides great practical tips and tricks on jBPM. He's another BPM and jBPM guru calling himself rightfully the jBPM Forum Addict. In practice this means that he helped thousands of people getting started with jBPM over the last 5 years by answering basically every question on the jBPM user forum.

BPEL versus BPM

Pierre Vigneras wrote a nice article on InfoQ about how BPEL is not the right solution for BPM. As you might know that is what I have been saying for a long time. Also the discussion that follows the article is quite interesting.

Seven Forms Of BPM

My article Seven Forms Of BPM with JBoss jBPM just got published on dzone. In this article, I explain 7 distinct concrete forms of BPM. Some are more business oriented and some are more technical oriented. BPM is a hugely overloaded term, resulting in a lot of confusion. Hopefully this article helps to clear out at least some of the confusion.

If you don't like clicking your way through the pages, consider the printer friendly format of the article.

How Are Services, Data And Processes Tied Up in an SOA?

After reading InfoQ's report on Fred Cummins' essay about the data in an SOA, I thought the discussion could get a lot more concrete if we added an overview picture in the mix. Here's my take on how applications, services, data and processes are related.

Please ignore my absent taste for colour and drawing skills :-)

Applications and functionality is typically developed in application silos. Sometimes they come as Commercial Off The Shelf (COTS) products, sometimes they are custom build applications. Fred touches on an interesting topic with

"
Those who focus on data management have, for decades, driven the industry toward consolidation of databases under a philosophy that tighter coupling means greater efficiency and consistency.
"

Since the increased focus on integration technologies and SOA, there is a common misconception that tight coupling is bad. For integrating disparate systems, that is typically true. But inside of application silo's tight coupling is typically a good thing.

An application silo usually manages data and it includes support for the related business processes. These processes can be implemented by an embeddable BPMS or they can be just as well coded in a programming language. These processes can have all the characteristics of processes implemented on top of the ESB in e.g. BPEL. They are long running and transactional, they can include human tasks as well as service invocations to services on the bus and so on. Application silo processes are only distinct from the processes on top of the ESB in the sense that they are an integral part of the application silo and therefore they are hosted in a different environment like e.g. Java instead of XML/WSDL. That is where the value of the jPDL process language comes in. It's really embeddable and it integrates very nice with any Java environment. That's why jPDL is embedded a lot in Java based portals, Enterprise Content Management (ECM) systems and custom Java applications. It's really fit for this tight coupled Java environment.

Each of these application silo's typically has a functional interface that exposes the operations supported by the application. A User Interface (UI) can then expose the functional interface to users and the same functional interface can also be exposed to the Enterprise Service Bus (ESB) via a Service Adapter.

The main purpose of an Enterprise Service Bus is integrating disparate systems. So it's typically XML/WSDL based. If many events and service invocations are published on the ESB related to one business process, then it might make sense to track the overall process with an ESB-level process. BPEL is the ideal process language for this environment.

What not a lot of people realize is that the location of business process implementations can be freely picked. If most of the accessed functionality and data for a given process is related to one application silo, it might make much more sense to implement it inside of that application silo. Still in that scenario, services can be consumed from other systems over the ESB.

On the other hand, if the process must integrate with many disparate systems, most of the events are already published on the ESB and there is no application to which this process clearly belongs, then it's most likely easier to implement it as a BPEL process on top of the ESB.

The main point I have tried to make is that the implementation of Business Processes should not be tied to integration technologies (read: the ESB). They can be just as well located within the application silos.

This also exposes one of the difficulties in mapping the analyst's business processes to implementation level processes. Analysts draw boxes and arrows in a diagram and they are not really concerned with this architectural background that provides the environment for implementing those processes. So an analysis process still has to be mapped to executable process languages in application silo's or on top of the ESB. This is not always a one-to-one mapping.

Task Assignment And Pools Harder Then You Think

Workflows and business processes are often perceived as simple in the sense that non technical people can draw diagrams that can be executed. John Reynolds explain a typical example of task assignment in Getting tasks to the right participants - Part 1:

“When a Loan Application comes in, make the application available to all of our Credit Officers who have sufficient Lending Authority to process the loan, and who haven’t already met their quota of applications for the week. Of course if everybody has already met their quotas for the week, then let everyone have an opportunity to work on the new application.

One more thing, only a few of our Credit Officers can approve loans over $100,000, so don’t route low value loans to them unless they are the only available credit officers.

And don’t let anyone claim more than 3 applications at a time. Our Credit Officers are compensated for the number of loans that they process, and some of them will claim all the applications that they can in hopes of earning more money.”

This really sounds like a realistic task assignment to me. My point here is that it's impossible to capture this kind of logic in the business process diagram. It reinforces the message about process development that I've been giving for a long time. Analysts provide a description of a business process. Typically that is a diagram plus free text documentation like e.g. this kind of task assignment rules. Then it is up to the process developer to come up with an executable process that looks exactly like the business analyst's diagram, but this time it is an executable process. Iterative development can then be realised on the executable process. I don't believe that round tripping between analyst and implementation models is feasible for the majority of BPM use cases, especially if those turn out to be very different.

The second post that I refer to is Bruce Silver's BPMN to Requester: Get Outta My Pool. In that post, Bruce points out that BPMN swimlanes are in fact inspired by BPEL's partner links and that experienced business analyst have a hard time understanding those basics. In fact, I think the business analysts are right. Analyst models should not be constrained with executable details. If we want to create a notation that can serve analysts and process developers, then it should be nothing more but boxes and arrows. All the extra semantics that are added to diagrams only are targetted to either the analysts or to the developer. But those extra semantical decorations and concepts never make (the same) sense to both target audiences.

This really shows the scheziphrenic nature of BPMN. On the one hand BPMN aims to be a free modelling notation for business analysts. And on the other hand, it tries to map one on one to an executable service orchestration language like BPEL.

Brewing The jBPM Community

Our managers were a bit concerned at first. "Are you sure it's a good idea to have an IT event in a beer factory?". Of course it is...

Last Friday, we had the jBPM Community Day. A rememberable day it turned out to be. We assembled the full core of the jBPM contributors from JBoss and other companies at the Guinness storehouse in Dublin. More then 40 people showed up, of which half of them flew in specially for this event.

The three muscateers arrived. The first thing they noticed was this thing that looked like a spaceship mounted on top of the beer factory.

Finding the way to the room took some concentration.
But most of us made it before the Master of Ceremony kicked it off.
We gave most of the platform for talks to core members of the community. That turned out to be a bulls eye.

Joram Barrez started addressed any performance question that people in the audience might wonder about. Also he showed the value of how easy the Business Intelligence information could be extracted from jBPM process executions.

Next, Mark Proctor managed to sneek in a Drools-spy into our jBPM event.
Paul Browne talked about the situations where drools rules and jPDL processes make a perfect match. Both Joram and Paul are great speakers and they know what they talk about. Thanks a lot, guys!

Then it was time to do some sightseeing in the building.
And to taste the Guinness at the gravity bar (the space ship thing).
An awsome, full 360 degrees view!
After that pint of Guinness, my short talk was scheduled. Next time we need to have someone that pulls the plug when I go over my time limit again :-)

Then we splitted the audience in two separate tracks. The core contributors went to discuss the future of the project.
Ronald (aka Kukeltje) showed how to hold a Guinness so that your neighbour doesn't see it and with the other hand answering forum questions at the same time.

On a more serious note: this is where the most constructive feedback was generated. We had a great brainstorm session on how we can improve the migration path from jPDL 3 to the upcoming jPDL 4.

At the same time, the other people users got an introduction to jPDL from Koen Aers, the creator of the jPDL eclipse plugin designer.

The reception dinner closed a fruitful day.
Then we went down to the temple bar area and the Master of Ceremony found this great pub with live music.

But with strickt rules !
The 2BInternational team met with the locals and showed us that they had more moves then only in Business Process Management.

But then things started to get messy.
So I concluded it was time to stop taking pictures :-)

Oh... and there was a memorable close of this memorable evening. When walking to the hotel, I came across this die hard artist still out on the street doing a perfect inpersonation of Mark Proctor. Awsome!
Amen.

High-Quality Free BPM Book

Thanks to Sandy Kemsley, I found Michael Zur Muehlen has published his very nice e-book online. No registration required so definitely have a look at it. Even though the book seems to be a couple of years old, it includes a thoughtful and still very relevant description of BPM as a discipline and the relation to BPM software technology.

Dublin, Here We Come !

The jBPM Community Day on June 6th is starting to become a real international event with people coming from Belgium, The Netherlands, France, Germany, Italy and Ireland of course.

The program is updated and gives a good idea of what's going to happen. Also a list of hotels and activities is added (thanks, Paul!)

Don't miss it ! Be sure to registration quickly. It is as easy as sending an email to dublin@jbpm.org

BPM != BPEL

It seems to be a very stubbern misunderstanding that I have tried to straighten out many times before. But for those that didn't get it yet, even John Evdemon, co-chair of the BPEL technical committee said already in 2007 that BPM != BPEL and now in the recent BPMN discussion he adds: If you can do something it doesn't mean that you should...

HTH

Buzzwords In Pictures

Sometimes you can find good explanations of tech buzzwords in real life. So far, I found out what Ajax, SOA and backup really means.

If your HTML-over-HTTP-house is on fire, the Ajax hose comes to the rescue.


If your integration stinks like a sewage system, just put a SOA cover on it.


And a backup is even more vital then I ever imagined.

I'll translate for the non-dutch speaking: "Even mother nature provides a back-up" And in the round circle it says : "Test one month for free". Sign me up ! Sign me up !

Big Problems Ahead For BPMN 2.0 ?

Boris Lublinsky posted a good overview on InfoQ about the online discussions around BPMN 2.0 and it reveals IMO a very profound problem in traditional BPM thinking.

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 ?

jBPM Community Day in Dublin On June 6th

The jBPM Community Day in Dublin is a great opportunity to learn more about jBPM, the Process Virtual Machine or JBoss in general. The core jBPM developers and key members of the community will be there in a relaxed atmosphere. It's just friday afternoon on June 6th. There will be some informative sessions, guinness entertainment and plenty of breaks to network and talk to others in the jBPM community. Lunch and evening meal included and it's free ! What more could you want :-)

Click here for more information about this great event.

You can register by simply sending an email to dublin@jbpm.org with your name in it.

I hope to see you all there.

Process Virtual Machine Alpha2 Released

The Process Virtual Machine is a simple Java library for building and executing state machines. It can optionally store process definitions and executions in a relational database. The Process Virtual Machine serves high level BPM as well as low level Java state machines. It serves as a foundation for several process language implementations like jPDL, BPEL, XPDL and Pageflow.

This second release adds a deployer architecture, enterprise bindings and documentation about the persistence of processes. It further improves the stream handling and the job executor.

Check it out !

The Process Virtual Machine Homepage
Documentation
Download

Enjoy and let us know what you think of it.

JavaPolis Refactored To Javoxx

JavaPolis becomes Javoxx

"
New name
New logo
Same Concept : Giving a voice to the Java community
"

Check it out on the JavaPolis website, On the Javoxx website and at Parleys.com

Mark December 8-12 in your calendars, book your flight and hotel and start packing your bags. This is a mandatory excursion for each self respecting Java developer. This is one of the few situations where I'm happy to fulfil my obligations!

In Depth Analysis Of OSS BPM By Jason Woodruff

Jason was able to extract our grand vision perfectly from the bits and pieces that we've published here and there on the forums, articles and website.

Congrats, Jason.

jBPM Nominated For JAX Innovation Awards 2008

Cool! jBPM has been nominated for the JAX Innovation Awards 2008. The Award Ceremony will take place in the course of the JAX Conference on Wednesday, 23 April.

This got me worried about what we're going to do with the prize money *if* we happen to win it. It sparked the idea of a jBPM Event. We could spend the money on flying in people from the community over to our event.

We already selected Dublin as the place to be and probably June 6th as the date. Mark that date in your calendar ! Chances are good that it's going to happen anyway. So we feel like we've won already, regardless of the outcome :-) But still we hope that we win some prize money to bring lots of community people, partners and clients to our event to share experiences and have a good Guinness together.

Let's keep our fingers crossed...

Awsome jBPM Performance Numbers

Couple of weeks ago I saw a great presentation by Joram Barrez of Dolmen called "The Full Stack". Basically he showed how they selected jBPM and SeeWhy and composed it into a full BPM solution. Since I went to the event with not much expectations, this was a pleasant surprise. Things became even more interesting when Joram showed the performance tests they did to see if jBPM would meet their demands. We wanted to do those tests for ages, but never got to it. So big thanks, Joram for sharing them with us !

As you might know process execution in jBPM can happen with or without persistence. These measurements are done *with* persistence, as this is the most common way of how jBPM is used.

He started with the simplest process. That took 2 milliseconds to execute.
Then a processes that grew longer and longer:

Then he verified the effect of simple and complex process concurrency:


Amen.

So even this complex process runs with only 12 ms overhead of jBPM ! Awsome. Even I was surprised :-)

And the last test was a complete realistic process of handling a hospital report. That took 3 milliseconds to execute.


All of this shows that the overhead created by jBPM runtime process management is really small. Doing the statemanagement of such processes yourself will lead to a lot more development time, and in many cases, the performance will not be as optimized as just using jBPM.

This only highlights the performance evaluation part of the talk. I definitely recommend to read his blog post about the full contents of Joram's presentation.

First Release Of The Process Virtual Machine

We've been talking about it for a long time. And we've been working on it for even much longer. And finally, the moment of truth is here. The first alpha release of the Process Virtual Machine can be downloaded. Documentation and Javadocs are also available.

The Process Virtual Machine now also got it's own home page.

This marks an important milestone for the jBPM project. It's the finalization of our approach to support multiple process languages and embeddable BPM.

But don't wait any longer. Go download it and start building your first processes and process activities.

Complete Refresh Of The jBPM Website

JBoss jBPM has a renewed website. A serious update was long time overdue. We took the time to put the soul of the project into the website. Multiple subprojects now are very prominent, highlighting the fact that jBPM supports multiple process languages. An overview section helps people to understand workflow, BPM and how we approach it.

This new site is part of a larger effort to focus more on building the community further out. Previously we already announced the new logo. We now have about 20000 downloads per month, but we won't rest until BPM and workflow is a ubiquitous part of software development.

Special thanks goes to Koen for making it happen.

My Concluding Nuance On BPMN

Before I try to summarize my position, I'll reference all the related blogs in this discussion:

Michael zur Muehlen: How much BPMN do you need?
Bruce Silver: On How Much BPMN Do You Need
Michael zur Muehlen: Who is at fault - the language or the speaker?
Bruce Silver: Michael Elaborates
Me: The Hottest BPMN Process Modelling Debate, BPMN Conformance Sets And Unrealistic Ambitions and The Devil Is In The Technical Details
And overviews from InfoQ and Sandy Kemsley.

After the above and another good discussion at the Dolmen event: Do’s en don’ts van Business Process Management yesterday, I would like to give another shot at summarizing my point of view around BPMN and indicate where I see most misunderstandings around analysis to implementation.

BPMN can be used for analysis. In that sense, the BPMN analysis model is a model or a description of the real world. BPMN can also be used to represent executable process languages. But in that case the BPMN diagram represents a piece of software.

So my point is that, in general, it is impossible for an analysis model to automagically be translated into an implementation model. Even while for both models BPMN can be used, at some point, the purpose of the model changes. I believe that the purpose-change from analysis to implementation can not and should not happen automatically or transparantly.

In some cases, the BPMN model representing the executable process could very well be exactly the same as the original analysis diagram. In fact, the better the executable process language, the closer the implementation diagram will be to the original analysis diagram. William Vampenepe's post already shows that BPMN to BPEL doesn't really succeed in that goal.

BPMN to XPDL would be much closer, but XPDL doesn't really aim to be an executable process language.

BPMN to BPEL: Lipstick On A Pig?

Yesterday I came across William Vambenepe's blog post: BPMN to BPEL: going to battle with one hand tied? It shows that if you translate a simple BPMN model to BPEL, the BPEL process is not really recognizable any more. It seems to reconfirm my initial estimations about that kind of transformation.

I'm happy with the rapid adoption of BPMN in the BPM world. But I was always puzzled by the big focus of the BPMN to BPEL conversion. I have not done the excercise myself of trying to write an algorithm that did such a transformation because the models just don't seem to fit. BPEL is a composite (aka block) structured language. BPMN is graph based. BPMN is focussed on process analysis, while BPEL is about orchestrating web services. And in my experience, the non tech business analysts don't think in terms of web services.

The Devil Is In The Technical Details

My reply to Bruce's comment got out of hand so I decided to publish it as a separate post.

For the sake of the discussion, let's zoom in on the part where we see different things :-) I understand your point of view as focussed on the modelling side. Then you see some vendors that can take a BPMN model, add details (be it visible in the diagram or just properties) and then this model becomes executable:

"
BPMN is just the model, the activity flow in abstract sense. The implementation properties of each activity, event, or gateway are layered on by developers. Not in code, but using the visual tools even those guys like to use. And not stored in BPMN attributes, but in the tool-specific metadata that drives the executable language.
"

I doubt the general feasibility of this approach.

First, this implies that at least some visual model constructs that can be used during analysis have a runtime meaning. There are different kind of analysts. Some have a tech background and they know that this process is going to be executed on a computer system. Some don't. Analysing a business process, means trying to understand the business problem and describing that. The analyst might use all the BPMN constructs for that not knowing what that these have a runtime meaning on a computer system. An executable model is software that is to be run on one system. I think that in general, there always needs to be a human translation from the analysis model to the executable model, even if both the analysis model and the executable model can be expressed in BPMN.

With jPDL, we have focussed on modelling freedom, which means that the executable process diagram should look exactly like the analyst diagram. And that was not trivial. Important concepts are listeners (aka actions) so that a developer can associate callbacks on specific points in the process. Another concept is that the runtime behaviour for nodes doesn't have to come from a fixed set of process constructs. Instead, if the analyst has a really weird requirement in a specific node (aka activity), then the developer can code the runtime behaviour for that node in a plain programming language like java and hook it up in the process.

I think that an executable process language needs those kinds of features and a lot more to really keep the same diagram. I think it is often overlooked that analysis and implementation are two different things.

So the simple waterfall model of adding implementation details to an analysis model doesn't cut it for me.

The second part where the pure plays will keep having a problem with the development teams is embeddability. Instead of having a separate monolithic BPMS that has to be connected to applications, I have seen that the developer community likes it much more when the BPMS logic can be embedded into their own applications. And the BPMS database can be a set of tables right next to the application tables. That is what the operators like: Since the BPMS is part of the application, it reduces the number of systems that need to be managed and hence simplifies IT operations.

To support embeddability, BPMS vendors like us need to support all the DB's out there. Next, the application domain model needs to be coupled seamlessly with the process executions. E.g. the Order hibernate entity (or ejb), needs to be linked bidirectionally with the Order process. That is something that we can offer on a API level basis to developers.

I didn't yet see another executable process language then jPDL that can offer that level of convenience to the developers. IMO, it is not possible to get this level of convenience for developers if you start from the analysis model. Somewhere you have to turn requirements into a software design.

Without this translation idea, in all other executable BPMS systems I have seen so far, executable details ripple through in the tools offered to the analyst. And in the niche markets where those vendors are active now, a lot of analysts have some technical background. But if we want to make BPM and workflow a ubiquitous technology that is in the repertoire of every IT team, we have offer it in a way that is easily consumable for IT teams.

One last parting thought, inspired by the vendors that you reference. What do these vendors have different then what Ultimus had 5 years ago ? That was the first vendor I looked at when I started. At that time, they already had a very complete product. How come they (and so many others in that field at that time) were not able to gain any significant market share. Instead it seems like BPM vendors come and go all the time. None of those is able to get beyond a certain treshold of adoption. I think this has to do with the fact that BPMS tools sell easy to CXO's, but it is very hard to make a BPMS that is attractive to developers. IMO, it's the IT team that should select a BPMS, not management.

Thanks Bruce, with this awsome discussion, it certainly got out the best in me :-)

BPMN Conformance Sets And Unrealistic Ambitions

In the recent BPMN discussion, Bruce clarifies that he also sees a partitioning in BPMN:

"
The SIMPLE conformance set includes task, collapsed subprocess, gateway (exclusive data-based and parallel), None start and end events, pool, lane, data object, text annotation, sequence flow, and association.

The STANDARD conformance set includes task (task type User, Service, Send, Receive); collapsed and expanded subprocess, looping or multi-instance activity, gateway (inclusive, exclusive data-based, exclusive event-based, parallel), start events (None, message, timer), catching intermediate events in sequence flow (timer, message), throwing intermediate events in sequence flow (message), attached intermediate events (timer, message, error), end events (None, error, message, terminate), pool, lane, data object, text annotation, sequence flow (uncontrolled, conditional, default), and association. [Looks like we left out message flow… not sure why.]

The COMPLETE conformance set includes the full BPMN 1.1 spec.
"

This is very close to (and much more concrete then) the levels that I envisioned. That puts our opinions indeed much closer as I initially estimated. Especially if you only look at the modelling perspective, then I totally agree with you, Bruce.

So now, my only disagreement is not with Bruce, but with the picture that the traditional BPMS vendors paint. He describes it like this:

"
And, like Michael, the tool vendors factor into my thinking as well, in particular the BPMS vendors who support BPMN’s model-driven implementation style.
"

IMO, the BPMN model-driven implementation as pursued by most vendors is flawed. They see the executable language as the byte-code behind the BPMN model. Then round tripping is envisioned between the model and the "byte-code". I believe that it is impossible to let the non technical people drive the executable byte code.

Instead, I think it is much more realistic that the analyst delivers an initial analysis model. This model can be in 'the COMPLETE conformance set' as described by Bruce or it can be boxes and arrows on a napkin. Then this serves as the requirements input for the development team. The executable process language should be a selection of the development team. They can select a language that fits their architecture and the environment of the process best.

The clue is that a good executable process language would allow the developers to build a process that exactly looks like the analysts input. That way, the implementation model is structured in the same way as the analysis model. As a result, analyst and developer can speak the same language.

But crucial is that after the translation of an analysis model into an executable process, the responsibility is transferred to the development team. In subsequent iterations, the communication between analysts and developers can happen around the diagram, but it's the developers that should do the updates to the executable process.

With general purpose executable process languages, it's not possible to let the non technical business analyst modify executable software. The exception is in the specific process languages with a specific target and limited scope. For example a language to specify approvals in a document management system. In those cases, the analysts can build fully executable processes.

The round tripping approach that traditional BPMS vendors put forward tries to automate the translation of requirements into software design. That is, IMO, an unrealistic ambition.

The Hottest BPMN Process Modelling Debate

Just in case you didn't notice, a very important blog discussion is happening right now around BPMN. Bruce Silver is discussing with Michael Zur Muehlen about how BPMN is used, how it should be used and how it should be improved.

Michael: "How much BPMN do you need?"
Bruce: "On how much BPMN do you need"
Michael: "Who is at fault, the language or the speaker?"
Bruce: "Michael elaborates"

Bruce Silver is a BPM guru consultant. He advocates and teaches BPMN as a rigorous modelling notation. In his view process modellers need a very precise and expressive language so that a lot of details can be precisely documented in the shapes and decorations of a process diagram.

Michael Zur Muehlen is a BPM open academic with a practical touch. His point is that a better layering of the BPMN complexity is needed and that for most organisations, the more basic parts of BPMN are sufficient.

I very much appreciate both gentlemen. BPM minds like that are few and far between. In this case, I tend to agree with Michael. Michaels position reflects what I experience as well in the field. Depending on the culture in an organisation, only in very few occasions, modelling notations are used as mathematical science, in which case a lot of expressiveness is desirable and a lot of exact interpretation of the diagram is needed. In most cases, process diagrams are just drawings of boxes and arrows. We should not forget that multiple reports have indicated that Visio is by far the most used tool to draw business processes. If we assume that a majority doesn't use the BPMN Visio stencils, it means that many organisations now work without these precise modelling notations.

First, I think BPMN would benefit from a better layering. BPMN should introduce e.g. 3 levels. So that in a tool, you can choose whether you want to work in BPMN on level 1 (basics), level 2 (advanced) or level 3 (Bruce :-) ). Michael refers to the constructs already being divided into categories. If that is the case, it is certainly not prominent enough and a categorisation of the constructs is not enough. It should be verified that each level is a self contained language that is complete enough to satisfy a well defined set of modelling purposes.

Second, too formal is not good as it will get into execution semantics. That's why i indicated that maybe a third level will already be too detailed for a modelling notation.

Third BPMN should stick to being a modelling notation. That's what it is being adopted for. The properties can be removed and the mapping approach to concrete executable process languages should be left up to the vendors.

But when these discussions are settled, still the question is left open of how to translate these process analysis models into executable processes that can be executed on a BPMS. We as BPMS vendors tend to see this as the only possible use case of process modelling. But in fact, a bit more modesty is probably appropriate. We should realise that most business process models are not intended to become executable. But anyway, *if* a process analysis model is to be made executable, I think there has to be a translation to an executable process language. And such a translation should make sure that the analyst still recognizes the diagram of the executable process. That guarantees good communication between analyst and developer. After a process has become executable, it is software and it becomes the responsibility of the developer. Therefore, I don't really believe in the analysis to executable process round tripping. Instead, I think that that it is much more practical to have a one-way translation to an executable process and then iterative updates under control of the developer, but with good input from the analyst on the diagram level.

Anyways, all this side tracks to indicate that we at jBPM still have got couple of challenges left to tackle. Because our goal is actually to bring the usage and knowledge of BPM and workflow technology to become ubiquitous amongst IT teams. I know this has been envisioned before, I know this is ambitious, but I still think we're actually close to getting there.

For a long time now, we've been preaching about multiple process languages. Only recently I start to encounter left and right messages like 'multiple forms of workflow' and 'BPEL is not a silver bullet'. That is a done deal. We are finalizing the Process Virtual Machine that actually runs multiple process languages (like jPDL, BPEL and XPDL) natively. The other point is that embeddability is still underestimated. BPM products are still too much silo's that are hard to integrate into day to day application development. That is where we will be ready soon.

I'll be looking forward to the rest of that conversation.

The New jBPM Logo Rocks !

Back in the days I had spent a full two hours with MS Paint to create the first logo for jBPM. When it was done I was so happy with the result.

I remember it was just before JavaPolis 2004. Now that my project even had a logo, I was in full confidence. You know the feeling... Nothing could stop me now. So I went to the conference and immediately I got a lot of valuable feedback. All in the sense of "Hey Tom, you're project is great but your logo sucks bigtime!".

(Please put a curtain over your screen now and read on)

So this time I sticked to coding and left the paint job to the professionals. Even with my artistic skills I can see it's a world of difference. I think our new logo just rocks. But don't let me keep you in tension too long. Tataaaaa ! (you should pull the curtain from your screen now)
A small logo for this blog. But a giant leap for the jBPM project.

Can you see what it is ?

jBPM @ JBUG Benelux

This Friday, I'll talk about the Process Virtual Machine at the next JBUG Benelux meeting. These JBUG events are especially interesting since there is always a great interaction and lots of discussion that spawns from (and during!) the presentations. I'm looking forward to it.

Pete Muir will kick off with a 'SEAM In Action' talk. I saw Pete's presentation two weeks ago at JBossWorld Orlando and it was great. Pete is an excellent speaker and he's got some great handwaiving manouvres. Then I'll be talking about the Process Virtual Machine. And the last but not least, Bart Schuller and Daan Hoogenboezem will bring a testimonial about their experiences using jBPM. It's always great to get such direct feedback. Hopefully there is some positive in there as well :-)

For those of you more interested in the packaging rather then that content, the event will be hosted in Paddy Murphy's, an "vette" Irish pub in Rotterdam. Lunatech does the hosting of the event and we will take care of the Guinness.

I'm sure you don't want to miss this. Hope to see you there !

jBPM @ FOSDEM

I'll be speaking about "Workflow in Java" this afternoon from 15:00 till 16:00 in room AW1.120. Due to misunderstandings, this talk didn't make it into the conference guide. So this blog post is an attempt to avoid an empty room :-) Hope to see you there.

JBossWorld Recap

JBossWorld was last week in Orlando, FL. Of course, we took the opportunity to meet up in advance with the core JBoss developers. It still surprises me each time how the communication at such meetings can be intense, distributed, apparently anarchistic and yet extremely effective ...often even at 1am at the bar.

My presentation "A Lightweight Approach to Business Processes with JBoss jBPM" was in the very first slot. I always like that very much as jet lag and parties tend to undermine my concentration as the week progresses.

Met up with my good friends at SeeWhy. They might be able to contribute an initial version of the log/event generation in the Process Virtual Machine. The open source collaboration model in practice. Cool.

Same open source spirit for NexusBPM. Matthew Sandoz has already extended jPDL with new node types in the engine and in the graphical designer. Good to see that a long term vision becomes reality. We're happy that Matthew is interested to donate his contributions to the jBPM community and we will be assisting him in the process of doing so.

By coincidence, IDS Scheer's ProcessWorld conference was also taking place at the exact same location at the exact same time. I saw Sandy Kemsley blogging about it and pinged her to have a meeting. We definitely agreed that translating analysis models into executable software artifacts is not as easy as most BPMS vendors make us believe. For many other observations of the BPM market we thought very similar, which is surprising given our different background. Only when it came down to roundtripping between the analysis model and the implementation models of business processes, I seriously doubted if that was achievable, while Sandy had good faith that the big BPM players some day will find a way to make that transparant.

Another interesting meeting was with our new CEO, Jim Whitehurst. Everyone was enthousiast about the fact that he managed to analyse and express exactly where the problems are located in such a short period. Now our expectations him to get them fixed are very high :-)

A last anecdote that I would like to share is my jogging experience around the Marriott World Center. It turned out to be extremely difficult to find a track for jogging. Even the driveway to the hotel was a 4 lane street without cycle or pedestrian facilities. Eventually I saw a golf court behind a small pond and grass. There was a sign before the pond. I assumed it was going to be "Don't walk on the grass" and given my struggles so far, I was completely prepared to ignore it. But the sign didn't say anything like that. Instead it had a much more effective message: "Don't feed the alligators!". It worked for me :-)

SOA Done The Hard Way

You don't see many public cridible reports about results of SOA projects. So that's why Chris Muir 's testimonial is interesting.

The overall message in Chris' post is that there are a lot of practical problems between the dream and reality of SOA development.

"Just because the underlying Web Service communications allow you to communicate in a standard fashion, it doesn't mean the systems or organisations you communicate to are following any standards internally."

Top of the bill was:

"In addition only 1 of the 3 suppliers actually had test systems we could build our application against. And for the supplier that did have a test system we literally had to phone them to ask them to flush the data each time we did a test. So much for quick agile development."

But the post contains much more in depth insight about the practical things that can go wrong in SOA projects. Definitely worth a read.

It expresses very well how Oracle's Fusion doesn't really address most of the practical issues. In fact, they are very hard (if at all) to address. That's why I'm happy with JBoss' practical developer oriented approach that gives full control to developers. With the tool suite that we're building, we focus not to introduce unnecessary levels of complex indirections.

What is BPEL really ? And what are process component models ?

I included a very simple description of what BPEL really is in my article "Process Component Models: The Next Generation In Workflow ?", published at InfoQ. Basically the article is about different forms of workflow and Business Process Management (BPM) and it tries to demystify some of the common misconceptions around BPM. And at the end, a new approach to building embeddable runtime engines is introduced: Process component models. With process component models, it's possible to serve the different forms of workflow and BPM by executing multiple process languages natively on top of one core simple state machine library.

What Possesses These Open Source Developers ?

Joe Walker desrcibes it in a very realistic way for me:

"
The funny thing about getting heavily involved in an open source project is the roller coaster ride you embark on. There's the buzz from seeing the hits to the web server and reading what people think of your project. There's the gnawing feeling of responsibility when you discover very large websites using your code, and you're worried about bugs you might have created. There's the total flat feeling when a friend tells you they're taking your code out of a project because they prefer an alternative; and there's the burnout when you just can't keep up with the volume of work, and realize that a huge percentage of what you do is not directly development related.

My experiences with open source have opened a huge number of doors. I've met people that I wouldn't have met otherwise and had job offers that I wouldn't have dreamed of before. There really is a magic buzz to open source.
"

Right on, Joe!

Process Modelling And Process Execution

Jim Sinur talks about a lesser known aspect in BPM and workflow: the interaction of process modeling with process execution. He walks through 5 use cases of BPM and explains which tools that apply best: modelling tools or a Business Process Management System (BPMS, aka runtime process engine).

The part of it that I think is not enough known is the differentiation between the modelling tools and the process engines. The aim of modelling tools is to let the analyst create a diagram to help with documenting business processes. On the other hand, the aim of the BPMS is to track the progress of process executions and to execute the automated parts of it on a computer system.

BPMSs offer modelling capabilities, but since those models need to be executed later on, there is more to it then just the diagram. The diagram of an executable process will be more restricted then a diagram of an analysis model. Also the diagram of the executable process will be tied to software execution so changes to the diagram lead to changes to software execution.

There are some good tools for process analysis and there are some good BPMSs that support a graphical diagram view onto their executable processes. But making the link between those two worlds is not handled by today's technologies.

BPEL is known as a BPM language. It's an executable process language. And because of its focus on WSDL and executability, it is not suitable to let a non technical business analyst model a business process.

BPMN is mostly known as a graphical notation for business process diagrams. It's a good language for the business analysts, but creating easy and maintainable bindings to executable process languages is not yet demonstrated. Especially the gap between BPMN and BPEL is too big to keep in sync with round tripping.

So this leads to a software development cycle for processes that is completely similar to any other software automation project. Non tech business analysts can create analysis models. From analysis models, implementation models can be distilled. After that translation, the business analyst will only be able to see the implementation models in read only mode. The analyst will still recognise the diagrams, which results in a common language between the business analysts and the development team. That is a big added value that BPMSs can bring.

XPDL and jPDL have already today are most suited for aligning the executable process model with the analysis model. While BPEL is very complementary technology on an ESB, it is still very problematic in making the link between analysis models and executable models.

With jPDL 4 that we are currently conceiving, it will be possible to just add technical details to the analysis model and keep the original diagram as-is for the executable process. That is quite an achievement as the analysis model will not have taken into account persistence, transaction demarcation and concurrency details. Making all of those technical details fit into any Java application architecture is something that we can be proud of. But let's not make this into a jPDL blog.

The main message of this blog was that the link between modelling tools and process execution engines is still not as good as most people assume. Especially not with the two technologies that are mostly known: BPMN and BPEL. While the link between BPMN and BPEL is broken, both technologies can still be very usefull on their own.

BPM, A Peel Of SOA And The CIO Filter Syndrome

Jim Sinur kicks an open door and expresses the current general ideas around BPM and SOA in "What is the Nature of the BPM/SOA Codependence?"

I think in many ways the views expressed in that post are too limited and I'll sketch where I would like to see a broader vision. Since the tenor of the post is very representative for todays generally accepted viewpoint, I'll discuss that general viewpoint, even when it goes a bit outside this post of Jim.

In the BPM section, he describes that a human task that doesn't require a lot of thinking can be considered a candidate for automation:

There is another class of work that revolves around human activity where the knowledge level is not as intense and revolves around workflow-like activities. This work has also eluded automation at the level that a service would be needed.

The fact that the word 'service' is used bothers me. As if there no other forms of automation then a service. This particular phrase is an example of a broader mistake that I see with business level people talking about software. Their view seems to be limited to BPM and SOA only.

This is what I would call the CIO level filter. The CIO level filter only lets those parts of software development pass that can be understood by business people. BPM and SOA, but also rules fit into that category. Executable business processes and executable rules are in essence pieces of software. These languages try to create a representation that are understandable by non technical people. That is how they should be treated. All too often, non technical people tend to forget about the software nature of executable business processes and executable rule bases and discuss them in the plain english interpretation.

I believe many BPM folks miss insight on general application development to talk about software architectures. In my opinion, applications are developed in silos. Connectivity between application silos is enhanced with the typical SOA, WSDL, WS-* armoury. But BPM is much broader applicable then only on top of services.

There are many forms of process languages. Some of them like BPEL are only targetted at the services level. Others like jPDL are targetted to be used inside application development. So my point is that business processes, in the business sense of the word, translate over many layers of the software architecture, not only the services layer. Some business processes might be implemented on the services level only, in which case BPEL is a good candidate. While other business processes might be implemented as part of a Java application, in which case jPDL is a better option. Other business processes might be easier to implement in plain Java code.

Executable process languages come in different flavours and different habitats. The choice of executable process language should be a technical one. A company can manage their business processes better and more agile by leaving the choice for the process language to the technical team. All too often I see situations where the technology is selected upfront.

On Jim's SOA part, there is another occurence of what I would call the CIO filter syndrome:

The power of the SOA architectural approach is that it enables autonomous subsystems to be assembled into entities (SOA applications / processes ) that can be as cohesive externally as applications built with older architectural approaches (classic components, modularization, or object-oriented paradigm).

The benefit of SOAs over these older approaches is increased agility and greater tolerance for change throughout the life cycle of a system, especially compared with a system that assumes tight coupling and homogeneity across the subsystems.

I agree with the message that an SOA is all about increasing connectivity between loosely coupled components. The interoperability of WS-* infrastructure that is available today helps to simplify and speed up the connectivity problem. But that doesn't take away the applications at the end of the connectivity need to be build and developed. When building applications, tight coupling is a blessing. Without typesafety and refactoring, application development would take considerably longer. Without synchronous method invocations as in Java, applications would run infinitely slower.

So it's not new versus old. It's loosely coupled versus tightly coupled, knowing that inside an application silo, tightly coupling has great advantages. So I think that application development is as relevant as it was before, the only thing that was added recently is a set of standard technologies with which you can easily put a peel of SOA around your applications.

This still leaves the difficult task of the software architect to define what functionality is build in which application and what interfaces will be exposed to the SOA connectivity layer.

In summary, the CIO filter syndrome is that non technical business people try to come to conclusions about software architectures by only looking at the languages and parts of the architecture that they understand. Try to avoid it :-)