Rethinking Zachman – the 'What' column

Expanding on the previous post on the overall set of Zachman columns, let’s rethink the detail of each framework column, starting with ‘What‘.

Zachman describes the ‘What’ column as data, or more generally as ‘entity / relationship‘.

To make this generic enough for enterprise-architecture, re-view this column as ‘asset‘. Data is just one class of asset – specifically, a virtual asset. Architecturally, we need to manage all of the assets – not just the data – in a similar way.

So this column describes the organisation’s assets – its countable and measurable ‘things’ – and the relationships between assets of the same type (as primitives) and different types (as composites). Beyond this expansion to a broader range of assets, and a categorisation into segments of fundamentally different types of assets, the column remains essentially the same as in Zachman.

Segments of the column include:

• physical assets: servers, routers, widgets, paper forms, physical objects of all kinds
  • model types: parts-breakdown, bill of materials, etc
• virtual assets: data, metadata, messages, models
  • model types: data-model, metadata-schema, model-definitions etc
• relational assets: links to people – customers, clients, employees and other stakeholders
  • model types: business-relationships and relationship-types
• aspirational assets: morale, values, commitment, drive
  • model types: architecture ‘Universals’ (row-zero), customer / employee survey-designs etc
• abstract assets: financials, valuations (‘goodwill’) etc
  • model types: financial models, derivatives, valuation schemas etc

The distinctions between the segments are derived from standard classification-schemes for property types. For example, physical property is ‘alienable’ – if I give a physical object to you, I no longer have it – whereas virtual property is ‘non-alienable’ – if I give an idea to you, I still have it. And whilst abstract-assets are perhaps the hardest category to understand, they’re also the assets about which business is usually most concerned – especially financials.

(As an aside, many of our economic problems arise from attempts to treat all property as if it’s physical, ‘alienable’ and controllable – the black farce that is ‘intellectual property’ law being an extreme case in point. Another disaster-area is that otherwise excellent phrase “our people are our greatest asset!” – because people are not assets: it is the relationship with each person that is the asset, and needs to be managed as such. Relational assets, incidentally, are the nearest that we get to a true ‘Who’ in this revised framework – in other words, ‘Who’ is actually a special class of ‘What’.)

Within the ‘What’ column, relationships may exist between primitives of the same segment, or in different segments. Only in the same-segment case – for example, the relationships between entities in a data-model – do we have the true primitive-models implied in Zachman’s ‘entity / relationship’ description; all the others are actually composites, and need to be modelled as such. To say that this can get complicated is an understatement – but we need to be clear about these distinctions if we’re to get the architecture to work properly.

An everyday example: a form that needs a signature. Sounds really straightforward, doesn’t it? But it’s actually much more complicated than it looks. The form is a physical object: so we need to manage it as a physical object, with all of the concomitant complexities of procurement, inventory, pre-use warehousing, modification and use, storage and disposal. But it also contains data: so we also need to manage it as a virtual asset, with all the concerns about data-quality, information-quality and so on. Then for something as simple as a signature, we need to identify the relevant role and responsibility (‘Who’), link from there back to the specific person allocated that role (the ‘relational asset’) to action the respective action (‘How’). And we might well need to record on the form the time (‘When’), place (‘Where’) and reason (‘Why’) for the signature. So even a simple form can easily become a decidedly complex composite.

So what? you might say. The answer is that as long as nothing changes, this kind of analysis is indeed irrelevant – an ‘academic exercise’. But the moment you want to change something, it becomes essential to split the composite into its primitives, and assess each in turn so as to improve overall effectiveness.

For example, if you want to remove all the physical messiness of a paper form, and turn it into pure virtual data, you must also re-think the process of sign-off: otherwise what you’ll end up with is the virtual record and another paper form, which you now somehow have to synchronise – not only defeating the object of the exercise, but actually making it worse from a maintenance point of view. (Likewise if you do change to a virtual sign-off, you should also be able to automate links to the ‘When’, the ‘Where’ and the ‘Why’ – they don’t need to be left on the online form to be manually filled-in every damn time, as I saw happening on a system design at my recent client!) Unless we split the composite into its primitives, these issues and options remain invisible – hiding real risks or opportunities for improvement.

To summarise, the ‘What’ column represents the assets of the enterprise – the entities that actions are done with, or to, in the pursuit of the enterprise’s business-purpose.