We have an easy notion of the data dictionary: a description of the data at rest in a OLTP system.  But what about the data in motion?  That’s where the Business Event Schema comes in.

More than a simple XML schema, a business event schema is a description that contains the following elements:

• The name of the business process that initiates the event.
• The timing or frequency that this event will occur and the conditions under which it will occur.
• The schema (an XSD will do here) of the fields and the data types for those fields.  In addition, a description of the domain values and their meanings in the context of the business event is required.
• The mechanism by which this event will be published (to be used by consumers who want to gain awareness of the event).
• The expected list of consumers of the event (not that the person doing the describing may not know, and probably never will know, the complete list of consumers.  That isn’t the point.  This is here to help communicate how this event schema can be used as part of a business process).

This is, IMHO, a key deliverable for any architect attempting to describe a business process and how systems that are involved in that process can be integrated with one-another in a real-time fashion.  This event-driven integration goes hand-in-hand with service oriented architecture, in that the systems involved are loosely coupled, with explicit boundaries, using well defined data schemas, and at a coarse-grained level of interaction.