For as long as the discipline of Enterprise Architecture has been around, it’s been a slippery beast. Some organisations have embraced the practice and concepts, and have become ardent evangelists of its power to improve the aggregate return they get from IT investments over the long haul; but many others just prod the idea with a stick as if it’s a hairball that a cat has just thrown up.

It’s a big problem. The large volumes of discussion and debate ongoing on blogs and discussion groups, and at conferences, suggests that a great many organisations are still unclear about how to define it or draw a boundary around it. There are at least two dimensions of uncertainty which I’ll attempt to summarise here (and as you’ll see in a minute, two dimensions of uncertainty is quite enough to be going on with).

The importance of enterprise architecture

The first way in which people seem to struggle to agree regards the “what” of Enterprise Architecture practice – which boils down to what people mean when they say “enterprise”. For some, “enterprise” means “looking at everything in an organisation end-to-end, from strategy to execution, bridging business and IT concerns” (or in other words, pretty much everything is in scope – though perhaps not to a high level of detail). For others, “enterprise” means “looking at IT concerns end-to-end” (and therefore excluding relationships to business concerns).

The second way in which people seem to struggle to agree regards the “how” of Enterprise Architecture practice – which boils down to what people mean when they say “architecture”. Specifically, it’s about what people believe is the most important part of the practice. For some, it’s all about the tangible deliverables – the set of models that get created. For others, it’s not about the end result in isolation, but it’s at least as much about the way that those models are created in the first place. One group tends to lean towards private acts of creation and refinement: this is Enterprise Architecture as an exclusive, elevated practice, carried out by specialised practitioners, mostly in private. The other group tends to lean towards collaborative, open acts of creation and refinement: this is Enterprise Architecture as a conversation.

For many of the 15 years that I’ve been an IT industry analyst and consultant, I’ve been talking to Enterprise Architects and trying to find out what seems to work and what doesn’t work. I’ve come to the conclusion that there’s one stand-out type of approach that seems to have the best outcomes: the one that’s based on the “business and IT, strategy-to-execution” interpretation of “enterprise”, and that’s also based on the “open and collaborative” interpretation of “architecture”.

Why? Not least because – unlike when Enterprise Architecture as a concept and as a discipline first became widely considered – the biggest risks in successful business exploitation of IT aren’t, by-and-large, risks associated with the creation of large, monolithic, isolated systems. They’re risks associated with successful business understanding and use of a whole constellation of inter-related systems – most of which probably won’t be built by your people, and some of which might be ‘rented’ without you knowing (until after the fact).

Just focusing on the technology pieces of the puzzle sets you up to be blind-sided by some of the most important risks of all – risks to do with successful deployment, acceptance and adoption. And just focusing on the outputs of architecture work (the models), rather than focusing on understanding and actively engaging with the needs, concerns, priorities and fears of the people who are the real influencers of success in order to create the models, exposes you to the very same risks, but from a different angle.

The most successful IT architects in the long term are influencers, cajolers, nudgers, tweakers. They’re not the people driving macho balls-out megabucks IT transformation programmes that likely end up being associated with words like “baby” and “bathwater”. They’re people who can work co-operatively to discover and elaborate a shared vision for how IT can contribute business value over time, and then work co-operatively to make continual course corrections – taking into account changing business priorities as well as changing technology capabilities, models and skills availability. They’re what practicing enterprise architects like Todd Biske and Leo de Sousa call “activists, not archivists”.

Next generation IT requires next generation EA

The problem we collectively face, unfortunately, is that the majority of the current literature, guidance and training related to Enterprise Architecture is not focused on this kind of broad-based, open, collaborative, activist approach to the practice. The organisations forging ahead are doing so largely under their own steam.

What’s your view? I’d love to hear your thoughts.