Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Friday, October 1, 2010

BLDD, BPEL, and BPMN - a first opinion

My good colleague Charles Moller asked me about in what BLDD would differ from BPEL and BPMN.

I will start by the easier part: BPMN. According to Wikipedia (from where I copied all phrases between quotes), it is "a standard for business process modeling, and provides a graphical notation for specifying business processes in a Business Process Diagram (BPD)." Since BLDD's proposal is to use any BPM notation to write specifications (possibly complemented by a textual language), BPMN is an option to BLDD.

Going further, "The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently, BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation."
In other words, as expected, BPMN can be used as an Ubiquitous Language (or a Shared Language, as I dare to call this concept).

Moreover, BPMN also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly Business Process Execution Language (BPEL). BPEL is an orchestration language, in other words, it is used to specify "an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer."  Now, it is interesting to read about the relation between BPMN and BPEL:

"
Relationship of BPEL to BPMN
There is no standard graphical notation for BPEL, as the OASIS technical committee decided this was out of scope. Some vendors have invented their own notations.
(...)
Others have proposed to use a substantially different business process modeling language, namely Business Process Modeling Notation (BPMN), as a graphical front-end to capture BPEL process descriptions.
(...)
However, the development of [tools that map from BPMN to BPEL] has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other.
"
This final paragraph gave me some hope that BLDD is not an in vain proposal!

BLDD is based and inspired in BDD, which in turn is influenced by Domain Driven Design (DDD). In other words, for all reasons exposed by these techniques, having all the artifacts (models, requirements, source code, tests, documentation...) readable by humans is a must have feature. Also, round-trip is totally necessary. Besides following these principles, BLDD is simpler and independent of any execution engine - although we are investigating it in environments with workflow engines. I am not saying that BPEL isn't good, I am sure that some really complex systems can take a lot of advantage of it, however, we want to have a more generic proposal, which can be implemented in any language.

I know of BPEL Script, however, it seems to be a language to describe processes, it think is not a full fledged programming language. An idea to investigate is the use of automated tests with BPELScripts and make it another proposal for BLDD (something like BPELScripts + TDD or even BDD). However, what we propose now with BLDD is to use generic languages, such as Python, Ruby, and Java, to implement all the stuff, and more, in a way readable by humans.

So, in other words, I think that BLDD and BPEL has the same goal of implementing systems based on business processes. However:
a) BPEL (i) needs a heavier machinery, (ii) already provides a series of artifacts for dealing with highly complex systems, and (iii) is well supported by industry.
b) BLDD (i) is simpler in general, (ii) is heavily based in TDD, with all its advantages, and (iii) it works with human-readable artifacts from end to end.

Which one to use in your case? I think it depends on your demands, technical knowledge, and development culture. I don't have a final answer, mainly because we need to advance on BLDD proposal and also because I prefer to use the Keep it as Simple as Possible (KISP) principle. I think there is room for BPELScript + BLDD, however, more time is needed for analyzing this proposal (any volunteers?).

Anyway, after reading this quite interesting two-year old article (some of the problems expressed in it maybe are solved right now), I have a final remark: sometimes "enterprise class solutions" become so complex that programmers abandon them in the end, such as CORBA (and J2EE at some extent).

1 comment:

  1. A quick note: BLDD also differs from Executable UML because this one follows the Model Driven Architecture method, in other words - and simplifying, try to use models at maximum detail level in order to generate code afterwards. BLDD uses models only to establish communication between users and developers or when needed during implementation. BLDD is Agile, xtUML is MDD.

    ReplyDelete