Rethinking Zachman – the 'Why' column

Finally, the last of the amended Zachman columns – the ‘Why‘ column.

Zachman describes this column as ‘motivation’, and defines the primitive as ‘ends / means’. That definition would give us problems straight away, because it’s another pseudo-primitive: not ‘Why’ on its own, but a composite of Why (‘ends’) and How (‘means’). A more appropriate primitive here is decision, linked together in webs and trails of derivations that ultimately anchor back to ‘the decision’, the enterprise Vision. Decisions underpin motivation, so Zachman’s overall description for the column would still be valid.

Another reason for changing the definition of the primitive here is that we need a broader scope than ‘business rules’ – Zachman’s only example at the mid to lower levels. Business rules, requirements, policies, analyses, all the other decisions that underpin strategy and tactics – these are the reasons we do anything in the enterprise, and are what we need to document in the Why column.

As with the Who column, there are several ways we could cut the segments, but perhaps the most useful is the Cynefin set, indicating the degree of flexibility in the decision:

  • rule-based (Cynefin ‘known’ domain; aligns somewhat with physical segments): ‘law’, mandatory, no flexibility – must always link to source(s) that justify the rigidity of the decision, such as analytics, external legislation, etc
  • analytic (Cynefin ‘knowable’ domain; aligns somewhat with virtual segments): ‘best-practice’ decision depends on multiple factors and/or transforms – should be linked to the factors (What), transforms (How) etc on which it is based, and to sources for standards
  • heuristic (Cynefin ‘complex’ domain; aligns somewhat with relational segments): contextual guidelines – should link to other decisions or items identifying the context, and to roles or persons responsible for maintenance of the guidelines
  • principle-based (Cynefin ‘chaotic’ domain; aligns somewhat with aspirational and/or abstract segments): decision derived from high level of skill – must link to guiding principles and to person or group (e.g. committee) responsible for the decision

This also matches the layering of source-documents in ISO-9000:2000: rule-based work-instructions derive from analytic or best-practice procedures derived from heuristic policies or guidelines, derived in turn from the principles indicated by the vision.

Typical model-types include requirements methodologies such as Volere, and strategy/tactics models such as the Business Motivation Model – though note that the latter’s concept of ‘vision’ is simply a view of a ‘desirable future state’ for short-term strategy, rather than the invariant Vision required in row-zero to guide and anchor principle-based decisions.

Types of relationships between decisions include ‘expands on’ (especially when descending down the Zachman rows) and ‘conflicts with’. The other columns will usually include extensive cross-links to the Why column, with relationships such as ‘implements’ (for example, How or What implements decision). Every requirement also needs links to one or more items – usually What or How – that provide a test to confirm when the requirement has been met.

In principle, every relationship between any items in the entire framework is a decision, and thus technically should belong in the Why column. In effect, a relationship is a special type of decision that links two other items together. The same Cynefin types would apply to these as to other decisions: some relationships, such as foreign-key links in a database schema, are rule-based; others, such as assignments of people (What»virtual) to roles (Who»virtual) to business functions (How) are more likely to be based on best-practice or guidelines; and so on. For clarity, and for sanity’s sake, we display these decisions as connecting lines rather than as Zachman entities: but at times we need to remember that that is what they are.

To summarise: the primitives for the amended Why column are decisions, with specific relationships such as ‘expands on’ and ‘conflicts with’ to link them together into a single tree ultimately anchored in the enterprise Vision.

Leave a Reply

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

*