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

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

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.