In terms of ‘means and ends’, what’s the end of enterprise-architecture – its real, practical purpose?
[Don’t worry! – this isn’t yet another round in those interminable arguments about ‘What is enterprise-architecture?’… What follows would apply just as much to IT-architecture, or business-architecture, or just about any other form of architecture, as it does to EA at a whole-of-enterprise scope.]
What got me going on this was a conversation with a colleague, who was pondering whether his new organisation needed an enterprise-architect – a full-time or part-time enterprise-architecture role. That they were going to need some form of enterprise-architecture was not in doubt; but the need for an explicit person to do that work was a bit less certain.
The more we looked at it, the more blurry it became. And then a kind of breakthrough: enterprise-architecture is a discipline, not a role.
To me, enterprise-architecture is a discipline – or set of disciplines, if you prefer – that revolves around a single core theme: that things work better when they work together, on purpose. (Okay, there are lots of nuances and ifs and buts and perhapses all mixed up in there, but that summary of the ‘core theme’ is close enough for now, yes?)
And the key point here is that this will only work well when it’s taken up as everyone‘s responsibility – not solely the responsibility of the person who has some variant of ‘Enterprise Architect’ in their job-title.
As with other ‘pervasive’ themes such as quality, security, health-and-safety, knowledge-sharing, environment and suchlike, it’s more of a discipline than a ‘job’. It’s sort-of a specialism, yes, but a specialism that in real-world practice looks significantly different from the mainstream specialist roles seen in job-adverts and the like. For example, it’s usually a generalist discipline – ‘go anywhere, work as directed’, rather than ‘work on these materials for these defined outcomes’. And there are few clear ‘deliverables’ for these ‘pervasive-themes’: the best we can do, or expect to do, is to make things somehow better in the terms of that specific discipline, with metrics that are often blurry at best.
The danger here is that if it does become someone’s role, someone’s job, there can be some unfortunate unintended-consequences. Of these, the most common traps are:
- the enterprise-architects interpret everything solely in terms of enterprise-architecture itself – and try to force everyone else to do likewise
- enterprise-architecture becomes regarded as solely the responsibility of the enterprise-architects – not as the necessary responsibility of everyone
When we put the two together, the risk here is that enterprise-architecture becomes both hated and ignored – in other words, exactly the outcome we don’t want…
[The equivalent applies to every other pervasive-theme, of course. I remember being on one of those team-building courses where the task was to get everyone over a high wall, against the clock, to protect them from some metaphoric explosion or flood at the end of that time. The person assigned the role of ‘safety-officer’ became so obsessive about safety – criticising everyone, stopping every action as ‘unsafe’ in some kind of absolute terms – that no-one got over the wall before we ran out of time: everyone ‘died’. And that does happen all too often in real-life, too: there were several tragic examples of this at Japanese primary-schools during the 2011 tsunami.]
What we really need – again, as with every other pervasive-theme – is for enterprise-architecture to become understood, accepted and enacted by everyone as their personal responsibility. In practice, what we need to make it happen are four distinct sets of activities:
- develop awareness of the pervasive-theme – in this case, enterprise-architecture – to explain why it’s important to everyone
- develop capability to enact the theme – otherwise it ain’t gonna happen, no matter how great the awareness may be
- apply capability for the theme in every aspect of real-world practice – because that’s where it actually happens, and needs to happen
- verify and audit what was done to enact the theme – so as to support continual-improvement on that theme
So yes, it’s probable that, right at the start, we’d need someone in the role of ‘safety-officer’ or ‘security-officer’ or whatever, to help everyone with all of this, and in chivvying them and reminding them why it’s important and why and how to do it. Hence, in this case, the role of ‘enterprise-architect’. And the need for that role is likely to continue on for quite a while, perhaps indefinitely.
Yet in doing so, we should never lose track of the real aim here – that the disciplines to support the outcomes of the respective pervasive-theme become understood as and are enacted in practice as everyone‘s responsibility.
In other words, the end of enterprise-architecture is that there is no ‘Enterprise Architect’ – instead, everyone is an enterprise-architect, in their own way, with and on behalf of everyone else.