Exercises and Case Studies
As the book comes to a close, we will explore some exercises and case studies. The exercises are sample business processes that are illustrative and you are encouraged to try and build them out yourself or simply follow along with the possible solution described. The case studies are the essence of real-world solutions seen in the wild. These processes have been sufficiently changed so that no process secrets are exposed.
Exercise – Education class enrollment
You have undoubtedly attended vendor education classes in the past. Think about what has to go on behind the scenes to host such a class. We will focus on a part of this process called student enrollment. We can imagine that a class on a particular topic is going to be taught at a location on a certain date. IBM education is going to teach the class and believes that there is sufficient demand in the topic in that particular city. An instance of a class, in a city and on a particular date is called a class offering. A few months before the class is to be delivered, the enrollment for the class begins. Enrollment closes three days before the delivery date. Anytime between the class being originally offered and two weeks prior to the delivery date, the class may be cancelled by the class administrators.
Challenge – Design and implement the enrollment process
When we think about any new process that has been handed to us for design, it is good to walk through the following generic questions:
Q: What is the purpose of the process?
This feels like one of those awkward questions but some reflection should show that we can't begin to design a process if we can't articulate an answer to this question. We don't have to describe how the process will achieve this task. After all, that is why we are going to design it because we don't know how it will work but we must be able to describe what its purpose is. For this scenario our process is to manage the enrollment of students for a class offering. And we should stop there. If we attempt to say more, we are probably in design.
Q: When does the process start?
Our process starts after the decision to offer a class has been made. How that particular decision is arrived at is not in scope and we can ignore it completely. We will assume that the class has been advertised (somehow) and that enrollment should begin.
Q: What is the input to the process?
Most if not all processes have some initial input data supplied to them when they start. It is this input data that differentiates one process instance from another. Those processes which don't have input data quickly solicit some as part of the process to allow them to distinguish themselves from other processes. In our story, the input to this process is the details of a class offering. Here we could go off and perform interview after interview to meticulously pin down all the details or we could go to the other extreme and treat our input as a black box simply called a "class offering" and do nothing more than that. As always, the correct answer is some happy medium. I suggest making notes of the low hanging fruit. If we say that the process starts after a class is offered … then ask about the attributes of an offered class. For our story, we will assume that a class offering is made up of the following information.
Are all of these attributes of a class pertinent to our process? Probably not. Will there be other attributes that we will need to work with that haven't yet been captured? Almost certainly. Determining the inputs to the process does not have to be a one-shot event. If it is later determined that in order to initiate a new process instance more information than we thought we needed is required then we can either negotiate to have those items supplied to the process when it starts or else we can include steps in our process to explicitly source that information from within the process itself.
Q: What are the possible completion states of the process?
Every process instance must eventually come to a conclusion. Determining when the process has finished is a key consideration and one that if captured will guide the design. Reviewing our process notion, we remember that it is the enrollment of students into a proposed class. Enrollment ends three days before the class is to be taught or if the class is cancelled. In this last sentence, we have the core of the process termination states. There are two of them. One is that the enrollment process ends because the class is ready to be taught and the other is that the enrollment process ends because the class has been cancelled.
Q: What is the output of the process?
Unlike inputs, not all processes have distinct outputs from an IT data perspective. If the process we are following is that of making a cup of tea, there is no "data" at the end but is instead a sequence of steps that a human being follows. In our process however, we do have new output data. If we think about the purpose of the process, we will find that the output is a list of students enrolled for the class.
Q: Who participates in the process?
Most IBPM based processes have an element of staff interaction where human beings perform some role in the process. Identifying the roles of these people and how they interact can be key. The participants usually come to light during the interviews.
My first attempt at a solution was to use IBPM as a BPMN diagramming tool and I came up with the following:
Let us walk through the story. It beings with a parallel gateway that splits the process into three parallel tokens. The first (top) reaches a timer that puts that thread to sleep until 3 days before the class is to start. The second (thread) waits for a Message Event that represents a request to cancel the class. The third (thread) waits for a Message Event that represents a request to enroll a new student. Notice that the new student event, once processed, returns back to waiting for another new student event. This appears to be an unbreakable loop which might cause the process to never end. Notice however that either a cancel event or a wake timer event will also occur. The result of these is an exception or a terminate event either of which will cause the process to terminate in its entirety. This process now looks pretty elegant … unfortunately, we have some problems.
BPMN semantics state that when a terminate event is reached, the process is immediately terminated. This is what we expected. The BPMN semantics then go on to state that if the process that is terminated is a child process, the parent process regains control and continues. This too is goodness since we expect this process to be invoked as part of a larger process. Unfortunately, IBPM doesn't adhere to the BPMN semantics when it comes to the terminate event. If a terminate event is reached in IBPM, both the process and any parent chain that caused it to be reached are terminated and this is not what we want.
There is another flaw with this process as it stands. The cancel exception throws an exception (as per its design intent) but it does not pass any data (other than the nature of the exception) back to its caller. What this means is that the knowledge of which students are already enrolled will not be returned back to the caller in the event of a class cancellation and we said earlier that the outcome of student enrollment will be the students currently enrolled … this should be true whether or not the enrollment process ended because the class was cancelled or whether the class is ready to be taught.
Now we approach our second level of refinement and after some thought, come up with the following:
Superficially, this process looks substantially different from our last attempt but actually follows the same principles. The core of the story is the activity called "Wait for new Student" which we have implemented as a sub-process. The process steps that it encapsulates looks as:
Ok … this is obviously going to need some explanation. The activity called "Wait for new Student" will block until a new student event arrives. If one of these events arrives, we transition to "Record Student" and then go back to waiting for a new enrollment. This we can understand easily enough. Now notice the attached event handlers that are attached to the activity. There is one for a message event and one for a timer event. The message event will wake up when a cancel class event is received and the timer event will wake up when it is 3 days before the class. Either of these events causes the termination of the activity to which they are attached. Since this activity is the sub-process which is waiting for a new student, we have in effect found a way to break out of our loop.
Notice also that if the class is cancelled, we no longer throw an exception. Instead we now return simple control to the caller but in the data returned, we flag that the class has been cancelled and assume that the caller will handle that information appropriately.
Is this the only possible solution? Probably not … and that is where the artistry of BPM comes into play. We have married together here a number of competing factors. We have attempted to capture the functional intent of the process, we have attempted to make the process as readable and easily understood as possible while and finally we have designed the process so that it can be actually executed on the IBPM runtime. Ideally all three of these goals can be satisfied but as shown, sometimes we have to pragmatically trade one for the other.
If we had used our first attempt at the process, we would have discovered the termination of all levels of the process and have to rethink our design (which we actually did). Only experience and diligent reading about (and experimentation with) the product will allow you to head-off such situations. The cancellation situation would ideally have been caught early enough to negotiate changes at the process level as a whole.
Now, back to the story … as student enrollments arrives, where are these student enrollments being recorded? Ideally they are being recorded in a data store such as a database. Storing them within the process itself is normally not a good idea. In general. unless it is control data, process data should be stored where other data normally lives and that is in a database or other external application.
Having created a BPD and drawn it out in AE unfortunately the process is not yet ready to run. Generally, less than 50% of the work has been accomplished in drawing the diagram till it is ready to be executed. As they say, the devil is in the detail and each element on the BPD canvas can have a lot of detail associated with it. A question of when the detail should be added arises. Should each activity be fleshed out as it is added to the diagram or should the diagram as a whole be drawn and then fleshed out with detail? There is nothing in the tool that forces you to work one way or another and each have strengths and weaknesses. Personally, I like to draw out the whole diagram and then go back and supply more details. One down side to this approach is to remember to actually add the details after creating the diagram. Too many times I have created a diagram and added the details I remembered to add only to find unexpected results during testing which were caused by other omitted details. One solution to this is to change the color of the activities after they have been implemented leaving their default colors to mean not implemented. Unfortunately not all activities can be colored. If adding the details later has this flaw why not add details as we go along? This itself can result in a different problem. It is very common to start building out a process only to make dramatic changes as we go along. If we fleshed out every step as we progress, we would be wasting effort discarding or dramatically changing much before the final process.
In our story, we have two event types. One for the cancellation of a process and one for the arrival of a new student registration. These types of events are used to indicate to the process something happening outside of the bounds of the process and for both of these, events are good models. We don't know if or when a class will be cancelled and we don't know when students will register or how many. Associated with an event is event payload data. This is information that travels with the event. For a student enrolling, we will assume this to be the details of the student. In our first pass at modeling, we don't have to pin down all the details of this data other than to know it exists. In IBPM, events are associated with UCAs. Because there are two types of events, it makes sense two define two UCAs.