Business Events - their place in developments - Part One

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.

This note reconsiders events and how they fit with business systems. It forms the first of a short series.


Introduction

Over the years I have become increasingly convinced of the usefulness of thinking of business systems as comprised of responses to events – a customer places an order and the supplier supplies it; a car driver puts in a claim for an accident and the insurer pays it (in an ideal world at least! ); a person applies for information on joining a club and the club provides details; and so on.

In each case something happens, some communication is effected as a consequence, and some activity kicks into life and produces a response.

There is nothing new in this and mine is certainly not the only company to find events of benefit when trying to scope projects and to identify requirements. In my experience the core ideas go back to McMenamin and Palmer (Essential System Analysis, 1985) and I was reminded of them when I read Alec Sharp’s book on workflow – see the separate note on Business Processes. This triggered me to write down my own thoughts on the subject.

Over the course of three or four notes I intend to set out some definitions for terms such as:

  • Business Event
  • Trigger
  • Elementary Process
  • Response/Outcome
  • Beneficiary
  • Measure

show how these relate together, and highlight why and how they are useful to Business Analysts.

In this first note, I will focus on events.

The basics of Business Events

All business systems comprise processes. (We could spend a while defining what we mean by a process; for now I will assume that everyone has a working understanding of the term.) Each process in a business system is there for a purpose, or at least it should be! It is intended to produce some output which is of use to the business and/or its customers. It should also run correctly and produce correct output each time it runs, and have a controlled means to handle failures (errors).

But what makes a process execute? Do processes run whenever they feel like it? Of course not.

Let’s go back to the examples I used earlier.

A customer places an order – so, presumably the customer has determined a need for something which can be provided by a supplier. The supplier would have in place a process to handle orders and this would be triggered by the arrival of an order.

A car driver puts in a claim for an accident – the insurer will have a process set up to deal with claims and this is triggered by the arrival of a completed claim form.

The pattern is obvious. Something happens, the business system is alerted to the fact that something has happened, and a process is initiated.

A Definition

The thing which happens is an event. The Oxford Dictionary (on-line version) gives a definition of event as:

'a thing that happens or takes place, especially one of importance'

In the real world there are many events occurring all the time. A specific business, and a specific business system, will be interested in just a subset of these so let me modify the definition just slightly. A business event is:

'a thing that happens or takes place, which is of interest to a business’

A business sets up processes to handle these business events but runs them only when told that one has occurred. So, if a driver has an accident but fails to inform the insurer then the claims processing will not be triggered. The claim (embodied in some form of communication) provides the trigger. When a claim is received it initiates the claims process.

We can generalise this – a business event occurs and creates a trigger which in turn initiates a process in the business system. The process will have been defined to provide the necessary response to the event. When triggered it does so, and then stops and waits for another instance of the business event to occur.

A Business System

Expand this and you can conceive of a business system comprising a set of processes, each of which is defined to provide the required response to a particular business event. Each business event produces a trigger which initiates the appropriate process. Once a process has finished its processing it stops and waits to be triggered again.

Thus business systems are planned response systems.

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 functional 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, business staff have little difficulty in understanding the idea of triggers and responses.

Still to come

Are all business events the same? Are there classes of events?

How large is the process that responds to an event?

Who benefits and what measures can be used to assess processes?

Watch this space!

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.