Wednesday, April 01, 2009

Enterprise as a Network of Events 2

Following my post on Enterprise as a Network of Events, Nigel Green drew my attention to something he wrote a couple of years ago on the case for a clear distinction between events and content, in which he points out that "aggregated events become content over time".

As it happens, I touched on something like this in my 1992 book on Information Modelling. At that time, the specific question I was addressing was how to represent the history of organizational change in a data model. There are two basic options.

  1. History is represented as a series of snapshots of the organization at specific times. If you want to know what the change was, you just have to compare two snapshots. (For example, this is how page history is represented on Wikipedia.)
  2. History is represented as a series of changes (differences). Then if you want to know what the state of the organization was at a given time, you just have to aggregate the changes forwards or backwards from a fixed point.
From a purely logical point of view, it doesn't matter which of these two representations you adopt, because you can always derive one from the other. In practical terms, however, you may find that one representation is a lot easier to work with than the other.

What both representations have in common is a definition of information in terms of difference: a difference that makes a difference, as Bateson puts it.

Information as Difference

Hold your hand perfectly still, palm upwards and resting comfortably on a table. With your other hand, drop a small coin into the palm. You will feel the impact, and if the coin is cold, you will feel the coldness of the metal. Soon however, you will feel nothing. The nerve cells don't bother repeating themselves. They will only report to the brain when something changes. Information is difference.

A lizard hunting insects operates on the same principle. The lizard's eye only reports movement to the lizard's brain. If the hunted insect settles on a leaf, the lizard literally cannot see it. But the moment the insect starts to move, whop, the lizard can see it again, and the tongue flickers out and catches it.

But there are differences and differences. Information is difference that makes a difference. You were probably aware, as you dropped the coin into your palm, your eyes told you automatically, without your brain even asking, what the value of the coin was; but you were probably not aware what date it was minted. This is because (unless you are a numismatist) the value of the coin makes a difference to you whereas its date doesn't.

What is it that makes a difference to a lizard, to a numismatist, to you? Surely not the same things. What is information for the lizard is not information for you, and what is information for you is not information for the lizard.

This is why the perspective of information is important. Perspective defines what counts as information at all, perspective defines to whom the information makes a difference.

Enterprise Strategy and Difference

Now what's this got to do with the enterprise? There are two important differentiation questions for any enterprise: how do They differentiate Us, and how do We differentiate Them.

Firstly how do They differentiate Us. In other words what differences in our products and services or organization are (a) going to be noticed by external stakeholders such as customers and (b) going to affect the behaviour and attitudes of these stakeholders.

Sophisticated marketing organizations pay a lot of attention to this kind of thing. Does it make a difference if we put this in a blue envelope? Does it make a difference if we have a female voice here? Sometimes you have to experiment with differences that don't matter, in order to have a refined view of what differences do matter.

Secondly, how do We differentiate Them. What are the strong signals in the environment that we must respond to, and what are the weak signals we might respond to? An organization that responded to every weak signal would be impossibly unstable, so most organizations have operational processes that respond to strong signals, and some form of business intelligence that scans the environment for weak signals and identifies a subset of these signals demanding some kind of response.

Sometimes the appropriate response to some detected difference or discrepancy is some kind of business improvement, such as business process improvement and/or system engineering. Which means that the history of the organization is inscribed into its current structure and processes.

"What's the purpose of this process step?"

"We've done that extra check ever since we got badly burned in the XYZ deal five years ago."
If we knew enough (which of course we don't), we might conceivable infer the current state of the organization from a careful analysis of all the events that have ever happened to it. That would join this post back to where we started. Neat but impractical.

But that's not actually what I'm trying to do. I think understanding an organization as an information-processing system helps us to do two practical and concrete things.

  • Diagnose the current problems and opportunities facing a complex organization.
  • Design an event-driven business improvement process, based on business intelligence.

My next question is: what kind of business model supports these challenges.


Joar said...

Thanks for an interesting article!
I just want to share some thoughts on your comparison of the two basic representations. You say that the two options are logically interchangeble. From the perspective of the information model as such, I agree. However; since implementing an information model will always mean introducing data, this will no longer be true when implementing. In fact, I believe this to be one of the major reasons for e.g. CASE-tools to fall out of fashion: once you start implementation you cannot really use the tools again.

The first approach can simply not handle e.g. that you change the name of an entity after the system's being deployed without loosing the data. When using the state comparison option it will not be able to tell the difference between:
a. the entity A's being renamed to B and
b. the entity A's being deleted and a new entity B's being created.
Any attempt at auto generation based on the model state would therefore mean loosing any data of entity A.

This is actually the reason why we've chosen to let our tool (RISE) for model driven information system development keep track of the model's evolution instead of its state. I.e. it keeps is a record of the series of changes as in your second option. This means that you can maintain and change your solution based on changes to your model without compromising the data. Not least important during development phase since basically all development is re-development of sorts.

When implementing: that's a difference that makes a difference!

Joar Swenning

RISE to Bloome Software

Paul Wallis said...


A very interesting series of posts, which took me back to when I worked in the Oil & Gas Industry. We had two Real-Time Monitoring Systems attached to the process control equipment that logged hundreds of thousands of values every few seconds to create a history of what happened on the manufacturing plants.

Both of the systems worked in different ways, following your two basic options representing change.

The first system would snapshot everything - tens of thousands of values every few seconds. For each point it would also store a mathematical context for that value - the standard deviations to previous values, max and min values over rolling periods of time, etc...

The second system would look for a difference. Has the delta between this value and the last values changed sufficiently to store the number? If so, simply store the number. Partly, the context for the event was defined by the meaning of “sufficiently” and the number of other values changing at that time.

What was readily apparent was that the context of an event changed the perception or interpretation of the event. Streamlining the way that engineers could look at the flows, temperatures, densities, pressures at the time of the event enabled them to more quickly understand what was happening - apply meaning through context.

The same is true within the enterprise when it comes to placing meaningful context around events and an analogy can be drawn from the systems described above.

For the past ten years I’ve been working on a method of mapping how data flows around an enterprise, which is analogous to how product flows round a manufacturing plant.

When we can map how the enterprise operates in terms of data flow (which in itself could be seen as a sequence of events), and we can understand how the assets within an enterprise are used to support that flow, we can start to see the analogy to Oil & Gas more clearly.

By understanding the point in the data flow where an event is generated our perception of the event changes, we place a business context around the event and we gain more meaning - just like the engineers do on a petrochemical plant.

If you want to learn more about how it can be achieved you can find a wiki page here (, or visit