It's a well worn and cynical observation – that I use often – but it's worth repeating. A “process” is something you'd like other people to follow in situations where you yourself would just use your own judgment. A “framework” is what you think other people need to understand in order for you to do your job correctly.

The way we manage our organisations is filled with these sorts of half solutions. In particular, it's filled with ways of managing complexity that put obligations on others. Putting it another way, the application of the method differs depending on what side you're on – us or them. “They should follow a better process”. “They don't understand our framework”.

Enterprise Architecture is a good example of this. It's locked in a battle with the upper echelons of the corporate world. The premise of enterprise architecture is that you can make systematic decisions about strategy and resource allocation based on building an integrated model of the business, information, applications, and infrastructure (or any number of different layerings and groupings).

Enterprise Architecture (EA) competes with general management and governance principles which align decision making rights with responsibility – regardless of the availability of enterprise architecture models or frameworks. In this context EA could be accused of wanting to eat the cake (of strategic thinking) but not wanting to accept responsibility for the consequences (the fat of being the decision maker).

The problem of creating a systematic approach to strategic resource allocation is a real and important. It deserves to be solved for your organisation. However, it's not a modeling problem, it's a collaboration problem.

I like to talk in terms of “Collaboration Architectures” – this is a sort of “applied architecture” discipline which simply defines the architecture as a “delimited shared understanding”. It's descriptive of the shared understanding of the components, layers, and relationships that the group collaborating all agree on. Most importantly, that delineated shared understand only changes organically with the understanding of the group. You find the collaboration architecture before you change it.

These collaboration architectures are the bridge between soft skills, general management principles and governance, and the desire for systematic approaches to management. It's only in relation to this type of architecture that decisions can be make (including allocation of tasks, resources, performance management, etc).

Collaboration architectures can be mentored by a third party – just like individual meetings can be facilitated or chaired – so there is no conflict of interest between who owns decision rights and who is mentoring the collaboration architecture.

If Enterprise Architecture is to be saved from obscurity – or at least from being constantly misunderstood as it fails to define itself consistently – it needs to focus on the how it facilitates collaboration. It also needs to be clear on what decisions its collaboration architecture supports.

A collaboration architecture for executives coming together to make resource allocation and strategy decisions is powerful. When enterprise architecture plays this role it to is a powerful strategic tool. But it needs to loose a lot of baggage lest it be replaced by other collaboration architectures more suitable to the task.

But that's for another day…