The Case for a Clear Distinction between Events and Content.

I should explain my terminology here. When I refer to Events I mean the information about a business-meaningful event – not the actual real-world experience of the event. Similarly, when I refer to Content, I am also talking about information - in the sense of the ‘content of a book’. So, both Events and Content are categories of information and naturally form part of an Information System, in the broadest sense.

Events:	The real-world proceedings that stimulate business activity – sometimes in a pre-defined sequence but often not. These are the triggers for action.
Content:	The documents, conversations or messages that are produced and consumed by business activities. These are the dialogues we use to share a plan, a concept, a history and/or the details of a person, place or thing.

Events (Event Messages) do carry information. However, the information carried has only one purpose: to provide sufficient context to make the Event meaningful to a person or a software component, working on their behalf. It is important to maintain the logical[1] distinction between Event and Content.

Fuzzy and Precise Events:

Events can be regarded as both highly structured and precise and highly unstructured and imprecise messages within a common Event ‘envelope’ (general structure). For example, a movement tracking system may receive highly structured signals from RFID or GPS devices which are then converted into equally structured human-readable business events, But the same system might also receive much more unstructured Event information, possibly capture a ‘text’ message on a mobile phone that might alert of a delay caused by heavy traffic. The emphasis is placed on the value to the human consumer as opposed to, sometimes unhelpful, or misplaced, information engineering rigour. That’s not to say, however, that over time a loosely defined Event may benefit from being made more structured and precise and that some Events need to be implemented as semantically-agreed/syntax-precise data structures from day one.

To illustrate further:

• Fuzzy Events -The Event information may not be as complete or as rigorous as, for example, a structured document or data record might require. However, it might be really useful to know that an Event has taken place even if the information conveyed requires a degree of human interpretation. Maintaining separation between the Event and related Content makes it possible to get value from the Event information without confusing it with the, necessarily precise, business Content information. This is because the Event and the Content have fundamentally different business purposes (as illustrated above). Recognising this difference can be the key to avoiding lengthy data modelling and data standards work (around Identity schemes and other codified data) and thus ensures a degree of business value is delivered as early as possible. The Event may not be interpretable by an IT system – but it may be of use to a person, in the same way a scribbled jotting on Post-it-Note might provide valuable information.

• Precise Events - Paradoxically, the opposite is also true. Content, in the form of a conversation or audio/visual media might be difficult for an IT system to consume and interpret, but is fine for human consumption. In this case, the separation can have the opposite benefit – the Event is always IT ‘friendly’ in the sense it can always be processed in the general sense of routing and subscription, and the Event ‘context information’ may also be processed by rules and derive a new fact or implication.

Aggregated Events become Content over time.

Unfortunately, having said that it’s important to make a logical distinction between Events and Content, the reality is less clear-cut. This is illustrated by the ‘Wave/Particle’ nature of Event information in IT Systems. While they exist as independent, content-light, ‘Business Signals’ during minute-by-minute business operation, they are also ‘Content’ when they are retrieved in sets and aggregations from an ‘Event Log’ or Data Warehouse. Fortunately, from a business point-of-view, this seems to be easily understood. The debate around Event and Content, however, is more prevalent in the IT community and stems from years of building IT applications and databases without a clear distinction between the two.

---

[1] In some circumstances the physical implementation of an Event-based system may include ‘Payload Data’ (Content) bound to the Event. The same logical separation rules, however, apply. The value of this separation identified in MIT’s/AutoID Inc’s original work on the X-internet and EPC standards.

Enterprise Architecture v Services Federation Architecture

This post is based on a number of recent discussions (many of you will recognise some of the thoughts). It posits - A Service Federation approach would provide a better way of understanding, aligning and delivering business and IT services than that of traditional Enterprise Architecture.

‘Services Federation Architecture’ (SFA) is a simplified, more realistic and risk reducing approach to building IS systems. That is, realistic in the sense that the model provides a better representation of how the real-world actually operates.


Enterprise Architects usually approach their work top down– starting with business vision and strategy and working down to the implemented system components and the activities of the people that use them. This way of working has had a degree of success within the four walls of the organisation (in truth, however, rarely applied enterprise-wide). But more importantly, it breaks down across highly federated business scenarios like supply chains. Here multiple business domains interact around a common purpose and at the same time, operate within the context of their own business mission and behavioural traits. This world is less precision-engineered and more negotiated as events unfold – but within a simple model of well defined but relatively simple “touch-points”.

The need for a simplified approach services (from definition to delivery) is obvious in the highly federated world of international trading partners. For example, the joining up both human-based and technology-based services across an international supply chain involving different originations across multiple countries and many languages. Anything other than a simple model of the interfaces between interacting services would simply fail to be meaningful. Each of the members of this supply focused Value System ( “system” in the General Systems Theory abstract sense) operate both within the context of their own independent Value System and within that of the overarching supply chain.

Each constituent organisation is potentially both a consumer and provider of services (within the context of a particular business activity or task). However, despite the apparent complexity, these interacting services are naturally understood by the individuals involved and as is the notion of service governance through policies, contracts and SLAs between parties. The need to document the descriptions of the services provided and the associate information passed between each service (either verbal, paper-based or electronic) is also intuitive. There is a clear understanding of responsibility across the interacting domains and little desire to ‘peek into’ others processes as long as service levels are met or exceeded.

Contrast this with artefacts prescribed by many Enterprise Architecture frameworks. These frameworks focus on engineering rigour and traceability from the coarse-grained business strategies down to very fine-grained technology widgets. The architecture and engineering process wraps itself within its own language and with it, introduces multiple layers of translation between the originating business concept and the final operational outcome. This has the effect of dis-integrating IT away from the business and introduces delay and increases the risk of misinterpretation.

So what? - I believe we might be better off describing, creating and managing services using a “Service Provision in a Supply Chain” pattern rather than the “Construction Blueprint” or even, the slightly more applicable, “Town Planning” pattern. By doing this, perhaps, we can find a way to simplify how we conceive and deliver IT-enabled capabilities and at the same time, reconnect IT to the business.

There are many aspects to this discussion and as always, the interesting stuff is probably to be found somewhere between engineering rigour and operational pragmatics. I would like to explore this thinking here over the coming weeks. I also believe this is fundamental to the whole Services Fabric theme. While similar discussions have taken place in the past within the context of Object Orientation for example, I believe now is the right time to explore a more holistic, abstracted, macro approach to both business (e.g. trading-economies and global ecological needs) and IT (e.g. Web 2.0, Semantic Web, CEP.. et al). I feel this might drive out new insights and principles that can be applied at a macro level (e.g. pan-nation trade) right down to services delivered within an enterprise or by an individual - in all cases; without regard for the service delivery mechanism (e.g. IT-based or human-based).

Other related areas for discussion that come to mind:

• Fractal Model (i.e. a model that is recursively constructed or self-similar, that is, like a shape that appears similar at all scales of magnification)
• Value Networks and Domains of Control
• Service Granularity: How to get in right – the Holy Grail!
• A better representation of the real world and real-world-aware systems
• Social networking and trading models
• Multiple concurrent centres of gravity
• The importance of understanding Events in a federated model.
• Business and IT communication
• The relative importance of re-use and of what?

CEP

Posit: bringing the event and services views together is at the heart a "Services Fabric" - links to event processing here:

Complex event processing (CEP) is a new technology. It can be applied to extracting and analyzing information from any kind of distributed message-based system. It is developed from the Rapide concepts of (1) causal event modeling, (2) event patterns and pattern matching, and (3) event pattern maps and constraints. Complex event processing can be applied to a wide variety of Enterprise monitoring and management problems, from low level network management to high level enterprise intelligence gathering.


Intelligent automation that saves time and improves resource utilization:

Components of business systems typically have different formats for the information they collect about events. Companies cannot visualize all events from disparate components in a cohesive way to manage their environments efficiently. For example, if an IS team needs to figure out what made a business-critical e-business application go down, they may need to understand 40 different event log formats. Root cause analysis of the problem could require input and analysis by numerous system administrators, spanning the network, web and database.

http://www.complexevents.com/