Rethinking Zachman – the columns

More on rethinking Zachman – this time on the vertical columns.

Way back in the 1980s, Zachman defined just three columns for his original framework:

  • What (data)
  • How (function)
  • Where (network)

The trouble is that all this gives us is records (data) of actions (function) – which is pretty much meaningless, really. (Though unfortunately too many IT specialists – such as one particularly frustrating project-manager at my last client – still seem to think of that as the main focus, or even the sole focus, of architecture.) Hence quite early on, Zachman added another three columns:

  • Who (people)
  • When (business cycle)
  • Why (business rule)

All well and good – sort of – as long as the only interest of ‘enterprise’-architecture is IT. But if we want to move beyond those boundaries – or even for anything other than some fairly simple data-and-function modelling – the limitations soon become apparent. For example, how do we map even basic physical IT hardware such as servers and routers? They should probably go into the ‘What’ column – except Zachman says that that’s reserved for data only. Similarly, we can map manual use-cases to the ‘Who’ column – but there’s nowhere to put an automated use-case – which we need to do when we’re planning out process re-engineering. Oops… And there are other, more subtle confusions: for example, Zachman correctly asserts that architecture depends on primitives, but his ‘Why’ column, he says, consists of ‘ends and means’ – yet ‘means’ are clearly ‘How’, not ‘Why’, hence ‘ends and means’ are a composite, not a primitive.

The result is that whilst the rows are essentially okay as they stand – with a few minor tweaks, as in my previous post – we really do need to re-think the columns, pretty much from first-principles, in order to make the framework usable for real enterprise-scope architecture. Here’s my suggestion for a rework:

  • What: assets of any kind – physical objects, data, links to people, morale, finances, etc
  • How: activities or services – described independently from the agent (machine, software, person etc) that carries out that activity
  • Where: locations – in physical space (geography etc), virtual space (IP nodes, http addresses etc), relational space (social networks etc) and suchlike
  • Who: roles and their capabilities and/or responsibilities, as in the ‘actor’ of a use-case, or a ‘swim-lane’ on a process-diagram – which may be human, a machine, a software application, etc, and may be either individual or collective (such as the responsibilities of an organisational unit)
  • When: events and relationships between those events – which may be an event or cycle in time, but might equally be physical (a flood, a system-failure), human (a client initiating a business-process), a trigger from a business-rule (a sensor value, a boundary-condition), and so on
  • Why: decisions and the tests which trigger or validate the condition for the decision – as in strategy, policy, business-requirements, business-rules and so on.

You’ll note that this suggests that ‘Who’ is a near-complete misnomer: what we need in its place is something closer to ‘By Whom’. (‘Who’ is actually a variant or ‘segment’ of ‘What’, or ‘How’, ‘Who’, ‘When and so on, as I’ll aim to explain in future posts.)

The end-result of this rework is that down at the row-5/Implement level, it should be possible to describe everything in terms of a single sentence-structure for work-instructions that maps exactly to the revised columns, and as a composite across every column:

“with <asset> do <activity> at <location> by <actor> on <event> because <decision>

At the row-6/Operations level, the sentence might come out in a slightly different order, and usually in the past tense, but it should still be essentially the same:

<activity> was done with <asset> by <actor> at <location> on <event> because <decision>

And although it’s a composite, we can still identify the individual component-primitives that make up that composite. Which makes architectural redesign possible, and which anchors the trails of relationships between items and between layers that we need in order to resolve business-concerns such as strategic analysis, failure-impact analysis and resolution of complex ‘pain-points’.

The other point is that in effect there’s an entire dimension missing from the framework, to split each column into distinct and necessary segments. As in the examples above, we need to be able to distinguish between physical items, virtual items, people-as-items; functions done by machines, functions done by software, functions done by people, and so on. We’ll look at that in depth as we look at each of the columns in turn in the following posts.

More later: and a reminder that this is very much a work-in-progress, so once again, comments/suggestions would be gratefully received!

1 Comment on “Rethinking Zachman – the columns

  1. I am very very new to enterprise architecture even after practicing it for the past 5 years. First of all let me express my sincere thanks to you for publishing a lot of EA related articles and books.

    I am starting to read your blog from the start. The virtue solely lies in giving them entirely for free and i wholeheartedly appreciate that.

    I believe people like you should start giving online courses to make the practice of EA more realistic and beneficial; in case if you have not seen this this site gives an opportunity for hosting online classes, (Please don’t get me wrong, i don’t have any affiliations with coursera).


Leave a Reply

Your email address will not be published. Required fields are marked *