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

.

Infoworld prize & Intalio|BPMS 5.2 Released

Salut à tout le monde!

I’m sorry for having abandoned my blog for so long, but I’ll soon have exciting examples that I’ll include here. I have been working in a couple of projects (ITIL, e-Government) that have allowed me to exercise a bit more on the art of BPM.

You’ll see short examples on those domains in the next weeks. I’ll also discuss about portals (Liferay, eXo, and even Sharepoint) and JCR (Java Content Repository), and how to integrate BPs with them.

My entry today is related to the prize that Infoworld awarded to Intalio a couple of days ago. This shows that
the effort pays, and that the product is mature and really outstanding in what concerns quality. More information here.

The second issue today is the newest release of Intalio. The official information is here. Now, some information is missing regarding the technical features. I hope they will correct that missing link.

You’ll see some changes, in particular in what regards the look&feel (3-D is nice!) and about layout. Deeper in the functionality, you’ll see that the menus are much more contextual (“intelligent”) when you change views. This allows modeler to concentrate on the taks at hand.

I had used the enterprise version a couple of months ago, and it seems that the just released community (CE) version integrates even newer features. For example, when in the mapper you can apply filters that reduce the overwhelming amount of items on input/output. The filter icon is a bit bizarre, but easy to spot (it’s the green one) and it explains the principle: only an arrow from three goes through. The other two menus on the right have also been improved.

Intalio mapper 5v2 new contextual menus

There are other new features related to connection to service registries, improved Web-service imports, etc. Since my goal is to remain in the domain of the community version only, I will not talk about them here.

Once I’ll have tested some new CE features (native support for REST web services, enriched XForms, enhanced DBC connector) in some real-world project, I’ll keep you informed.

さようなら

Process Logic & Process Data

When the modelers create a Business Process they must specify two things: the process logic and the process data.

The process logic is the description of the activities and events that take place during the execution of one instance of the business process. For example, for an imaginary BP:

when a fax arrives, the customer should be validated before going on. If the user is valid, then… ; at the end a fax should be sent back to the client.

In terms of executable business process, we should rewrite the process logic in a more structured fashion, as follows:

• when the event fax arrives is detected, then the process is launched.
• The first task is to determine what is the customer number
• then the customer number is used to validate the customer,
• then… ;
• at the end, a fax should be generated;
• the user must print it and
• sent the printed fax back to the customer.

Of course, the final form depends on the level of granularity and of detail of the (web) services that should be used, as well as of the information that the users of the system should introduce. In this case, the rewritten process logic can be easily translated to BPMN.

Ideally, the description of the process logic should satisfy the business needs. However, the resulting description cannot be executed because some elements are not there, as explained here. This is what happened with our first model. We must then complement this description with another layer of description.

The second level of specification is the process data. The current description of the process logic does not indicate more than the sequencing of both tasks and events. However, nothing has been said about how to use data for making decisions (if-else scenarios). Another important issue is data manipulation.

Nevertheless, in real life, every time that some event happens during a business process, some data is taken and sent to other systems, transformed into some useful result, and those results are communicated back to the process in order to use them some time in the future of the execution of the process.

This is what we do using forms, notebooks, post-its, IT systems. This information is resilient and many of the future decisions of how to handle the processing will be done on the basis of these data. That’s why they are called process data. In most cases, these data are simply transferred to a new system without any transformation.

Let us see un example of a very ordinary dialog over the phone:
- Carlos : Hi Susan, I just received a fax from a customer, could you help me validate him?
- Susan: Of course. Just give me the customer number, and the family name.
- Carlos: His customer number is: CN-CNCNCN-CN, and his last name is LNLNLN.
- Susan: OK. Give me a second. The customer FNFNFN, LNLNLN, identified with the number CN-CNCNCN-CN is valid. You can go ahead.
- Carlos: Thank you. Excuse me one more time, but: do you know how to make a claim in this new system?
- Susan: I’m not sure, but I think you should press the button “Customer Is Valid” in order for the system to know that I validated the customer for you.
- Carlos: Yeah, I see. Something new appeared on the screen. It asks me to print a response letter for the customer.
- Susan: Just do it. It will print a model reply letter with the reference number of the claim.
- Carlos: It’s done. But it’s also printing something on the sticker printer. It’s a sticker with the reference number and some barcode.
- Susan: You’re done. You stick the barcode to the incoming fax. Then you put it in the binder that is marked “Claims Dpt.”. The system will send them a message immediately so they know they have something pending in your office.
- Carlos: Yeah, I see. Before I had to call them all the time so they could come take it. It was not really effective with these guys.
- Susan: It’s improving. You’ll see. Don’t forget to take the other half of the sticker and put it on your logging book along with the date.
- Carlos: OK. Thanks for all your time and comprehension. Sorry if it took too long.
- Susan: Don’t care. Bye.

All these data: fax, “Customer is valid”, sticker, reference number, customer number, customer last name, customer first name, nature of the fax(claim), date, etc. are stored temporarily in order to perform a series of tasks. Some of these are physical data, other are just logical data and data references. The most important feature of those is that they are local and private to one instance of the business process:

• The fax is unique (one instance in paper, received at a time/date),
• the reference number is unique (the system should guarantee a sequential number for each request),
• the validation is unique (the customer is valid at the date/time of the request, but it might not be the case before or after),
• etc.

Therefore, the process logic is now complete: We know what event to expect or what activity should take place, and also what it takes to perform each activity.

We didn’t have enough space to cover the manipulation itself, and how to transform data. This will be done in a series of entries labeled “Process Data”.

What the Intalio Suite provides to each Role

The Intalio suite is made up of 2 basic sets: the Intalio | Designer and the Intalio | BPMS Server.

The first one is the platform for modeling and preparation for deployment. The second is the platform for execution. I will now list very succinctly the features that satisfy the specific needs of each role, without being exhaustive.

(The roles and the general project approach –xPD– are explained here and here)

• The Intalio | Designer is intended to be used by the Business Analyst and the Process Assembler.
  • BA-oriented functionality:
    • Process specification (BPMN designer) and validation
    • Screen designer (XForms designer)
  • PA-oriented functionality:
    • Data mapper (connecting input/output messages to the Process Data)
    • Pool specification (internal or external to the system)
    • Process-role assignment (for interactions)
    • Generator of BPEL and BPEL4People
  • SD-oriented functionality:
    • Deployment server parameters
    • Target URL namespace

• The Intalio | BPMS is intended to be used mostly by the Process Assembler and the Solution Deployer.
  • BA-oriented functionality:
    • Portal-like interface (XForms, authentification)
  • PA-oriented functionality:
    • Administrator interface
      • Process administration
      • Instance execution debugger (data, events, correlations)
    • Interface for testing Web-services
  • SD-oriented functionality:
    • Administrator interface
      • Process administration (deployment/undeployment, archiving)
      • Instance execution debugger (data, events, correlations)
    • Other administration portals

I will soon explain the diversity of platforms that make up the Intalio Suite, in particular the forest on the side of the Intalio | BPMS Server.

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 !!

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!

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!

Roles in the simplistic view of a BP-project

Grüezi,

In the last entry I explained 3 roles and the way they interact with the Intalio suite. In this entry, I will explain a bit more how the project starts and how the two first roles interact.

The Business Analyst (BA) is a functional specialist. She/he is responsible for creating a process specification. As this specification becomes very complex very rapidly, it is important to adopt an approach that I’ll baptize eXtreme Process Definition (XPD). Like eXtreme Programming, the idea is to make prototypes that are tested and validated very often, adding new functionality very quickly.

From the project management point of view, this corresponds to choosing a life-cycle named “Evolutive Prototyping”, where the previous core functionality is preserved, and new functionality is added; this has as advantage the capacity to always deliver a product, creating an optimal result for everybody at almost any situation (risk, cost, priority can make your project stop, and you always have something to deliver). A number of rules must be adopted, in order to make the evolution towards a final product agile.

The BPMS Designer enable this approach since the Rapid Prototyping of new functions is made possible even for non-technical guys. How? Well, the specification of Business Processes (BPs) is made by the business guys themselves:-O, using a language that is natural to them since it is just like flow diagrams: the Business Process Modeling Notation or BPMN. No programming (Zero Code) is the motto.

Besides the process itself, the BA must also create the screens that users of the system will see when they will interact with it. Of course, a bit of more technical knowledge is required here, but the path to a first prototype screenshot is really fast.

Just imagine, Intalio Designer makes possible to adopt agile methods at affordable or no cost in the Business Process dimension!!

The Process Assembler (PA) is the one that will make this specification ready-to-execute. His first task is to interact with the BA in order to verify the semantics, in what concerns conditional execution, iterations, the selection of one/many parallel paths (fork, rule-based execution, among many others) and for identifying the information required to compute each rule (for the conditions/predicates of each execution path). Next, the definition of contexts is required: sub-processes, transactional contexts, etc.

Concerning the screens for the users, the PA is responsible for adding the constraints that can be applied to the user interaction: the validation is automatic and declarative, only the predicates that should be respected are required.

A very particular duty of the PA is to connect the web-services and other providers to the BP specification. Now, this can be put off since the agile way does not compell the team to make the system fully executable. The most important issue here is to make a good spec. How to choose the good path towards a complete BP? by following the best-practices in the software engineering field, I propose you to do the pretty standard Work-Breadown Structure (WBS):

• first, the normal case, where everything goes OK,
• second, the alternative paths to the normal case, or the processing planned for special cases (starting by the 1-3 most common)
• third, the error cases, i.e. the cases when things go wrong and special measures and even backtracking should be done

The core functionality is generally respectful of Pareto principles: it applies to 60-70% of cases, letting the remaining 20-30% pending. If your BP has a section with more than 3 alternative paths, you may start thinking about isolating it into a sub-process. We’ll see how to do that in the near future.

I’m aware of the fact that the approach as presented here is not necessarily applicable to many cases. I will soon give details about the document-centered approach that is normally required in order to deal with the complexity of exchanges. I will also then describe how the Process Data should be designed. Bis bald!

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.