How far up the ivory tower should Enterprise Architects climb?

How many of us, when discussing architecture, have encountered the response “Architects? What do they do for us? Just sit in ivory towers drawing diagrams”. Surprisingly this response does not always come from a cynical business community but often from the very individuals or teams who stand to benefit from having access to knowledgeable and experienced architects, i.e. the IT teams themselves!

Over the years I have tried to identify why this is and can only think that their experiences have been ones where people have been happy to use the label ‘architect’ (it sounds much grander than ‘programmer’ or ‘manager’!) but have not understood, or been prepared to provide, what architecture is really about. Yes, a number of diagrams (or more correctly models) are produced but in the right environment, following the right approach and with the appropriate level of engagement with delivery programmes, an experienced architect produces what are in fact invaluable frameworks and solution blueprints.

So, my answer to the above is always “Yes, I do sit in a tower but only because it gives me a wider view of what is going on, how the various solution parts should come together, but I am always careful to ensure that I don’t loose touch with what’s realistic or practical”. It is a conscious decision to get a balanced view, i.e. wide enough to see the business drivers and overall solution context whilst still understanding the development and deployment constraints and possibilities. The architectural frameworks and solution blueprints then produced from this higher viewpoint, particularly when operating in the enterprise role, are much more relevant and effective in:

• Communicating the business solution vision to stakeholders;
• Guiding analysis and feasibility studies;
• Helping capture requirements and elaborate design principles;
• Assessing system impact and risk;
• Identifying solution options and making design decisions;
• Ensuring the full solution lifecycle is covered.

There is another side to taking this elevated position. It is crucial that those who need the day-to-day guidance and governance on development/implementation programmes (e.g. analysts, developers, project managers) are readily able to identify you as having the knowledge and perspectives to provide the business drivers, the solution context and the architectural structure. It is no good trying to operate as an Enterprise Architect if you are ‘down in the detail’ all the time – you will not have the necessary senior stakeholder relationships, the longer-term solution vision or the system ‘big picture’ - teams in general will not accept you as providing any solution leadership or design authority.

As with so many things the final choice, in this case ‘how far up the tower’ you go, is down to balance and compromise. Hopefully, by considering the following questions you should arrive at something that enables you as an Enterprise Architect to achieve the goals above.

• What is the scope of the solution programme(s), e.g. Intra/inter organisation, B2C/B/E?
• What is the impact and lifespan of these programmes and which stakeholders need to be kept informed of where the solutions are going?
• How many domains of expertise need to be managed within teams, e.g. applications, channels/integration, information, security, networks, deployment, operations, etc?
• What is the level of architectural and technological risk?

Anything which points to environments and solutions which are departmental in focus, have a small footprint, are short-term, use well known and familiar technologies, and/or have a local resources will tend to need someone operating in more of a Systems/Project Architect role closer down to the programme detail. However, environments and solutions which are larger-scale, typically geographically dispersed, are longer-term addressing strategic business needs, are complex with many domains, use new/innovative technology, and/or have dispersed multi-disciplinary teams requiring guidance and governance will need an Enterprise Architect position ‘higher up the tower’.

Remember - Keep your feet on the ground but your head high enough to see where the enterprise needs to go.