Under Tim's classification scheme, a lot of the real-world business events I'm interested in are regarded as coming from "The Application". That's good enough for some purposes, but I'd like to be able to apply event-driven architecture to the application level as well, rather than having events emerge from a black hole called "applications". It would be useful to have a classification scheme that will permit us (but not force us) to deconstruct the applications as appropriate.
If we are thinking about real-world events, then we need to think about the capture and representation of these events in an event-driven system - including analog-to-digital conversion. I offered the example of automatic extraction of events from video (CCTV in an airport). Tim pointed out some of the practical limitations of current technologies, including image recognition, and suggested passport scanning and human data entry as alternative mechanisms.
It is certainly important for the system designer to understand the accuracy with which an event can be (a) captured and (b) transformed within a given system/environment. Video might be used to track a particular passenger, or merely to provide a warning that the number of passengers waiting for passport control has exceeded some safety level. There may be a trade-off between what is easier/cheaper for the system designer and what is easier/quicker for the human actors within the system. Scanning and data entry may slow down the system and cause longer queues for passport control.
I believe it is important to characterize the event separately from the event-capture, and then give the system designer a choice between alternative event-capture mechanisms (based on such factors as accuracy, cost and system performance). The state-of-the-art in event-capture may improve over time, and we may wish to adopt new mechanisms as they become available, without this forcing us to alter the overall architecture of the system.
There are some useful concepts of event processing that can be derived from VSM (Stafford Beer's Viable Systems Model).
- Variety - range of events to which a given system can respond
- Attenuation - reducing variety (e.g. lumping similar events together)
- Amplification - increasing variety (e.g. detecting small differences between similar events)
- Transducer - a device that converts a stream of events from one form to another (which typically results in some attenuation or amplification).