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 :-)