TINAG – This Is Not A Guide 2 Intalio

Just an attempt to Document & Decode the Intalio Platform for Non-specialists

Archive for the ‘BPMN’ Category

Dealing with Time in Business Process Descriptions

Posted by José D. De la Cruz on February 8, 2009

The main conclusion of my last entry is:

Establish in a clear and precise form the meaning of the temporal terms that appear (explicitly or implicitly) in the Business Process specification
I hope the short analysis I presented there was useful but I fear it was quite technical. The importance of the subject was confirmed in the two last missions my team and I had (where we deal with BPs and with time modeling). I’d like to share them with you to offer a more business-oriented view of it.

One of the missions is a time-management system for the administration of one of the “big” Swiss cities, and the other is a portfolio tool for the PMO of a big multinational. As you can see, time is used as the base of the modeling for the first mission, but only as a parameter of object lifecycles in the second. Both systems are rich, complex, and address the concerns of a broad population.

It is really interesting to see how modeling time can get really harsh when trying to formalize it.
Time is an intrinsic notion for humans, but machines do not understand this abstraction. Time helps explain simultaneity and sequencing. Temporal expression can be expressed mathematically.

Now, the fact that –in general– time notions are not formalized in organisations nowadays, means that we have to get the notions of time as understood by the target organization integrated to our analysis before we proceed further. This means working with the community around our Business Process.

It is clear that in the technical world we’re used to deal with more precise models, but you cannot be naive when dealing with the organization that owns the BP.
For instance, in my project for the city administration, people had different interpretations in different departments. Although the HR department had a set of rules “cooked” recently by a committee that has been working for several months, the HR PMs did not read part of the temporal specs in the same way as the IT PM did, and this was even different from what the HR department representative has traditionally used as criteria in her daily work. Although differences were only present in very specific cases, these were actually the most interesting ones (Murphy’s Law).

Even more important, because of the systemic nature of the BP Management projects, let us not forget our friend Heisenberg: you cannot measure without interfering. Once you start asking people and they understand that they were not paying much attention to the formality of the descriptions, they will wonder themselves and question others,  and finally help you create a proper model. As a result, the organization will change, and many definitions too; not only this, but definitions and perspectives will change radically over time. Be careful to take measures that prevent change in specs becoming a routine.

Anyway, what you will obtain as specs is a Business Processes description far from the mathematical form. Why? because BPs are rarely specified by IT people. They must be taken from their raw expression and translated to a BP model using some strategy. I have sucessfully used this one:

  • Perform some grammatic analysis, and be specially suspicious about all separation symbols (commas, dots, semicolons, bulleted lists, etc.)
  • Identify sentences with letters or short names.
  • Be always careful when people use sequence-related words like “First“, “Then“, “After“, “Hence“, “In order to“, “Next“, “Last“, “Finally“, and many others.
  • Be alert of “big contexts” in the middle of the description. If not identified early enough, they can make you rewrite large parts of the model.This kind of sentences often return to the past, e.g. ” Before you can do action A or B, you must check…“
  • Identify clearly the context of each sequence-related word in the sentence. I use various colors to facilitate the task.
  • Label the newly identified sentences with letters or short names.
  • Establish the sequence with the aid of your customer(s). It can be a simple draft in the form of a flow diagram or –even better– a BPMN model.
  • Do not try to be much precise, get relaxed and create a skeleton smodel that makes sense. The interview/discussion with the customer(s) will give better results that pushing her or him. Avoid guessing whenever possible.
  • By creating a rapid prototype using Intalio, you’ll be able to determine interactively with your customer whether the model corresponds to her/his expectations. She/he will certainly appreciate seeing the results immediately.

Of course, things won’t be this easy and you have to define a basic path for the first iteration. There are at least two special cases that I recommend to filter out, and to deal with only in a second or third iteration. They do not make part of the main path of the BP, and their context must be clearly marked (initiating/branching point and joining point, if any). If you want to read more about the xPD iterations you can find a first reference here.

  • The first one is the processing of alternative paths: They are normally bound by expressions that either deal with conditions or return to the past: “If after X days, no acknowledge is received, then…“
  • The second is different in degree because deals with abnormal paths (exceptions and errors). These are cases that are definitively out of the normal path. For example: “Otherwise, do Y…“, “If no one of those actions is finished after X days, then …“, “After N days of wait for R, the issue will scale to the manager“.

A final suggestion: For every and each model segment, try to work with a real business process actor. For real, I mean a person that deals with the level of granularity of your model segment. Don’t take a high-level view for granted because very often this means a late effort must be done to correct the model, with increasing costs.
If it is an segment considered as important by your customer, it is preferable to put off its modeling, and say it clearly.

Posted in BP Modeling, BPMN | Tagged: , , , , , , , | Leave a Comment »

BPMN to BPEL: be careful

Posted by José D. De la Cruz on December 9, 2008

.
I just read the article in InfoQ written by Pierre Vignéras about BPMN and BPEL.

I was finishing my last entry to the blog but I think that that article is a bit misleading and I must react to it. Why? because it makes a point on some wrong interpretation of BPMN. In addition, this gives me a good excuse to explain some details about process algebras.

First, I must clarify that I like Bull and their suite, and that I could have rich discussions with the Bull guys and a couple of OW2 Project Managers in LinuxDays in Geneva. Besides, I used eXo in a project recently, and I think that’s a nice portal and that their implementation of the JCR-standard is just great. Bull’s philosophy is different from Intalio and very respectable, and Bonita is a nice-to-have BPM Suite. I like eXo and its family: Orchestra, JOnAs, the way the integrate…

Nevertheless, as an ancient researcher in this domain I cannot just let it pass a misinterpretation like the big one in his article, and specially the conclusion that he has created from that misunderstanding.
In a very short form, the process they describe is: a new employee starts working, and the company must proceed to some exams, and some logistics takes place (like giving her a computer). You can see the ~BPMN description here:
http://www.infoq.com/resource/articles/bpelbpm/en/resources/onboarding.png

Is this really a correct model?
Although Mr. Vignéras article starts with a discussion of structured and unstructured approaches to programming, his diagram is not structured. He just did not respect the most basic good practices for modeling in BPMN.
As in any language, in BPMN there are different levels (as I described in my last entry): lexical, syntactic, semantic and pragmatic. The two latter levels mean that not everything that is grammatically correct is necessarily a valid construction in the “common sense” understanding (If you want more on this, you should read Chomsky).

I must suppose that the author did not know in depth the substance he was dealing with. At least, he did not analyze the BPMN semantics of the process in advance. As a matter of fact, the BPMN model and the BPEL one MATCH, but it is the (textual) process description that is wrong :-O

In the description he says: “… When a new employee arrives at a company, a workflow is instantiated. First a record needs to be created in the Human Resources database. Simultaneously, an office has to be provided. As soon as the Human Resources activity has been completed, the employee can undergo a medical check. During that time, a computer is provided… “. If you face a description like this, you should ask yourself several things:

  • What activities do happen in parallel
  • What does it mean “During that time“?
  • How do you represent “can” ? and what about the other modal words?

Let’s Put Some Music
Let us decompose the description onto sentences:

  1. A = “First a record needs to be created in the Human Resources database”.
  2. B = “Simultaneously, an office has to be provided”.
  3. C = “As soon as the Human Resources activity has been completed“
  4. D = “the employee can undergo a medical check”
  5. E = “During that time, a computer is provided”

Going further, I will isolate the temporal and modal operators:

  1. TA = “First”
  2. TB = “Simultaneously”
  3. TC = “As soon as the … activity has been completed”
  4. TD = “can“
  5. TE = “During that time, “

Then, back to the initial text we obtain:

  1. A = TA + “a record needs to be created in the Human Resources database”.
  2. B = TB + “an office has to be provided”.
  3. C  — let’s just forget it
  4. D = TD + “the employee undergo a medical check”
  5. E = TE + “ a computer is provided”

Now we can write different descriptions of the BP. The basic thesis should be that During that time means “something that happens in parallel“.
Let us consider a quite basic process algebra (you can adopt a more precise CSP or CCS or Pi-calculus if you want):

  • sequence (.)
  • parallel construct (||)
  • exclusive OR (ø)
  • inclusive OR (+), and
  • the epsilon joker (ε).

Mr. Vignéras wrote a model that can be represented by this equation:

( (A.C)+ (ε ø D)) || (E) ) || (B.C.E)        :-O

No matter why the employee receives two computers !!

Now if we read the textual process description, and if we simplify the undeterministic expression D from “can“ to a deterministic “will certainly“, we may write the BP in 2 ways:

  1. f ( A.B.C.D).E — this is not valid because E is not in parallel.
  2. f (A.B.C.D)||E — this is valid but ambiguous

We must rewrite this last equation, but in a less ambiguous fashion. Because the sentence C establishes a causality between A and D, we can reduce the design space to those options that respect such causality. This does not, however, give us a unique option:

  1. (A.C.D) || B || E
  2. ((A.C.D) + B) || E
  3. ((A.C.D) || E) + B
  4. ((A.C.D) || (B + E)
  5. ((A.C.D) || (B.E)
  6. ((A.C.D) || (E.B)

As you can see, at no moment we can obtain the extrange model of Mr. Vignéras. In this case, we have exclusive paths to the E premise, i.e. a single computer given to the employee.

Are Exceptions Unstructured?
I was quite surprised with Mr. Vignéras’ view of exceptions as a non-structured approach. Actually, this was the real reason to feel uncomfortable when reading his article before I saw the BPMN modeling problem. He put the fault on Business Analysts, on the real world, and on everything else but a good structured programming/modeling language (his title reads “Business Analysts Write Parallel and Unstructured Processes”)… These are my reasons:

  • First, the 1968 article from Dijkstra was really focused on unstructured architecture of programs.
  • If one takes the time to study the more complete Dijkstra’s “A Discipline of Programming” (from 1976),  that is also more modern than the 1968 article, one can conclude that the essence of his message is that the modules have contracts (I won’t go into the details of the guarded command language). Each contract is fulfilled if the pre-condition is respected. This does not exclude the introduction of exceptions, because they are basically the result of not respecting those pre-conditions. Dijkstra is very clear: “If the precondition is not respected, we can say nothing about the postcondition“… the rest does not come from him.
  • The work done by Meyer for building the exception treatment that was eventually built onto the Eiffel language (and re-adopted by all major OO-languages) is actually a nice proposal to a very structured way of dealing with erroneous conditions. It was a counter-proposition to defensive programming, and it guaranteed that someone had to deal with the error. It instantiates a very well-known and structured pattern: the chain-of-command, that’s it.
  • The fundamental and complementary works of Parnas (modularity), Liskov (the Substitution Principle), from Rebeca Wirfs-brock group or the Fusion method group (that dealt with roles and design principles), are perfectly compatible with the notion of exception.
  • All these proposals are built around the Hoare Triple, and if you go really deep, the famous triple is another “not uncompatible” specification tool.
  • The language theory, specially the grammar automatas, say that a grammar is accepted if the path arrives to an endpoint.  I’d like to see this comunity’s reaction when considered as non-structured.

The unstructured nature of graphs (?)
Let us cope with graphs nature: I’m not fond of graphs, and I am almost allergic to them (more on that when I’ll come to my Ph.D. dissertation some day). This does not mean that graphs are bad, because they are useful.

For example, I kind-of-hate them but I have to admit that when working on parallel computing and data-flow, they really helped us structure the solutions. However, you had to be aware of their power and their flexibility.

Graphs are useful not only for parallelizing frameworks and middleware. When I worked on real-time systems, I also enjoyed using Structured Analysis models (for example Hatley & Pirbhai, some 16 years ago), that were kind of data-flow + control flow (quite similar to BPMN when zoomed-in) and helped you understand the complex relations among architectural modules.

Yes, graphs can get really wild, and I agree that you can create monster models, but they are not necessarily unstructured. As a matter of fact, in the cases mentioned above a graph was a hyper-useful means to structure your solution. It all depends on your use of the modeling techniques.

CONCLUSION
The author of the article mentioned above wrote a wrong BPMN model, then he wrote a process description that does not correspond to the diagram, and finally he explained a 2nd wrong model in BPEL. I know his goal was to prove something else, but I do not appreciate being mislead.

I hope I proved many fundamental notions in Computer Science do not share the definition of structured that was presented by the author. I also could show that  there is no single way to define “structured”, even for computer languages.

I think you can miss the point if you do not go far enough on your analysis. Brooks explain this very well when he calls this complexity, and differentiates essential from accidental.

  • For more curious people, please read the incredibly illuminating discussion of Weinberg on state and structure, as well as the work of Barwise and company on the modeling of logical systems (Stanford’s CLI).
  • I also invite you to read Mr. Bruce Silver discusses the distance from BPMN to BPEL, from market strategy to the issues related to the implementation of BPEL standards.
  • I will review my model once in the future, in order to check that everything is right. No guarantees for the moment.
  • I may add to it that XPDL (used by Bull’s products) is an interesting and may-be-extremely-structured language, but I am quite confident that you can also write things that do not make sense (on this domain, I only trust formal proofs and/or model-checking). Of course, I won’t spend time on doing that: it is possible, more than probable, and completely useless.

I do not put more pointers or bibliography, because of lack of energy. Sorry. Lo siento.

Posted in BP Modeling, BPMN | Tagged: , , , , | 1 Comment »

What You May Not Model

Posted by José D. De la Cruz on November 22, 2008

.

  • 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
.

Posted in BPEL, BPMN | Tagged: , | 3 Comments »

Process Logic & Process Data

Posted by José D. De la Cruz on May 19, 2008

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”.

Posted in BPMN, Data Mapper | Tagged: , | Leave a Comment »

Creating a first BP-model

Posted by José D. De la Cruz on May 11, 2008

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” ( 8-O “DO NOT TOUCH!!!” 8-O ).

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).

Bottom Menu

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.

Diagram initial of BP diagramWhat 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.

Perspective Fast Menu

Choose a Perspective by menu

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 :-) ).

Fast Zoom

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).

Flow ConnectorFlow ConnectorIn 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.

Error MessageNow 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?

Event Message StartVery 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.

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

Posted in BPMN, Debugger, Designer | Tagged: , , , , , | 1 Comment »

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

Posted by José D. De la Cruz on May 9, 2008

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!

Posted in Architecture, BPEL, BPMN, BPMS, Designer | Tagged: , , | Leave a Comment »

Before you start creating the BP model in Intalio…

Posted by José D. De la Cruz on May 8, 2008

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!

Posted in Architecture, BPMN, Designer, Diagnostics | Tagged: , , , | 1 Comment »

Roles in the simplistic view of a BP-project

Posted by José D. De la Cruz on April 24, 2008

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!

Posted in BPMN, Designer, Uncategorized | Tagged: , , , , , | 3 Comments »

A simplistic view of a BP-project using Intalio

Posted by José D. De la Cruz on April 22, 2008

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.

Posted in BPMN, BPMS, Data Mapper, Debugger, Designer, Web Services, XForms | Tagged: , , | 1 Comment »