Rethinking Zachman – the 'When' column

Next on the stack in the set of amended Zachman columns – the ‘When‘ column.

Unlike the original ‘Who’ column, which (IMHO) was just plain wrong, the problems with Zachman’s definition for this column – ‘time / cycle’ – are more like those that arise from defining the ‘What’ column as ‘data’: not wrong as such, just way too narrow in scope. The appropriate primitive here is the more generic term ‘event‘, and relationships between these events: ‘time’ is just one of several categories or segments of events, and ‘cycle’ is only one of several types of relationship between time-events – which again gives us some idea of the severity of the limitations in Zachman’s original framework.

The BPMN business-process-modelling notation specification gives us some useful pointers to the probable segments here: it lists message-events, timer-events, business-rule events and so on. What’s missing there are physical events and relational (people) events – though that’s hardly surprising, given that the BPMN specification is very much IT-oriented. So although it may need some tweaks in future, it’s probably simplest if we use the same set of segments as for the ‘What’ column:

• physical events: includes ‘disaster’ incidents – fire, flood etc – and any other kind of physical trigger-event
• virtual events: includes messages and other data-triggers
• relational events: includes meetings, phone-contacts, sign-offs and other people-based trigger-events
• aspirational events: includes business-rules (because these focus on meaning and purpose)
• abstract events: includes time-based triggers, business-cycles and the like

Relationships between the events will often be nested and hierarchical: for example, cycles contain smaller cycles, and so on, perhaps ad infinitum. Other relationships may be chained, as in a project Gantt chart.

As with the other columns, we’ll often find event-primitives that link as composites across the segments: an out-of-range data-value may trigger a business-rule which triggers a virtual message; likewise a message may arise from a mechanical sensor, or the sign-off of a document. So there’s some juggling of primitives and composites that we may need to do here; but the basic principle seems sound. The only complication is that, by definition, responses to events are reactive: if we want the enterprise to become more proactive, we need to create an architectural context in which at least some of the events are future-focussed. Another exercise for the reader, perhaps? 🙂

Anyway, the summary: the primitives for the When column are events, and relationships such as cycles which provide meaningful links between those events.