Enterprise Architecture – the big catch up

Here is the problem with EA – it is never complete at the point instant when a project asks some question of it. I think that is true no matter how many architects you have or how good they are.

This is the third time I’ve been responsible for “Architecture”, and – no disrespect intended to architects, who aren’t the problem – it never seems to be in complete enough a state that it can answer the specific question a project needs answering at a specific time.

In an organisation that respects its architects – and I think that DWP is one – that means the projects ring up the architects to get advice. Which is all very well, of course, but since the architects are spending all their time trying to build their architecture out to the point  where projects need it to be going, they don’t have time to write all their advice down and add it to the architecture.

Of course, you could have an architecture team that builds things at such a high level that you get completeness simply because you’ve abstracted away all the detail altogether.

But I think that kind of defeats the purpose of having decent architects. You’re then into the realms of strategy, and lets face it, architects are supposed to be working out how to get to the endpoint that the strategy defines, not defining the end point itself.

Now I know that this set of statements will be like waving a red flag at a bull for some people. I don’t mean to cause offence, really I don’t.

But I have come to the conclusion that demand for architecture – at whatever level of detail – will always outstrip the supply of architects available. No matter how much money you spend.

Now, this presents a quandary, I think. On the one hand, if projects can’t get what they need from the architecture, I wonder what the point of having an architecture is at all. But on the other hand, the chaos that results from not having one at all seems pretty likely to have awful repercussions. I’m not certain anyone wants to go back to the days where people did exactly what they pleased, and dang the consequences.

Anyway, it would be impossible now that we have to do “service orientation” and “reuse” and “integration”.

But I can’t help but wonder if the real answer is to decentralise architecture in some way  - make it a more collaborative and participatory activity, one in which projects do a degree of self serving. Where, maybe, the architects are curators of the content, rather than the creators themselves.

I’m going to be talking to my teams about an interesting experiment I have in my mind along these lines over the next week or so. If we go ahead and try something new, I’ll write about it here.

In the meantime, does anyone else have experiences that are relevant? How did you get your architecture ahead of project’s demands for it?

Comments

[Stephen]

Neil, just as an addendum…..

I do find sum of the costs associated with UK Government IT quite mind-boggling, compared to what I have seen in other countries, especially small ones, e.g. those who are really on the money.

I do question the development life-cycle, especially for new systems, in many ways, my ideal would be to develop a system with a few very good people, small with a very scalable architecture, do more proof-of-concepts etc. before engaging the army of people needed to make these things operational.

Government projects tend to get far too big, too quickly, and acquire a momentum of their own, sucking in the dollars before anyone knows what is actually going to be delivered.

So, yes, from that perspective there is a problem in terms of value for money, front-end process, governance, life-cycle and assurance and this needs to be further
explored..

Jon mentioned the 'Less is more' thing, and that is certainly true.

If the business could consolidate and align its projects better (e.g. less projects) through some form of portfolio managment - that could help as well.

Good that you raised and challenged the point.

[Kevin Lee Smith]

@James: “it never seems to be in complete enough a state that it can answer the specific question a project needs answering at a specific time”

Good question James,

The answer is very very simple.

EA is method, a tool and like any tool if it is used incorrectly that the "tool" will fail.

One of the key things people miss when EA modelling (which is only one aspect of EA) is that they need to follow a reasonable process for populating it and using it. The reason for your "architecture" never being complete is 2 fold.

#1 Do not think that a bunch of "Architects" in a room are responsible for maintaining the information in the model. The information in an EA model consists of many different types of information - department hierarchies, processes, financials, applications, etc, etc. The information should be owned and maintained by those people who are responsible for it. HR, Finance, Programme Office, Support, Development, Facilities, etc, etc…

Failure to do this will create a massive bottleneck.

#2 Do not populate a model without integrating or removing the data sources where the information came from.

Failure to do this will result in the information getting out of date meaning when someone wants to use some information they will have to “update” it first and therefore the model never seems correct or up to date because it isn’t.