What to model

As I already discussed in this previous entry, the project of designing a complete BP model is made up of 3 phases. They all come from the pretty standard Work Breakdown phases:

• the normal, good-behaving case
• the alternative, however still good-behaving cases
• the badly-behaving scenarios: cases that were not covered/expected (exceptions) and errors.

(An interesting approach similar to this, but focusing on the type of audience, is presented by Bruce Silver here)

Doing this for a single process with a tool such as Intalio is a breeze… however, dealing with a real BP in a real organization requires having some development strategy that can help us prevent problems as well as being good for dealing with complexity.

A not-totally-eXtreme approach
I propose you to plan at least the construction of three deliverables at each phase:

• The raw process: determining the steps/activites in order to achieve the process
• the user-screens/forms: what information is required at each step, what information should be asked in order to make an informed choice later in the process.
• the association of process and forms: the creation of links among the process step and its user form (we just produced in the previous step).

The iterations
Each one of the phases is actually made up of a number of iterations. Each of these iterations aims to create a model. A common scenario looks like this:

• First iteration: the process as a single activity: a starting event (or set of events), the process itself, and the expected output. The process has a name, and some text can explain what kind of information is processed in order to produce the output.
• Second iteration: the process as a Start-Do-End sequence. The Start activity includes all the proces setup, and the introduction of information; the Do activity includes the portion where the real processing takes place, i.e. the business rules, the decision-making steps, the alternative branches. Finally, the End activity includes all the process cleanup taks, and the end of transactions (accounting, notifications, etc.). As a result, the user-screens start being specified.
• Third iteration: the initial Do activity is split onto a Start-Do-End sequence. It is clear that the application of the business rules, and the decision-making process is not linear, and require the decomposition of the previous model. In this case, more information is given in how the information is entered into the BP or retrieved by it; the source can be some person or IT system.
• More iterations: a concrete flow of information appears. Each user-screen can be related to an activity on the BP, and the way this information is reused farther down the BP dataflow becomes pretty clear.

Every iteration is accompanied of the corresponding validation. If several actors intervene in the process, each one of those should validate the corresponding data introduced by users. Of course, this won’t be complete for the first iterations, but it will become when both more details and IT are added to the process.

The amount of effort required for creating a good BP model depends on the nature of the current process and of the maturity of the current automation of that BP. For instance, if the process is already in a computerized form, it will require only the re-creation of the user screens; if it is still paper-based or an informal process (i.e. a task-list, phone calls, post-its, requests in the corridor, etc.), it requires a real understanding and formalization of the essential information.

The Process Owner
Do not forget to include the process owner as frequently as possible. She is the only one that has the global view, and the one that understands the global constraints of your project.
The participants of the many specific process activities do not posses enough information in order to improve the general process and to know where it is really applicable.
Besides this, is it the Process Owner the only person that can help you define what the good granularity of your model should be. I avoided this subject in this blog entry because knowing when to stop refining is a difficult subject, and because it all depends on your customer.

Never forget that the process owner wants to obtain some information from the Business Process itself. In a few cases, that result can be obtained simply from the very act of creating a BP model, and no more work is required. However, in most real cases, the process owner wants to obtain something else: to measure something (performance, queue lenght, seasonal variations, cost per instance, etc.), to avoid something happening (paper-based processes, process blocks/deadlocks, no escalation), to make something visible to people working on the real BP (feeding some enterprise portal, contextual information before making a decision, among many others), or some other result.

You MUST establish with the process owner what the bottom line is.

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.