Rethinking Zachman – the rows

Enterprise-architecture again: first part of my promised write-up on where I’ve gotten to with rethinking Zachman.

Zachman’s framework consists of six horizontal rows, representing perspectives; and six vertical columns, key representing categories of entities. Between them they form 36 cells, each of which is supposed to represent a single type of indivisible ‘primitive’ which can be used to describe entities for compliance and re-use purposes in enterprise-architecture.

This post describes a rethink of the rows – the perspectives.

Unlike the columns, there’s not that much to rethink: the perspectives are pretty much as valid in non-IT contexts as in IT-centric ones. The only real change suggested in the integration with TOGAF is to add a new highmost row, with a single cell straddling across all the columns, as a common space for ‘universals’ to which everything in the whole enterprise should comply – vision, values, core principles, core policies and the like. (Strictly speaking it’s a kind of additional dimension, but it’s simplest to add it to Zachman as an extra row.) This represents the core architecture-content discovered during the TOGAF ‘Preliminary Phase’. All the other rows are split into the respective column cells, as in the original Zachman. So we end up with a vertical axis like this:

• Row 0: ‘Universals‘ – core constants to which everything should align – identifies the overall region of interest and the key points of connection shared with enterprise partners and other stakeholders
• Row 1: ‘Scope‘ (Zachman: ‘Planner’) – core entities in each category, described in list form, without relationships between them – the key ‘items of interest’ for the enterprise
• Row 2: ‘Business‘ (Zachman: ‘Owner’) – core entities described in more detail, from a business-metrics perspective, including relationships between entities both of the same type (‘primitives’) and of different types (‘composites’) – summary form, without attributes for entity-types
• Row 3: ‘System‘ (Zachman: ‘Designer’) – entities expanded out into implementation-independent designs – includes descriptive attributes
• Row 4: ‘Develop‘ (Zachman: ‘Builder’) – entities and attributes expanded out into implementation-dependent designs, including additional implementations for relationships – for example, cross-reference tables for ‘many-to-many’ data-relationships
• Row 5: ‘Implement‘ (Zachman: ‘Sub-contractor’ or ‘Out of Scope’) – implementation of designs into actual software, actual business-processes, work-instructions, hardware, networks etc
• Row 6: ‘Operations‘ (Zachman: usually implied but not described) – individual instances of entities, processes, etc as created, modified, acted on etc in real-time operations

The rows also have a steadily narrowing scope of time, from ‘Universals’, which, in principle at least, should never change, to ‘Operations’, which will be changing from moment to moment – in some cases in milliseconds or less.

To see how this works in practice, think of the dreaded ‘org-chart’:

• At row 0/Universals, there is just ‘the organisation’ – the enterprise as a whole.
• At row 1/Scope, we could split this into high-level business-units – the basic partitions of the enterprise, as labels for clusters of overall capabilities (which would be in the row-1 cell for the ‘Who ‘ column) and/or geographic locations (i.e. in the ‘Where’ column)
• At row 2/Business, we would start to differentiate these units, adding labels for the responsible role (the CxO levels) and the relationships between them – and also links to the metrics against which their overall performance would be measured
• At row 3/Systems, we expand out this skeleton into a nested structure of capabilities and reporting-relationships, with at least the upper rows labelled with generic roles and responsibility-types (but not actual names)
• At row 4/Develop, we start to become explicit: the upper rows may well start to gain explicit names as well as roles, and every branch needs defined capabilities and responsibilities – but we may use patterns of relationships to indicate lower-level organisational structures that would be re-used at different sites and/or for different capacity-levels (for example, a structure for specific types of work-teams, but without specifying the numbers of work-teams)
• At row 5/Implement, we require actual names for every slot in every implemented branch of the organisation-structure – yet this still represents only the nominal, intended structure, not necessarily what happens in practice
• At row 6/Operations, we have the real, actual organisation-structure as it changes dynamically day by day, minute by minute, with real-time rosters, with people in ‘acting’-roles to cover those on temporary leave, and the so on

At the uppermost level – the whole-of-enterprise level – we always and only have primitives; at the lower-levels, it becomes harder to see the primitives that underlying the implementation-composites – until at row-6, almost by definition, everything is (or should be!) a composite that straddles all the Zachman columns.

And there’s also a kind of implied boundary between row-3 and row-4 where we shift from abstract design to real-world implementation – a shift that’s also marked in organisation structures by the transition from ‘staff’ to ‘line’ management.

Mapping this to the four dimensions of the tetradian view, the upper levels (rows 0-3) represent the ‘Aspirational’ dimension (‘the business’), whilst the lower levels (particularly rows 4-6, but in some ways even upward as far as row-2) increasingly separate out into the three ‘Practical’, ‘Conceptual’ and ‘Relational’ dimensions (roughly speaking, objects, data and people respectively). More on that dimensional split as we look in more depth at the Zachman columns, starting with the next post.

Comments/suggestions, anyone?