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.

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