Responses to 'Rethinking Zachman'

Had a few responses already to this ‘Rethinking Zachman’ set of posts, some of them as comments, others direct by email. Although the emails are obviously personal, and need to remain anonymous unless otherwise indicated, the content of one of them really deserves to be here:

I think you are on to something when you compare composites with primitives

I wonder if this has something to do with the IT-centric mindset: analysis (the breaking of things down into their component parts) which is necessary to troubleshoot and repair, and to a large extent to architect and design, but only in part.

The flip side of analysis is synthesis, the bringing together. It is in synthesis that the business value comes. Why? Because the focus is on business outcomes. This is where your idea of composites comes in… of course! A business outcome relies on the bringing together into an integrated whole all the primitives and services the technical architect has to offer in order to deliver a business outcome. It is the integrated whole that makes the difference and something Enterprise Architecture should focus.

We can borrow from portfolio management principles from our finance brothers here. They found that securities perform much differently when working in a portfolio than when their performance was viewed separately. Optimization had to be done at the portfolio or “system” level, not at the individual security level. Even Family Systems Theory and Therapy works this way. Medicine works that way. The problems in a family or in a body are best solved when working at the overall system level not at the individual components or people level. I have many interesting examples of this from my coaching business when you have some time.

It is also interesting to note that there is very little to no value in individual components or pieces alone. It is only when they are brought together and work together to deliver something that we actually get value. Take a movie for instance. We have characters, plots, settings, etc. but we don’t have a movie until they are brought together in a compelling and interesting way.

Again I think this is due to the IT mindset. IT folks have mastered analysis. It is now time for them to become masters in the opposite direction and become equally masterful in synthesis in a business context.

Good points – triggering off a stream of ideas, which I sent in a return email and which I’ll also include here:

Exactly – the value comes from synthesis. As you say, it’s also what business understands – in other words, primitives bundled together into meaning-laden composites. The historical problem has been that the business can only see the composites – and hence can’t change anything with any ease, because everything is rigidly locked together into those composites – whilst IT (and the ‘engineering’ mindset in general) habitually breaks things down into disconnected primitives – and hence can’t see the meaning that’s carried (portfolio-style) in and through and between the composites.

(Also agree with the cross-link with Family Therapy and the like – for example, see my SEMPER whole-of-organisation diagnostic at http://www.tetradian.com/semper . Would love to discuss this further with you somewhen!)

Zachman’s original taxonomy was just-about usable for IT, but falls over in a heap as soon as we extend beyond that narrow scope. Yet the taxonomy of the primitives is the foundation for the entire architecture: hence my perhaps-obsessive concern to get it ‘right’! If we don’t have the right primitives – the right taxonomy – then we won’t be able to manage change; and if we don’t understand how primitives work together as composites, we won’t be able to understand how things actually happen and how we can change.

The trick is to get to the ‘natural composites’, whilst still remembering that they are composites, and juggle them into new configurations. This is the declared aim of service-oriented architecture, of course (though they’re still going about it in a strictly IT-centric way…), but perhaps a better analogy is the relationship of RNA to the G/A/C/T components of DNA, which can be reconfigured in pretty much any order to create radically different kinds of ‘meaning’.

The other business focus here is that primitives – not composites – provide the anchors for compliance and constraints. To take an IT example, if we specify SQL Server as the required/preferred database platform – i.e. a constraint – it’s still a good idea to use as much platform-independent code as we can in our database applications, and islate out and document any SQL Server-specific optimisations, otherwise we create future risks for legacy code when we do have to change the platform. (We could quibble about some of the fine detail, but in effect SQL Server is close to a primitive as a row-4/row-5 virtual-Who, for the applications as a virtual-How.) Business doesn’t want to know anything about the detail at this level – it’s an architect’s job to hide the complexity – but they do want the end-result, which is business change managed smoothly and effectively.

Next step is to rethink how relationships work between primitives; and then start looking at the ways we bind primitives into composites at the abstract levels. My suspicion is that the existing toolsets do their models the wrong way round: they start with primitives and define all possible relationships from there to other primitives, whereas I’m sensing that what we should be doing is saying that the relationship belongs to the model-type, with the links to the respective primitive as attributes of the relationship. Once that relationship is created, we should be able to follow the trails accordingly from the respective primitive; but the link is inherent to the relationship, and thence to the model – not to the primitive. May sound an academic point at first, but it would make a big difference in how we build the architecture incrementally, by an accretion of models (composites, syntheses) surfacing their primitives rather than a ‘big-bang’ attempt – Zachman-style – to identify every primitive in the entire organisation before we start doing any architecture.

I’ll experiment with this and put the results up in the blog, anyways.

One further comment from my correspondent:

One thing that comes to mind is some work IBM did several years ago – can’t quite recall what they called it but it dealt with eBusiness patterns. l liked the way they put the primitives together to provide business composites or patterns as they called then. Anyway, just thought I would pass this on in case you hadn’t seen it. I think it begins to get at some of your points.

The ‘eBusiness patterns’ are a good example of a design-level composite, illustrating well a principle that I tend to summarise as “compliance comes from architectural completeness; re-use comes from architectural incompleteness” – in other words we can re-use a composite to the extent that primitives for one or more Zachman columns are not present in the composite’s pattern. Again, more on that in another post.