We have been teaching an event-based approach to developments, and particularly in respect of business analysis, for more than twenty years. Over time some of the basic simplicity of the ideas, and their usefulness, appears to have become clouded.
Previous notes have focused on business events; in this we look at the processes triggered by the events.
To recap, business events trigger processes in business systems. Business events can be classified as external or internal and each event is notified to the business system by a trigger which initiates a process. Each process is defined as a response to an event and should provide the full and complete output/outcome required.
Lets look at these responses a little more closely by considering a simple example a training company and a customer wishing to book a place on a public course. What is the business event? Well, following the standard naming convention it would be something along the lines of Customer books public course place. How do we know the event has occurred? What is the trigger? Obviously this is the order from the customer.
We can be unconcerned at this point whether the medium by which the order is received is paper, phone, web-based, SMS . All we are concerned with is that a trigger has been received.
Now, what is the required response to this order? We can assume that it includes checking that the course exists and that places are available. We can also assume that a booking needs to be recorded. Is that it? No, there will almost certainly be further checks and controls on whether the customer is known, whether the delegate is known, what to do if a course is already fully booked all part of the required response to the event.
But, you have almost certainly attended a course. Did you get joining instructions? When was the invoice sent, on booking or only after the course? Here we have two further pieces of processing which are intimately associated with booking a course. Are they a part of the response to the receipt of an order or are they distinct event-triggered processes?
It is possible to make a case for either possibility but the real answer is it depends. It depends on what the business requires.
If the business says that an order is confirmed to the customer and that the confirmation is accompanied by joining instructions then it is all part of the same response. If the business policy is to invoice immediately then this becomes a part of that same response.
If the business only decides on the venue for courses at a late stage then it might not send joining instructions on receipt of order but wait until two weeks, say, before the course start date. What does this do to the processing? It separates the checking and recording of the order from sending joining instructions. But all processes are event-triggered so what now is the event that triggers joining instructions? You guessed it, time!
Similarly, if the business policy is to invoice only after a course then this will cause the processing for the creation of invoices to be separated from that which responds to the order. And what would be the business event which triggers invoicing? If we imagine that the instructor completes some form of post-course report which includes attendance then a likely candidate would be Instructor completes course report.
Back to the initial example a customer wants to have one if its staff trained. The business event is Customer books public course place. The trigger is the order. The process is the response required by the business when it is alerted to the occurrence of this event. Such a process should provide the complete response, no more, no less a minimum response. If the requirement includes the provision of joining instructions then this piece of logic will form a part of the response. It is still the minimum necessary, its just that the extent of what constitutes minimum has changed.
The idea of minimum response was discussed by McMenamin and Palmer who gave it a name the elementary process. The elementary process is an elegant concept. It is the minimum required response to an event. It is event-triggered and when initiated runs to completion or, if interrupted, backs out leaving the business in a consistent state. Once completed, the elementary process stops and waits for a further occurrence of its triggering event. Elementary processes are of variable size and complexity but always provide a response that the business expects to an event. Each elementary process is discrete; each is separate from all other elementary processes.
Now we can state a slightly modified view of a business system a business system comprises a set of elementary processes. Since, by definition, elementary processes are event-triggered we need not state this again.
In the course booking example we could have one elementary process, we could have three. In fact we could have more. If the business expected that joining instructions should be produced at the time of booking, what would happen if the venue was not known? Presumably there would need to be a further elementary process which would pick up where joining instructions had not been issued and rectify the failing. The event for this could be time, every week perhaps, or when a venue is booked so a part of the required processing for the event Venue confirms course booking would then be to produce joining instructions. Any further bookings for the same course would then have joining instructions produced immediately.
But wait a minute, that would mean that a piece of process (business) logic would exist in two places, in two separate elementary processes. Yet we have said that elementary processes are separate and discrete! There is no issue here; there is no bar to elementary processes including parts of the same logic or rules. The key is that each elementary process includes all the processing required as a response to an event.
Take a breather and think back to business systems you know and love. Do any fail to live up to this view? Arent they all event-triggered? Arent they all minimum response systems?
Its possible that you will find that a system with features that seem to contradict the above. I would be surprised if you did not. I would suggest thought that this is because you are seeing a physical implementation. Elementary processes have their roots in a logical or conceptual view of systems; the instant we introduce considerations of design and implementation so some of the purity of the idea is dissipated. This is not a problem. In fact it is a positive boon, because one of the other factors we need to keep in mind is that we are not worrying about business systems for the sheer fun of it; as business analysts we are expected to improve the business and business events and elementary processes help us to do this.
So, business systems are set up to respond to business events. Business events trigger elementary processes. Each elementary process provides the complete but minimum response to an event and elementary processes are each separate, one from another.
But how many elementary processes are there in a business system and how do they relate together? What was it about Alec Sharp's book that got me thinking? How exactly does this help a BA?
All this and more in the next exciting episode!