What You May Not Model

.

• If your intention is to model operational risk, I strongly suggest not to use Intalio.
• If you intend to compute the organizational performance a priori (via benchmarking the working capacity of the organizational units in a company), Intalio may not be the tool you’re looking for.
• If you want to compute process time or process cost, this cannot be done directly. You should wait until having an executable process, and then this may be feasible. However, there are other tools that may fit much better this requirement.
• If you need just to replace a composite application, and you focus on low-level notions (synchronous and asynchronous communications), be warned that Intalio and BPM do not include those kinds of
  primitives directly, and that your modeling can be uncomfortable. There are plenty of BPEL-level modeling tools that might fulfill your requirements directly.
• If you already have a model process written in some other language like EPC, UML, OSSAD, b-Flow… do not expect to find plug-ins that will help you import/translate.
• If your requirements do include the creation of a process framework (or a process library/reference), know that Intalio does not provide any process repository functionality. You should build one of your own.

• If there is not need for an executable BP as a result of the modeling effort, you’re not going to use the maximum capacity of Intalio…
• If you have no need of rigorous semantics that help you build valid and correct Biz Process models, just use any drawing tool with the notation you prefer.

Of course, Intalio is a great tool, but you will get no satisfaction of using it for what it was not intended.

Beware of the Law of the Hammer:

The child who receives a hammer for Christmas will discover
that everything needs pounding
– Gerald Weinberg

.

What is too often tacit and that should be know by both IT-guys and Biz-people

Konichiwa,

There are several aspects of the interface between the theory and practice of BPMS (and of the more general
workflow-systems) that are just never explained.

They are not necessarily present in the minds of non-specialists. I prefer to avoid the tacit understanding of such aspects. This often results in undeterministic and conflicting views of BPM, BPMN, and of the process descriptions that you create with it. It is also fundamental to grasp the essence of the architecture of BP-based systems (what is the place of BPMS and of workflows, of BPEL, BPEL4People, User Interaction, and others in the equation).

I won’t cover everything here but the main issues that help you understand the reasons that I consider most important to understand how to tackle a BP-project using Intalio and other BPMSs:

• The designer must clearly specify two logical sets:
  • the portions of the workflow (set of tasks) that can be performed automatically, and
  • those portions of workflow that require human intervention.
• The BP designer will generate an orchestrator that will be executed on a BPMS server. An orchestrator:
  • is an entity that guarantees that the execution of the business process follows the specification;
  • is external to the systems that will actually execute many of the actions, but it is the orchestrator who will command them to do those actions;
  • is not the owner of most of the information that is required for future actions, so it should grab and store that information for future use.
• The designer will then obtain two kinds of BP-pools (representing the coarse roles that participate in the process):
  • non-executable: each of the IT systems that the orchestrator must talk to, as well as every user interaction (web-based in most of cases)
  • executable: the orchestrator itself.
• The BPMS server:
  • provides an environment where to execute the orchestrator. Such environment is a virtual machine for BPEL and BPEL4People
  • provides a portal for managing the User-Interactions in synchrony with the BP-description
  • talks to security components, in order to authenticate and authorize BP-consumers

I hope this will make it easier to understand the structure of the resulting specification. More details on this subject will be discussed later.

Tchau!

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!