Dealing with Time in Business Process Descriptions

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.

0

BPMN to BPEL: be careful

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

Pre-BPM Pragmatics

In most human systems communication in Business Processes is normally done via the “data transfer” (“fill form XYZ-02A1, sign it and give it to me”) where each participant transfers segments of data that are then somehow put in a bulk of data (“let me put this into your application folder and I’ll come back to you”). This approach considers:

• each source/sink of data an isolated element in the puzzle (“silos”)
• the sources/sink of data are difficult to interact with, and
  therefore communication time should be optimized (reduced to the
  minimum possible size)
• interactions are not interactive, but mostly single-shot. This guarantees the integrity of process execution.
• each source/sink of data is a trusted participant:
  • Business logic is somehow built in each one
  • each knows how to do its task and does it correctly
  • The whole bulk of aggregated data is passed from one source/sink to the next

AN EXAMPLE
Let us suppose that we have this long-running business process. It is some application that requires legal papers (visa/University/building a house/etc.). I choose this as example because I’ve seen an increase in the number of e-government initiatives, but most of them only give you access to some PDF document you can print.
I consider in this example that the application process is compatible (but not yet implemented) with the notion of “electronic record” or a dossier that can be made up of digital files.

If you take into account the tacit modeling principles listed above, no wonder why you receive mails like this after submission:
“We hereby confirm that we have received your application folder. Do not contact us. You should receive a response within 2 months. The processing delays are notified via our website.”

Besides, the bulk of data is built using non-scalable/non-incremental means, like hardcopies (“please print this form and include it in your application folder”) that do not support versioning, and that can only be changed by a total blocking of the processing.

Let us say that you receive, after 2 months waiting:
“Dear Mr./Mrs., we have found that section 13, paragraph B, line 3 is not readable. Please correct it and re-submit your application folder… Do not contact us. You should receive a response within 2 months after re-submitting. The processing delays are notified via our website.”

Sounds like realistic to you? Let us say now that you changed what you were told to change, but because of the processing times, a legal certification –valid for only 3 months– will expire during the resubmission. You were careful but he asynchronous nature (silo + slow communication) you cannot avoid it. Therefore, this will invalidate your application once more.

DEADLOCK IN PRE-BPM SYSTEMS
Let us suppose now that you guessed the expiration of this legal document might be a problem. You prevent
this issue and get your legal paper renewed after sending the application, just in time before the three months expiration delay.
You send it, so your application should be updated with a valid version of the legal paper. However, the application is considered as incomplete and will be sent back to you.

Why is this happening?
The processing team considers that adding a new element “is against the rules” and cannot be done without “opening the door to other people abusing the system”.
No smart administrative chief will agree on doing that.

Worst, the current, valid version of the legal paper is no longer in your hands, but somewhere in that organization.

Transfer Bulk of Data Patterns
The data-transfer approach in pre-SOA and pre-BPM makes the bulk of information of application X be on top of a pile in bureau of A, and then somewhere in bureau of B, and so on. When sensitive information cannot be seen by B, some person AB has to be included to hide/exclude that information from the bulk. Once B finishes his processing, then AB can rebuild the bulk X.

This introduces delays, complexity and, thus, increases the probability of errors. In a paper-based world, this is translated into more workload per employer, more focus on repetitive/tedious tasks than on doing value-adding work, and more stacks of papers and of procedures to process them.

Then, scalability gets even more compromised.

CONCLUSION
This is not flexible, this is not scalable, and this is not proper: the user is not satisfied, the process is not transparent, and the service provider cannot really assess where the problem is. Then, there is no improvement.

How come that we have technology to interact with the rest of the humanity (mostly for fun) and not with the processes that really add value to our jobs and even our lives?

This can have a great economic impact. In Switzerland, where I live, a study demonstrated that obtaining a working permit for an EU-national takes 10 weeks but that the real processing time takes only 15 minutes. For non-EU nationals this takes even longer.What is the cost of these delays? the lost revenue for all the stakeholders? the stress?

As the say here: Bouf! :-<

What to model – II

.
Now that we have a first idea of what our model of Business Process should be like.

However, what is it supposed to look like?

Well, as in any language, there are several levels of analysis: lexical, syntactic, semantic and pragmatic. Whereas the first two or even three depend on the language, the pragmatics define what you should obtain in real life.

Surprisingly, lots of information exist on those three first levels of language analysis. I mean “surprising” because they are just a means to obtain what you really want. This means that the modeler is given all this:

• rules about what he can or cannot express @ each level
• many shorthand & tips & tricks about how to translate from one level to the next
• rules of governance, because this gets really complex

This does not only overwhelm and give headaches to modelers, but the design space explodes because of the dimensions growth is exponential.
This is natural in approaches where the modeler should create a number of models that go from a very abstract one to –finally– one that is really executable, and those are written using different languages.

Since Intalio is not like other modeling tools, you can create your model and make it executable after very few changes. It is power at your fingertips.

I will start from the other end, the pragmatics, as a more natural way to constrain the business process design.

Actually, I will deal in this entry with what we should avoid (the design space outer space), in order to establish what we want to get (the actual target: BPM pragmatics).

THE BASIC THINGS TO MODEL
As I showed in a previous entry, a process model in Intalio is a description of what you actually do, in the form of tasks
Some features of that description are the following:

• Each task can be either composite (made up of other tasks) or not
• These tasks are performed by one or more actors
• The actors that fulfill the tasks are modeled via pools.
• The actors can be either organizational units, roles, real people, IT systems, or some unknown system.
• The most fundamental thing is that the functional/non-functional contract linked to each task is performed by some actor

Once we have understood what tasks and actors are about, we should start thinking of how to make them work together. This is done via communication:

• The underlying modeling principle is to make actors communicate in a proper, flexible, scalable manner.
• The model of sequence and synchronization will tell what action is enabled to be executed
• The process logic will tell the orchestrator if a given task should actually be triggered
• The actual execution will be performed by the orchestrator.
• Several actions can be triggered in parallel, each branch having its own process logic. The merging of branches is also done by the orchestrator
• When required, non-merging branches (or autonomous branches) can also be modeled.

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

.

What to model

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

さようなら

A fiction to be automated & the introduction of an Orchestrator in the Business Process

Buna Ziua,

I could finally correct the problems with the animation in YouTube, then I can continue pouring the entries that were in the waiting queue. I promise I’ll update as quick as possible.

Having introduced the notion of orchestration in the last entry, we can get into deeper, fuzzier waters. Orchestration is as natural as vast, and many architects have created different solutions for the last 20 years. Nowadays there are standards, but so many and wrapped with so much marketing hype, that the subject is pervasive but remains dim, secluded. I illustrate here what I have succeeded to decode.

How to identify an orchestrator? it corresponds to the normal transfer of information that is present in the business process. This transfer is so fundamental that it is invisible in many organizations.

Let us imagine that your organization you has implemented paper-based processes 😳 . I know, I know. I don’t mean to abuse you but I am forced to create a horror scenario 👿 .

If this was the case, then customers (internal/external) should fill forms in order to ask for a service 😕 . Just imagine ❗

For example, if you as employee want a new 24″ screen 🙂 , you may be forced to fill a form to ask for that new screen 😦 . This paper-form should pass through the desk of your boss 😯 for a signature. Let us dream that your boss is happy with your request 😉 because your screen is more than 6 months old

Once she happily accepts, this form should go to some budget office. Let us imagine –then– that yours & some other requests are put together in a package that corresponds to the IT purchasings. To make things worse, assume that there is some person in the organization that should look at your request, ask for a few providers and examine their proposals, check them out once more with your boss or you, and then put it on the binder of the accepted & budgeted purchases. 😥 Ufff! Let us suppose that this binder arrives to the financial department, and that they will do the actual transaction.

In order to finish the BP, imagine that the provider receives and order (whose copy goes to your file binder) and that once the screen is sent, the bill will arrive to the accounting dpt. Someone over there will eventually pass it to treasury, that will do an –imaginary– payment to the provider.

Let us even imagine 💡 that your request has steadily grown to become a pile of paper forms with signatures from each person that has seen it, checked it up, approved or rejected it + photocopies of specifications/ bids/ offers/ contracts. Of course, in a theoretical scenario like this, one could yet imagine that copies of documents should be produced & sent to different sections of the organization ❗

Of course, this is only fiction. Things like those cannot occur in real life 😉

In order to avoid this Dantesque scenario, the wise management guys introduce an orchestrator. The orchestrator should replace the paper forms & binders. Not every single document, as most documents should be stored in a file for compliance requirements; such archive should be now performed in a digital format via a DMS (Document Management System — in french: GED) .

The orchestrator will require only the data that should be stored in order to satisfy the needs of future stages of the business process.

• For instance, the requester ID should be kept from the beginning because @ the end, the screen should be delivered to the requester (you 😆 ).
• Another example are the price and quantity of items that will be purchased, since this information will affect the financial information that is used for creating a budget, then to place the order, and finally to check the bill before issuing the corresponding payment.

Seen like this, any solution that can help us retransmit the informations to the services is good for the work. Be cautious with this kind of wild-, first-hand-, easily-sold, profusely-documented perspective of SOA. If you follow this simplistic analysis, then there is the danger to consider that workflow systems, ESB, Web-Services, CORBA, and any other EAI approach and technique are almost synonymous. They are very different things, specially when considering how the CRUD is split among the layers and the process’ stages, and when the persistence and the use of XML are analyzed in detail. Not to talk about BPM.

We will discuss those differences later on. Please try to think of what are the differences when:

• the orchestrator is implemented in such a way that all the information should pass through every process down the stream, against
• an orchestrator that sends to each process only the information that the specific process needs to perform its work

This reflection time will give you the first hints towards a classification. Please consider also the fact that most approaches mentioned above do not take into consideration the interactions of people during the process ➡ They assume that most information processing (transfers + services) is done automatically 😕

This cannot be realistic in our scenario 😯 . Just give it a last thought. Then, try to sleep… if you can 😈

Hasta luego!

The Business Process without orchestrator

In order to understand what you’re really obtaining from a BPMS, it is fundamental to see what the process looks like.

We illustrate here how an imaginary manufacturing company processes an order from a customer.

The company has 7 organizational units: Manufacturing (fabrication), Sales (ventes), Purchasings (achats), Marketing, Engine Certification, Certification of Technical Personnel.

Hey! I already started pouring some French here! Just as I had promised! 🙂

The company manufactures plane engines. Since this is a regulated industry, the engines must be tracked because of certification needs, and the personnel must also go through a detailed certification and tracking process.

• Everything starts when the order is received by the sales department. This is communicated the marketing deparment via the CRM.
• Once the deal is settled (price, quantity, discounts, etc.), the salesman checks whether everything that is required is already on stock.
• If it is not the case, the order goes to the manufacturing unit.
• First thing to do in the manufacturing unit: retrieve the Bill-Of-Materials and check that everything is ready.
• If some engine component is lacking, the purchasings unit should do what is required.
• Once all the components are there, the manufacturing can actually happen.
• The manufactured goods are packaged and put on the inventory.
• The sales department is notified that everything is ready.
• Shipping information is retrieved and confirmed with the customer
• For the transportation of goods, the purchasings department is called once more
• Once the negotiation with the provider of transportation is finished (weight, origin, destination, nature, price, delay, etc.) the goods are sent to the customer.
• After the goods are received by the customer, the Support Services (SAV-Service après vente) start. This service will feed the units of marketing with new statistics about problems, satisfaction, rate of failure, etc. This service also feeds the information required for the certification of each model of engine, and will help with all engine repairs (that can only be done by certified personnel).

This is illustrated in this illustration. It is an animation of the steps of the process.

It replaces and corrects this poor YouTube video. I will never put any other animation over there… 😦 it is quite un-intelligent to do what they did with my small example.

In a future entry, we will see what happens when this process is done via an orchestrator.

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