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.

Creating a first BP-model

Guten Tag,

Let us create a simple description of the process from the original one that the BA has before starting.

How? Well, you open Intalio Designer. Create a new Project, by selecting File->New->Intalio|BPMS Business Process Project; write down the name of the new project and configure the environment (by default, just say OK on this part). Then, you have an empty project with a single sub-directory named “build” ( “DO NOT TOUCH!!!” ).

In Intalio Designer you identify several zones of the screen: the menus at the top, the Process Explorer on the left, the drawing or working area (empty) at the center and up to the right margin; at the bottom you’ll also find two small windows with detailed descriptions, and at the bottom margin you’ll see the tabs chooser (on the left) and the status of the compiler/ deployer (on the right).

In each project, you can create as many process descriptions as you want. The idea is to create one diagram per process description, so let us do it: Right-click on the name of the project, and a menu will appear. Choose New->Business Process Diagram. Then, write down the name of the BP (it can be the same than for the project, no problem).

A new process diagram is created, opened in the drawing area, and a couple of default elements have been pre-built: a default pool, and a default task.

What is a pool? very briefly, it is the representation of the space of action of a given role/actor; it is used as a graphical container of all the tasks that are performed by such a role.

And, what is a task? well, a task is an action or activity performed by a role. It must be put inside a container (pool) in order to be assigned to that role. Tasks are what is listed in our original process description.

Making the system more comfortable for Business Process Modelers

The default perspective in Intalio is the Intalio|BPMS Designer perspective, , that contains the detail needed by the IT specialists. In order to change it, please choose the view menu (top right corner, or go to Window->Open Perspective->Intalio|BPMS Modeling or Window->Open Perspective->Other->Intalio|BPMS Modeling ). This view will allow the BA to use the whole space for the process diagram.

Choose the Palette tab (behind the Project Explorer). The palette offers you the whole set of BPMN symbols you need in order to create your graphical process description. If you want to put a task symbol in the pool, then you click on the Task symbol, and then you click on the drawing (do NOT drag it, please). That’s it.

You must set a name. You may either double-click inside the task, or do the modification using the Properties tab (Click on Properties, then at each task in the drawing. You can edit the content of Properties->Process Execution->Label)

(If you want a full description of this step, please go and visit the Intalio Tutorials and Screencasts in order to understand how to introduce the symbols. My goal with this blog is not to replace the documentation that is already there.)

Specifying the causal relationships: what comes after what

Continue introducing as many tasks as you have in the list of the original process description. Put the next task always to the right of the preceding one. Try not to be too generous, since screen real-state is scarce. You can also zoom out from the menu bar (the only option with the % sign in it ).

You will get a long “chorizo” of tasks. They’re not a network of consecutive tasks yet. This is why a red error symbol appears at the left margin of the pool when you save the file (CTRL+S).

In order to connect the tasks, choose the Flow Connector from the Palette, and then draw it in the working area: click once on one task and click once on the destination task, the arrow will appear indicating the correct direction. The Flow connector is actually a transfer of the control flow among tasks, not a transfer of the data flow.

As you see, by default, the tasks are done in linear-sequence. However, most interesting processes are made up of a non-linear sequence patterns (parallel, one task-or-the-other, a-minimum-of-iterations-of-a-task, a-minimum-of-instances-of-tasks, etc.). For the moment, we will not address these issues.

Once you finish entering the tasks in sequence, we have a first version of the process. Isn’t it difficult to change the control flow later? NO!! That’s the good thing of BPMN and Intalio. It is actually pretty easy, as we will see in a future entry.

Now you’re notified of an error when you save the project. Mmmmmhh… if you put the mouse over the error symbol on the first task of your process, you should read “The first task of an executable pool must receive a message” … ? It is not that terrible, but we have to go back to the original process description:

• what is the event that can trigger this process? what makes the organization to launch a process like this?
  • Is it a request/claim made by the person herself or by indirect means?
  • If it is the person: can she do it by mailing a letter? can it be done by phone? by fax? by e-mail? via a form in a website?
  • If it is done indirectly: what is the kind of system and of information that is received? what are the rules that enable the detection of a certain condition?

Very often, we can represent the launch of a process as an event, one that arrives or that is detected. This is represented by a Starting Event. The Intalio Palette proposes three events: Empty, Message, and Rule. Please select the Message Start. Put it as the first element in your process timeline.

Specifying the causal relationships: connecting to an external trigger

As the message must come from somewhere external to the orchestrator, you should draw another pool. Select the Pool from the Palette, and then draw it in the working area. It should be a non-executable pool, as explained here, since it is an external actor or system the one who initiates the process. It is not an element under the control of the orchestrator. Click once with the right-button of the mouse, and choose the last option of the list, Set pool non executable. As a result, the left margin of the pool becomes dark.

Put a task in this new, external pool: choose the Task from the Palette, and then draw it in the working area. This time no error is notified, since the non executable pools do not require an external starter.

In order to connect the tasks from different pools, choose the Message Connection from the Palette, and then draw it in the working area: click once on the origin task (the new task) and click once on the target task (the message start event of your process), a dotted arrow will appear indicating the correct direction. The message connection is actually a transfer of the data among tasks that is used as a synchronization point by the control flow.

Save the project. Both the error symbol and the error messages have disappeared.

BPMN is very zealous about well-formedness: please close every opening element, and start and end every process explicitly. I know! I know! Intalio is not telling you anything, but it will surely if you don’t correct the situation early. Pls listen to me: avoid the problems and save time. In this case, the orchestrator should include an explicit termination, and End Event. Please select the Empty End from the Palette, and then draw it in the working area, at the right of the chain of tasks. Insert a Flow Connector from the preceding task. We’re done.

The first iteration of our BP-model is complete. It is not possible to generate an executable description from this first model. We will see why very soon.

Vaarwel !!

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.