[bliki]Enterprise Architecture[/bliki] is one of those Humpty-Dumpty-like words that conveniently mean whatever you want them to mean.
I’ve also found that a lot of people have a violent antipathy to the term, as for them it summons up the spectre of IT geeks piling layers of jargon and obfuscation on top of their common-sense understandings of how a set of systems fit together with the business they serve. Add in a healthy dose of scepticism about the use of any jargon by someone who is trying to spend your money, and you wonder why any of us continue to use the term at all.
What I’ve found useful is to confine use of the words “Enterprise” and “Architecture” (together or apart) to those occasions when I’m talking to people from the IT world – for dealing with colleagues I resort to pictures. Although it’s incredibly tedious to manage big, comprehensive, models without specialist tools, for the level of conversation needed with most business colleagues I’ve found that fairly simple diagrams suffice.
The sort of situation I’d use this in would be to discuss with a business unit manager how changes to processes in their area would impact on the systems that support them (or conversely to explore the business impact of a technology change).
Keeping the diagram simple is an important part of making the conversation manageable – the key is to only show what is really necessary to help people make better decisions.
Here’s a generic example of the sort of thing I mean:
Of course this also relies on segmenting the areas you work with into sufficiently small and de-coupled chunks that one person can hold the key links in their head. This is an aspect of technological architecture that is (I believe) often missed in the quest for “economies of scale” – but that’s another post!
