I was at an Architecture conference earlier this year, and I learned two things. If you want to stand out at an Architecture conference, wear a red shirt and ask who owns Enterprise Architecture. Then be prepared to hear thoughts in subsequent sessions on the answer to “the guy in the red shirts’ question about who owns Enterprise Architecture”.
The IT Architecture profession is currently a bit of the wild west. Something to do for fun is to get a group of architects together and tell them there is no difference between a Information Systems Architect and a Solutions Architect. Hilarity will ensue. But tell them that an Enterprise Architects role is to bind them to a common strategy and they’ll turn on you quicker than a group of drunken friends in a bar fight.
The title of Enterprise Architect was relatively recently introduced to the lexicon. And it too suffers from ambiguity, perhaps disproportionately. Do they drive the business, or help them control IT? Do they have their own budget, or do they influence someone else’s? Standards? Strategy? Execution? PowerPoint? Visio? Code?
In absence of consensus, some say an Enterprise Architect has to be all of these things. A tall order, and arguably some combination of unachievable or ineffective. But truth be told it can often be a profitable one for those who can achieve the right combination of convincing and being. Everyone loves the hero.
Problem is you only need a hero when things are bad. And often in those circumstances the success of the Hero’s Journey is grounded more in a desperate need to believe in success than in actual success. Because if success was already recognizable, it would likely already exist, and that… follow me for a sec here.. would negate the need for a hero. Go ahead and re-read that, I’m kind of proud of it.
So how does an organization make success recognizable? Quote time:
“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” You know him; you love him; Albert Einstein ladies and gentlemen!
There is no more important activity than defining the problem. It is the best indicator of where your solution will end up. Yet amazingly it is more often than not staffed inappropriately and done poorly. 120 page Business Requirements docs, a reference made during a two hour meeting, and numerous other head scratching and often hilarious deviations.
A properly defined problem should answer the Zachman 5 W’s (What How Where Who When Why). Full disclosure – I first heard the 5 W’s it from my 5th grade English teacher; she apparently didn’t have as good PR as Zachman (but it is actually quite a bit older and more storied).
A properly designed solution should clearly indicate the gap between the problem state and the designed state. It should define the transition in a terse language that is easily understood by anyone in the organization. This is not the time for ‘Adjective Scavenger Hunts’ or ‘Catchy Code Names’. You can still call it ‘Operation Bluefish Alpha’ if you want, but if it doesn’t clearly describe the work to be done the chances of failure increase by approximately eleventy-billion .
The collection of an enterprise’s properly defined solutions is the Enterprise Architecture. It is not a role, or a process. It is not owned by one person or one group. It is a goal. It is unique to that organization, and everyone who contributes to it (and everyone in the organization should) is part of the Enterprise Architecture team.
For any organization of size and complexity, this can not be achieved by even the heroyist of hero’s. It takes a team of multi-disciplined resources – an organization – working toward a common goal – an Enterprise Architecture – that is defined, designed and delivered using the ubiquitous language of that organization. But that my friends, and the role an Enterprise Architecture Consultant can play, is another story.