Business Events - their place in developments
We have been teaching an event-based approach to developments, and particularly in respect of business analysis, since 1985. In the period since then some of the basic simplicity of the ideas appears to have become clouded.
This note takes the simple view and sets out what events are and how they fit with business systems. It forms the first of what will be a short series on the subject.
Introduction
Business Events provide Business Analysts with answers to a number of problems with which we all struggle. Problems such as:
- What is the scope of the project?
- What are the requirements?
- How can we confirm that we are working on the correct things?
Business Events as an aid to analysis is hardly a new concept; I first read of them in 1985 in Essential Systems Analysis by McMenamin and Palmer. Yet they are still used less often than they could, or perhaps, should be. They provide an inherently simple and understandable, yet immensely useful, aid to analysts.
In this note I want to address the simple question
What is a Business Event?
Business Events defined
What is an Event? Well, the Oxford Dictionary (on-line version) gives a definition of:
'a thing that happens or takes place, especially one of importance'.
This is absolutely appropriate for our purposes - an event is something which happens. But there are lots of things happening all the time, only some of which are of importance, or of interest, to a business.
Why are they important? Because the business needs to respond to them in some fashion; it needs to conduct some processing.
This process/response will have been defined in advance of the event occurring, thus we can think of a business system as including processes each of which is the planned response to the occurrence of a particular Business Event. But this only works if the fact that the event has occurred is communicated to the process in some way. Let’s call this communication the trigger.
So, an event occurs; the event creates a trigger; the trigger is communicated to and recognised by a planned process; the process executes and creates the intended outcome. Oh, and then the process stops and waits for another instance of the appropriate event to trigger it again.
Business Systems
And there you have a business system. All business systems comprise a set of processes where each responds to a particular event. The system responds only to a subset of all the events that occur in the world and only when the event is notified to the process by the arrival of a trigger.
An alternative view
Of course, there is always another way that we can look at this idea of events and business systems. Business systems comprise many things but fundamental to them is that they include processes. For the purposes of this note it does not matter how I am defining a process; here it is simply a piece of activity. Equally it does not matter whether the process is conducted by a person or a machine, it’s still a process.Do such processes erupt spontaneously into action, or does something have to happen to tell the process when to run?
Obviously it is the latter. Processes do not run simply whenever they feel like it. (Although you could believe that to be the case with some systems!)Something happens and the process executes as a result of being triggered. Let’s give a name to the thing that happens and which initiates or triggers the process; let’s call it an event.
Thus an event is something which happens and which triggers a process.
We are back to the same point. Business systems are response mechanisms which produce defined outcomes when triggered by the occurrence of specific business events.
But does this really help us as BAs? It certainly does. The scope of a project is defined by the business events to which the business must respond, no more and no less. The requirements of the project are the planned responses that are triggered as a result of the events and, as we will discuss in a later article, the business staff have little difficulty in understanding the idea of triggers and responses.
The concepts in this note are covered to some extent in our courses on Requirements Engineering and Modelling Business Processes. For further reading, the Robertsons do the concepts justice in their book on Requirements - see sidebar.