Link: http://weblog.tomgraves.org/index.php/2011/07/25/rethinking-layers-in-ea/
Still plodding away on ideas for a systematic process to translate a business-model in Business Model Canvas down into real-world architecture and implementation. (This links up with quite a few previous posts, such as ‘More on business-models‘, ‘Enterprise-architecture – let’s keep it simple‘ and ‘Is Archimate too IT-centric for enterprise-architecture?‘)
[Note: this is a work-in-progress post, not a finished piece – I really do need discussion on this one!]What’s come up this time is the usual struggle with the so-called ‘architectural layers’ in common EA frameworks such as TOGAF and Archimate:
- Business
- Applications (in Archimate) or Information Systems (in TOGAF)
- Infrastructure
The problem is that, for me, these are ridiculously incomplete, and lead directly to IT-centrism – where IT is deemed to be the sole centre and basis for everything. That IT-centrism what creates most of the much-lamented ‘business/IT-divide’.
The corollary is that, because IT is placed as the centre for everything, and applications only run on IT, everything else has to be lumped into ‘business-architecture’, because it’s the only place it can go. Hence in TOGAF, for example, high-level business-strategy is bundled together with mid-level process and detail-level manual work-instruction, without any kind of distinctions between them, solely because it’s ‘not-IT’. And technology and infrastructure that isn’t computer-based – lorries, fork-lift trucks, assembly-lines, plumbing and wiring and even the buildings within which everything operates – don’t even get a mention anywhere.
This brings serious problems even in IT-specific architectures: for example, how can we usefully describe the overall architecture of a data-centre without mentioning power-supply or cooling or access-pathways? What’s the point of arguing about instant-on virtualization for data-servers if it takes a minimum of six months to construct the building that houses them? How do we describe disaster-recovery processes for when the IT is out of action, when the only metamodels available to us can only describe IT? To anyone doing real enterprise-scope architecture in the real-world, the myopic inanity of IT-centrism gets really frustrating after a while…
Hence why I’ve been ranting and raging so much about the limitations of TOGAF and the like over the past few years. It’s not because I’m ‘anti-IT’ – as some people have dismissed me – but because I’m trying to get things to work in the real world. A messy, chaotic, uncertain world in which IT is often unreliable at best, irrelevant at worst, and which, for the most part, is not centred on IT. Sigh…
So, in short, the conventional concepts of so-called ‘business-architecture’ are an unusable mess, and the ‘application’ and ‘infrastructure’ so-called ‘layers’ are too narrow in scope to make practical sense for anything other than the most IT-centric of IT-architectures. Hence, also in short, not so much useless as probably worse-than-useless for most real-world purposes.
Which means that we need to start again. Properly.
But from where? Using what as the layers?
(Or do we even need layers at all? Is even the idea of ‘layers’ misleading?)
There’s the Zachman layers, of course: Contextual, Conceptual, Physical, Logical, Implementation, Operations. That does make practical sense as a description of the process of change, but perhaps not so much about the architecture itself – the interrelated, interconnected structure of that which is in use.
What about structural-decomposition – from abstract to detail? Well, yes, that’s useful, certainly, but it doesn’t really tell us much more than Zachman does, and doesn’t help us to differentiate between different kinds of ‘thing’ – the distinctions that come up, if somewhat erratically, in Zachman’s columns of What, How, Where, Who, When and Why.
The ‘Why’, though, does lead to another suggestion: Simon Sinek’s principle of ‘start with Why’, and its layering of Why, How and What.
Because if we start with Why, and tweak the ‘What’ slightly to ‘With What’, we end up with an almost exact match to the Archimate / TOGAF layering – but this time a layering that is not IT-centric. And which also lines up with key parts of the Business Model Canvas:
- Why? – about the choices and Value Propositions that drive ‘the business of the business’
- How? – about IT-applications, ‘manual’-processes and any other Key Activities that enact those choices and needs
- With What? – about any machines, equipment, buildings and other infrastructures and Key Resources upon which or through which those activities take place
At first glance this has some parallels to the long-established CapGemini ‘Integrated Architecture Framework‘ [IAF]:
(I have a vague recollection that there’s at least one more EA framework that uses a similar Why / How / With-What structure, but right now I can’t remember whose it is… 
– my apologies to that person, anyway.)
But if we look more closely at those layers in IAF, it’s clear that they’re just a re-labelling of Zachman layers, with the old TOGAF-style layers sideways-on, and deeper ‘cross-cutting themes’ such as security and governance further behind. (And actually that’s quite a good way to put it – which we’ll come back to in a moment.)
The point here is that if we use that Sinek-style categorisation of Why, How and With-What, we can cover just about anything that’s needed in the architecture: it doesn’t assume that the end-point is only about IT. And it still lines up well to Archimate: hence business-information (linked to Why) is represented in Archimate as a Business Object, its usage in processes (linked to How) is a Data Object, and its physical form (as a With What) is a Representation. Archimate doesn’t as yet have any entity to represent generic ‘physical Thing’ or ‘thing that flows through processes’ – such as we’d need to represent a parcel in a logistics context, for example – but the Why / How / With-What structure makes it easy to understand that Representation, Data Object and Business Object are just IT-oriented specialisations (in the UML sense) of each of the respective generic entities. It works. 
But should we use layers at all – especially scope-defining layers such as ‘business’, ‘application’ and ‘infrastructure’? In a sense, the IAF suggests not – any fixed notion of ‘layers’ is misleading. A better way to describe is to say that the ‘layers’ are merely areas of emphasis of attention: we separate those areas in order to ‘black-box’ the internals of an area of scope so as to focus our attention on the interfaces between those areas of attention. The IAF shows a very good way to visualise this, with sets of viewpoints that are in effect orthogonal to each other. The only problem there with the IAF is that, yet again, it constrains the overall scope to IT alone – which renders it too limited for whole-enterprise architecture. If we imagine that, rather than that catch-all column labelled ‘Business’, we could have as many columns as we need – and as many ‘backplanes’ that we might need, equivalent to the existing ‘Security’ and ‘Governance’ but covering all values in context for the enterprise – then something like IAF would make good sense.
I would suggest, though, that that simple categorisation would be a good place to start:
- Why – ‘business’
- How – ‘applications’
- With What – ‘infrastructure’
Use each of these not-quite-layers as a viewpoint for focus into the overall enterprise context, and use an adapted version of Archimate or an equivalent to model both within those ‘areas of interest’ and to explore the connections between them.
Okay, that’s it for now: over to you, if you would?
