Is this BP-project proposal for real?

Kalimera,

I have received some feedback about my proposal, and I will try to address the doubts about it. The word simplistic means that it is reductionist: not all the elements are there. It makes it more understandable and crispy. Not doing so will add much further detail very quickly making complexity appear in the process.

If you read carefully, the entries say “simplistic view” meaning that the view is reductionist, not the whole approach.

Why a reductionist view?

As I talk here about a BP-project, I have chosen to retain only three roles. This might be inconvenient for large projects, since the Information Architect, the platform specialists, process owners and other people should participate. Let me say that I focus first on the essential roles only, and that I will introduce other people as soon as the basic model will be described completely. Secondly, the 3 essential roles we cover are the ones that allow to create the Business Process Model. Other roles will allow us to integrate it with the SOA via the web services, know all the details of the information to be exchanged, add the security constraints and the specifics of the exchange protocol, etc. but this is not the core of what we aim to do.

In short, I know no other methodology that can be explained without a basic model. I expect no to create something more complex.

Is it formalized or peer-2-peer?

As many have already understood, this methodology is neither completely RUP-like, nor totally eXtreme-oriented. This attempts to be just a
good, effective combination of both; our goal is to remain eclectic, open to both improvements and customization.

Why RUP? Because it merges the best practices that have been compiled in many years and with experience accumulated in different domains, people know it, and even if the name is as generic as to mean nothing in particular, it also sells because it is as generic as to mean many things –including quality– to many people (It is just that I’m tired of meeting people that demand RUP, and later they show they know not much about it… but the word makes people calm… wow!)

Why eXtreme? Since we want models/code to be executed and validated in short loops, and to think about testing even before modeling, and to guarantee the quality during the execution… there is no other choice.

How many other roles, then?

Each role can be split onto 2-3 roles each, that may be often performed by 1-5 persons each. In really small projects you can find all three roles made by a single person. Of course I will talk about this in a future entry. Please be alert.

Arrivederci

A BP-project model… what for?

Hola a todos,

One of my goals for this initial period is to create some a number of “chunks of information” that should make more understandable the workflow and dataflow that occur in a BPM project done with Intalio. Why?

• Because it is a model (by itself) that can help managers and project managers grasp the main concepts and steps
• For ROI to be computed (it should be, anyway), then first a cost model must be established
• Because by formalizing it, we can explain it to other members in the team what a BPM project really takes
• Why not? even if the approach is pretty eXtreme-like, the idea of BPM cannot easily enter into the minds & souls of non-specialists
• No project manager is going to assume a project where the risks cannot be modeled (and dealt with) **
• The BPM model offered by Intalio is not the same offered by other BPM platforms that are either a) more oriented towards the Business-Analysts or b) more technology-oriented, making BPEL-like reasoning explicit and where SOA is mostly the piping among applications. Consequently, the project model cannot be the same.
• Finally, it is sure that people are smart and will eventually propose something else, either for enhancing
  this proposal or –let’s hope– for replacing it completely for something less absurd. However, a first step is required.

** Some people have not understood what eXtreme really means

Many decision-makers find extraordinary the idea of BPM, but they cannot see what it looks like. Then, they see it, and they don’t assimilate it. Even after a custom-made demo, the paradigm-shift is so strong that the audience is unwilling to think about actually adopting it internally. Afterwards, convincing the decision-makers to go further, spend money and resources (and time) is… just out of question!

(Don’t care. Every paradigm-shifts make all companies, organizations and societies go through these sort-of-”usual” crisis)

The normal workflow, where each guy does its own stuff: business people just describe fuzzy things & functionality, IT people work on this problem and produce a solution… and then nobody is really satisfied… it just doesn’t work as it should, but it’s known and it works.

The Agile Processes, where the tools and the code are “the thing” is not very tranquilizing for people used to create solutions in a certain way for already a number of years. Yes, agile approaches have made their way and are “tendence” but in BPM the abstractions are much higher… and doubt creeps into the scene…

Do not point at these reluctant guys with your finger: THE critical business data is exposed to us via the BPM, and the complex business logic of each of this bricks is huge… remember that similar projects, such as data-migration, are tackled with extreme prudence.

Any reason for this? well, problems like accessing a database and all the transactional-related conflicts are just a simple issue when compared to the conflicts we can have nowadays in BPM: the bricks are ERPs, CRMs, Financial applications, the Accounting system, among many other sparse and dense constituents… therefore, the ramifications of any underspecification or any misconception will be broader than with a single database. The constituent systems of an SOA have been created, developed, maintained and used mostly as separate entities, because the semantics of any composition are not necessarily well-known.

As the abstractions of BPM are more general, the transactional contexts and business logic are much more powerful… for the good and for the bad.

If the IT applications were created (“by God”) as individual applications, and they are each so complex, how can you guarantee (you, little human ) that no mistake will be introduced? An error in the semantics of the composition can become a real disaster for the target organization. Why do you think that just by putting BPM on-the-loop the world will certainly become simpler?

Of course, the BPM on SOA can be applied without much consternation in most modern companies, small projects, etc. However, in order to make this a really transcendental approach, what we should try to change is the mindset and development approach in BIG organizations, mainly in government, in the management of critical resources (food, public services), in the fundamental services for economy, etc.

My thoughts are getting a bit too wild. May be I’m tired, or may be it is time to continue the technical discussion.

A simplistic view of a BP-project using Intalio

Bonjour à tout le monde!

Well, after having dealt with some very specific problems of Intalio, I have to get back to the initial goal of this blog: to explain how to use the BPM suite. I’m sorry if I went a bit onto the specifics of some problems, but I have to document them before I forget them. Once done, let us be back on-the-track.

Since there is no specification about how to use the platform, I will dare to propose a sort-of-methodology in order to use Intalio. Hey! you know, I have not found any reference for this, so I had to create something by myself. Please consider it only as a personal reminder, and if you have elements to add, just write a comment. Thanks in advance.

The Project Roles

In my humble opinion, the Intalio suite is oriented towards 3 basic set of roles:

• the Business Analyst (BA) or Process designer: a functional designer that models the process, its semantics (sequencing, loops, handling of special cases), the conditions that start the process (the triggers) and the conditions that should be satisfied in order to finish the process (the terminating conditions). She/he will interact with the assembler (next role) in order to guarantee that the semantics of the description are respected.
• the Process Assembler (PA): a technical specialist. This role will –first– introduce a more formal semantics onto the business process specification created by the BA. Later, she/he will perform the connections assembly: integrate the set of BP-artifacts onto the process solution. Finally, she/he will interact with the deployer (next role) in order to perform the tests of the executable version.
• the Solution Deployer (SD): the actor that actually makes the specification executable (Business Process + artifacts). This role should define a development/testing environment and a production environment; this last one requires that the SD documents the target IT architecture. This actor is highly competent on the technical issues.

The BP-artifacts that can be assembled by the PA are of three types:

• the web services,
• the user screens, and
• the database connections that are available (lately, since Intalio 5 allows it).

The most critical task that this role must satisfy is the correct mapping of the messages as input/outputs of the process data. I sugggest to adopt an approach based on document-like artifacts. I will address this issue in future entries, of course.

I hope it is clear for the readers that this is a non-linear process. In practice, it becomes evident that the communication among the BA and the PA is actually an ongoing relationship, and may take longer than expected: each phase of the BP should go through specification, modeling, integration, testing, debugging, and validation… :-O

In order to deal with the incremental of my approach, I will soon start explaining a RUP-like approach that I’ve been thinking of. Sure, it won’t be perfect, just like this proposal.

The number of roles in a big project is –of course– higher than 3. My intention is to explain the vanilla approach, before introducing complexity. Bien sûr, this approach is far from perfect, and may not satisfy the requirements of some really knowledgeable guys, but it is a basic proposal that is better than having nothing as a reference. Besides, this is the first time I try to formalize it. I just hope it helps you.