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.
The first note in this series described a business system as a planned response system where processes respond to business events when alerted by a trigger to the fact that a business event has occurred. The examples I used were each of events occurring in bodies/organisations outside the business system in which the response process would be situated. In this note I will expand on events, particularly on classes of events, and introduce the idea of a unit of processing associated with a business event.
To start, let's analyse one of the examples from before - car insurance claims.
An accident and a decision by the policy holder to make a claim are external to the insurer and its processing. The event occurs outside the boundary of any business system owned or run by the insurer. It's not exactly earth-shattering therefore to think of such events as external.
External business events occur outside scope the scope of a business system, the scope of a project. They are outside the control of the business, at least in the sense of the business having control over their occurrence or the timing of any occurrence.
External business events communicate their occurrence to business systems. The communication they provide is the trigger for the process that the business has ready and waiting for it.
Thus an external business event occurs outside the business system. For a project we could say that an external business event occurs outside the project, say in an actor. External business events are recognised to have occurred because they alert the business system by providing a trigger for the insurance claim perhaps a claims form; for a place on a training course, a booking form; for the supply of a product, a sales order. (Note that I have deliberately used physical examples of triggers here but really all we are interested in is the content of a communication, not the medium of its conveyance.)
If there is something called an external business event then it requires no great leap of imagination to conceive that there might be something called an internal business event and there is!
Internal events occur within the bounds of a business system or project and, in my view, they are associated principally with time or with a condition in the recorded data of the business.
Take two examples
If my premise is correct then the processes related to these must be triggered by an event. But what external event triggers statements? What triggers a purchase order? Of course, in each case it is time which triggers the relevant processing.
For the statement we might imagine a regular monthly event which assesses the financial position. For the PO we might imagine a more frequent review of materials. In each case these internal events have no externally-generated trigger. Time itself is the trigger and typically the processing examines data established as a result of a number of occurrences of external business events.
Thus we have two classes of business events:
You could if you wish distinguish internal events as Time-based and Condition-based. Often I will do just this, although I believe the condition-based events are really time-related. Some authors have elaborated further variants of internal events. For example, BCS sees time, condition and management decision. The first two are as I have described them, an example of the third could be, management decides to set staff bonus level at 1%. I like to keep it simple, and to my mind this is just a variant of time-based, time to set bonus rate.
So, we have two broad classes of events external and internal, where internal may be subdivided by tine and condition.
We have a general naming convention, which I have used above, whereby external events are named in the form 'Customer places Order' or 'Policy Holder makes Claim' and internal events are named as 'Time to ...'.
Next time we look at processes.