Before you start creating the BP model in Intalio…

Bon giorno,

Most people find it difficult to start a business process modeling project with Intalio but when reusing examples. Consequently, I thought it would be useful to give a few hints of what it really takes to start from scratch. Of course, I’ll be as generic as possible and attempt to remain consistent with xPD, and we should address specific needs at some point in the future.

As I said before, the PD or BA is responsible for mapping the BP description by using Intalio Designer. Here, we follow a top-down approach where the specification comes from the business side; it may however remain still applicable for orchestration efforts coming from the IT side.

In order to model a Business Process, the BA should first have a model process, even a draft one. If it is not the case, she/he should create it, but this is a different issue we will talk about in a future entry. I will assume the BA has a list of the tasks that make up the process, and that YOU are the BA. Please, choose a simple process that is mostly sequential; we can add complexity later but the goal now is to understand.

The original model process is just a description. It does not posses several properties that are required to make it executable. So, we must transform this description (“AS-IS”) into the one you will obtain at the end of the modeling project (“TO-BE”) . What is the difference?

• Semantics (symbols used and grammar) of the description language are ad hoc.
• Data is not mapped: there is no way to communicate the context to the different tasks explicitly.
• Actors are often specified but in a physical/real environment, where paper & thick walls isolate roles, and where several specific IT systems/applications must be used.

We will write a new specification with more rigorous semantics by using BPMN. BPMN is a description language produced by consensus of a large community; it is a public standard, so people should be able to understand the BP-model 10 years from now, even in a different geographical area. That’s the good thing of this approach: it does not only facilitate reuse and maintenance, but also makes it possible to integrate the Biz-people onto the initiative.

Finally, before starting translating the description, please check first these points out:

• What is the event that can trigger this process? what makes the organization to launch a process like this?
• What is obtained as result at the end of the process?
• How many (coarse) roles/organizational units participate in the process?

PS: Because you should learn BPMN first; I propose you to download & read the Introduction to BPMN and to refer to websites such as BPM Initiative, BPMN.org, BPM Institute, and BPM Research. I won’t teach BPMN here, @ least not for the basics.

I will just tell you that BPMN diagrams are like flowcharts and that you must recognize only four shapes. Each shape represents a main element in the flow: event (circle) that indicate that something happened, activity (rounded rectangle) that mean some work is done (internally or by an external actor), selector/gateway (diamond) for representing control flow (branch/join), and connection(arrow) that indicate control flow and communication. In addition, the roles are represented by swimlanes (pools and lanes).

Hasta la vista!

The pre-conditions for making BPM and SOA possible

Namaste,

Of course I won’t talk here about every single condition. I will discuss, however, two critical issues regarding motivation, technology, and achievement.

Why? In the last few weeks, I’ve had very interesting discussions with some architects and senior developers. They are part of bigger architect and/or development teams and had addressed me as a may-be specialist that could assist them on finding the sense of their lives I summarize the several interactions in three logical groups. They are NOT physical groups of people, and most of them qualify at least in two logical groups.

Actually, they did not find the approach of their teams very correct however not wrong either. It was just that some doubts remained in their spirits, relentlessly distracting them from executing the tasks assigned to them. They could not only follow the same savanna corridor drawn by others without much thinking about where they were heading to.

The first of this groups presented me the following scenario: for several years, they had been developing a number of applications and wrappers for other applications in a big, corporate-wide effort to create a Service-Oriented Architecture. This SOA grows incrementally, and each new service (and the refactored ones) is integrated some time later in workflows and portal that were used by one or more parts of their organizations. So, what? many more years coming…

This is a really critical issue. Actually, they did not really understand what they were doing. When looking back, they felt that the effort done for so long by so many people did not really pay back. The project was late, more costly… the same history than before. So what? All this SOA stuff was just a ton of mumbo-jumbo, a lot of marketing.

This is something to avoid: projects should be shorter, incremental, ROI calculated rapidly, process owner satisfaction should become an upfront issue. Of course, this is an enormous change as for the projects in the past this was the thing to avoid. Please, this is a critical issue for SOA projects indeed. People should perceive the added value. Technical folks should be able to compare the final result.

The second logical group, a bit smaller, was constituted by people who either:

• wanted to know whether it was possible to create geo-spatial applications, or
• wanted to know whether it was really useful to create such applications for, for example, do inventory management

As you can see, there is a problem understanding the scope of a) the technical side of the architecture, as well as of b) the project. Why were they attracted into the geo-spatial applications? why YYYY-maps or GGGG-maps?

Hey! this obsession with mashups and Ajax make the technology the only issue. BPM is not about that. SOA enables this, but you only need a couple of web services for many cases and not a whole architecture. BPM and SOA are about the essentials of enterprise applications, not about the accidental issues such as information representation and interactivity of the user interface (but for applications whose goal is this one). BPM and SOA are intended to reduce complexity and decouple the architectural components. The process-based view of the world allows to map the business activities. If your solution requires visual geospatial components, just use them. If not, do not do it. Don’t mix what is not mixable and don’t compare what is not comparable.

The final, third group is about people that struggle with too many technical issues. Is this really necessary? is it useful? why so much complexity added? wasn’t it supposed to be the contrary? Hey, that hurts!!!

These guys pass their time solving issues about XML binding by hand, XML validation, doing the right messaging implementation for the routing, writing components for authorizing access, … the terms changed, but the fashion did not: the same well-known, vintage approach to architectural design and application development. They did not understand when I talked about performance metrics, about ROI, not even about BPMS like the ones provided by Intalio or PegaSystems (or BEA or Lombardi or MS). They have a daily battle with BPEL coding, SOAP coding, XML validation: the IT view only. They’ll never speedup.

BPM and SOA are more than that: they allow integrating the Biz- and the IT-worlds. They put the IT to the service of Biz, as it was in the old days. The tools are essential, but also understanding what really has to be measured. But… how to continue if we’re not sure all the exchanged XML docs are completely consistent? Well, I think you’re completely missing the point!!! As for everything else in the universe, there are a number of basic preconditions: your computer has the virtual machine installed and working correctly, the application server executes, it reads inputs and writes outputs,… and the computer is ON. You cannot suspect & validate everything!! Nevertheless, if you’re binding XML by hand everywhere and creating sockets by yourself instead of using the appropriate tools for parsing & validating XML and for creating the web services, and you also have to take care of the 13×5 XSL Transformations since people in the 5 independent development teams do not agree on what the XML schema is and, in addition, everybody wants to manage the round-trip exchange and persistence, first re-think your project very seriously: this is neither BPM nor “managed” SOA because you positively missed something in the process of selling it.

You know? I feel just like all these people. That’s why I already saw, experienced, studied, and read about many cases just like these. I know what it is and I want others to avoid it. I saw a bit too many organizations investing money on things they did not really understand. BPM is finally there, and I invite you to make the maximum profit from it.

We can conclude, then, that the pre-conditions for making BPM and SOA:

1. Communicate well: correctly and timely; do not overstate what can be done, do not let people go onto technical issues only; put the business process as central actors; show the roadmap. Integration requires agreement.
2. Focus: Do not let people wander in the woods, having crazy ideas of what can be done; do not let them concentrate a bit too much on technology. They will solve the wrong problem.

Aloha!

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.