Back in England after my ‘EA Masterclass’ series in Australia, seems it might be useful to reflect a bit on where this ‘whole-of-enterprise’ approach to enterprise-architecture is going.
So let’s reiterate a bit, because yes, it’s different from what we might call ‘mainstream’ enterprise-architecture such as TOGAF and the like. Quite a lot different, actually.
First point is the scope. At present, most mainstream EA focusses on what we might describe as the realm of projects – the means via which the organisation coordinates change. We could summarise this visually in terms of a Zachman-like layering as follows:
For this, the work of EA is typically about providing coordination, governance and guidance between projects, and developing some kind of roadmaps and reference-frameworks to assist in those tasks.
In ‘classic’ EA, the focus was and often still is almost exclusively on IT infrastructure, data and applications – though that’s broadening somewhat these days, on one side with themes such as BYOD, social, mobile and ‘Internet of Things’, and on another with a stronger emphasis on business-models, business-architectures and the like. We’d also see more emphasis now on cross-cutting concerns such as security and so on. And there are predefined frameworks for each of these, such as described in a by-the-book TOGAF training. (Which, I ought to emphasise, is valid in its own way.)
In this approach to EA, though – ‘whole-enterprise’ EA – we expand out the potential scope into any direction that the organisation might need. The scope might include anything from all the way up to really-big-picture, to occasional drill-down right into fine-detail, and not just IT but anywhere in the enterprise-space, in some cases (such as some aspects of disaster-recovery) maybe not even touching computer-based IT at all:
We need to do this because, in an architecture, everything depends on everything else. Architects often come up with the reply “It depends…“: well, at some point we do need to be able to explore exactly what that “It depends” depends on – and that’s what determines the real scope we need to work with.
In whole-enterprise EA we can do this because we work not so much with the usual prepackaged EA-frameworks, but mostly with metaframeworks – a special class of frameworks that shows us how to create on-the-fly whatever context-specific frameworks we’d need. In most cases, these are recursive or fractal: the same pattern works in much the same way in any context and at every level. In essence, by learning one pattern, we also learn its use and applicability for almost anywhere – hugely simplifying work across large complex contexts. As one workshop participant put it, in an email the day after the course, “I see patterns… they’re everywhere!”:-)
Probably the key metaframework-pattern in the course – and the one that underpinned the structure of the course itself – was the Five Elements pattern, as shown here in its ‘strategy / tactics / operations’ variant:
And that was just one of the patterns that we explored how to use within whole-of-enterprise EA: overall, there were more than 20 metaframework-patterns covered in the course. Which, to be honest, was probably quite a lot too much: in most of the courses it took a whole day to cover the full set of course-materials, rather than the half-day I’d expected. That did cut into the time we’d allowed for the real ‘masterclass’ part – participants putting it all to use within their own business-contexts – but even so, we did have time enough to cover a pretty full range of industries and business-types, including investment, superannuation, utilities, research, recruitment, industrial-engineering, defence, police, healthcare, HR, consultancy, online-community and the software-apps business.
One of the key differences to mainstream EA – as illustrated by the strategy-oriented section of the Five Elements cycle above – was the emphasis on big-picture purpose, and on the people-oriented aspects of EA. These barely rate even a mention in most current ‘EA’-frameworks – perhaps because of the implicit IT-centrism so endemic amongst those frameworks – but, as participants in the course quickly agreed, they’re absolutely essential concerns for any real EA.
The one metaframework-set that did cause some difficulty was Enterprise Canvas. The problem is that there’s an awful lot in it, all of which I somewhat foolishly tried to cover in something like half a dozen slides – which just didn’t work, of course. In later iterations of the Masterclass series, I did take it a lot more slowly, explaining each part of the framework, how they all mesh together, and how they all work for different levels of detail or abstraction – but it was still too complex and too much ‘detail-level stuff’ for many of the participants.
The two parts of Enterprise Canvas that caused the most difficulty are, first, the ‘guidance’-service interdependencies – Validation, Direction and Coordination:
And, perhaps even more, the Service Content checklist – kind of like an expanded version of a single Zachman row:
It seems clear now that I’ll need to do a new blog-post series, re-explaining Enterprise Canvas, how it works, how it’s used in service-oriented mapping and all that. Once we get our head around it, it’s actually very simple, and very powerful – but the blunt fact is that it does take a fair bit to get the head around just how simple and powerful it really is, and I’ll admit that I’ll need to explain that better than I have done so far.
One other metaframework that also needs further explanation is SCORE – my sort-of extended version of SWOT, reworked for the more strategy-oriented needs of enterprise-architecture and the like:
In principle it wasn’t in the course-content, but turned out to be extremely valuable in the couple of times it came up in the conversation. Hence, again, something I may need to expand on somewhat more, perhaps – and maybe explicitly include in a future revision of the Masterclass materials.
More later – particularly that blog-series on Enterprise Canvas – but enough for now: hope you find this review useful, anyway.