About 15 years ago I found myself running a project management course for a local authority in Scotland. I was doing my usual pitch at the start of my career history, talking about how I’d been an architect, first solution then enterprise, at the BBC. A chap in the front row’s face looked like thunder.
As I got the group to introduce themselves, he revealed that he was and architect working in the council’s planning team and that he took umbrage at a jumped-up IT person talking about themselves with a term that took him seven years to qualify to use. It’s a moment that has stuck with me.
Enterprise Architecture is a funny beast. It’s been around for two decades or so, and I’ve yet to work in an organisation where it really seems to work. Increasingly I’m coming to the conclusion that the metaphor of “Architecture” is the problem.
Because what most EA functions are there to do isn’t much like what an actual architect does. There are a number of potential roles, and maybe if we extend out the metaphor it helps to explain them.
First of all, there’s a role as a civic planner. In the same way that local authorities put plans in place for different types of use and development in different parts of a city, an enterprise architecture team should be determining some high-level principles for how technology is used in an organisation. Where, for example, should ERP or CRM be used? What platforms for development might be appropriate? How do those things fit with the activities of the organisation? This planning process needs to be collaborative and consultative, and probably not very detailed.
Secondly there are a couple of governance roles: the first is as a planning authority. When someone wants to build something, does the exterior of that thing (read- interfaces and so on) meet the requirements of the other things around it, and does it sit in the right place in accordance with the civic plan?
The other is as a building control. Is the way in which the interior of the thing being built being done safely and in accordance with standards for building (code, data and so on).
Finally, there is a role as cartographer. What is the map of where were are today, and where we are going? The former can be in detail, the latter in broader strokes.
Metaphors are really useful when they work. When they’re duff, then they can cause all sorts of problems. I wonder if it’s time to ditch Enterprise Architecture as a term altogether?
mmitII 