Show me your Enterprise Architecture…

The Enterprise Architect or Chief Architect role is often a very murky space to play, because people ask to see this “Enterprise Architecture”, and that unfortunately means different things to different people.  If you asked me for the “Enterprise Architecture” I would want to give you this pack of documents because they are probably most useful in guiding IT decisions:

• Analysis of the Organisational Strategy clearly showing how the Technology strategy Aligns, and if it doesn’t – giving recommendations on how to make it align.
• An Analysis of the Business Functions and key processes, clearly indicating which systems support those business functions.
• A Health Assessment of those systems indicating their systemic health, degree of alignment with the stated business strategies and functions, satisfaction of the users, and technology lifecycle perspectives.
• A Technology Roadmap integrating Business-Unit-level roadmaps and initiatives into a single Enterprise level Technology roadmap.

BUT…

It could take years to establish a functioning Architecture Practice that produces and updates such a pack on a regular basis (depending on the size of the organisation).

So my approach would be to create a high-level draft Architecture in a few months, that will then become the basis of incremental improvement as the process gets established.

If one tries to map all Business Functions and processes to a task level, before mapping systems, before creating a roadmap, you may take too long to get to the point of having any useful impact.

Every Architecture artefact MUST help the organisation to make better decisions, faster.  There must be (and there is) a way to prioritise the EA deliverables in such a way that they impact the “next” important decision just in time.    I am a great believer in creating a mile-wide/inch-deep Architecture view first, from which priorities can be selected and more detailed work can be done.  Very often mile-deep efforts are never finished, or they result in EA investment being cut, because they take too long to yield useful results.

Establishing an Architecture Practice

So my approach to EA establishment would be:

• Assess the enterprise from a high level-strategic perspective
• Decide on the set of EA artefacts needed initially
• Plan the phases of the EA establishment programme
• Create very high-level drafts of the EA artefacts very quickly
• Incrementally populate those with information, but start using them as soon as they contain useful content.
• Expand their use as their content evolves to become more useful

This way value is gleaned early from the Architecture efforts, without compromising the ultimate objective of having a complete set of EA artefacts to guide all the relevant IT decisions at the end of the establishment programme.

In the process of establishing an architecture practice it is also critical to focus on establishing the processes and inserting them into the decision making process as soon as possible.  The earlier that  existing  IT decision-making  processes become used to requesting Architecture input and guidance, the better.  In many organisations with mature management, where architecture is in its infancy, the managers all want a piece of the new architect as soon as they walk in the door.  Mature Managers recognise that there is huge value in making better IT decisions, and the way they can do that is by having proper architectural guidance.  The trick is deciding who to help first, and how to prioritise that effort.

With the Priority of Architecture Artefacts established, the problem of which Business Area’s to start with comes into focus.

The Health / Importance metric.

The Importance metric applies to both Business Processes and Systems supporting them.  Some Business Processes are critical to an organisation, and others cause only a small inconvenience when missing (e.g. pause-area coffee replenishment process – except for Software development companies which run on coffee).  Others are critical at certain times of the month and almost irrelevant at other times (e.g. payroll).  Similarly systems supporting a business process may have varying degrees of criticality.  Either way, one of the important metrics to help you prioritise you efforts is going to be some measure of the importance of each Business process and their supporting systems.

The Health Metric applies to systems, and it measures the degree to which that system is functioning reliably, and meeting the business requirements of its respective business process.  Some technology aspects can also be brought into the health metric, such as obsolescence, and ability of the IT Organisation to monitor and support the technology being used.

I have a standard set of survey questions that I use to determine the Health and Importance metrics, that I adjust slightly depending on the organisation’s requirements.

This information is then plotted on a simple 2×2 matrix indicating the Importance versus Health.  Obviously the items that are important and Unhealthy are your first priorities.  The Unimportant Healthy Systems are obviously your last targets, leaving  Unimportant-Unhealthy and Important-Healthy as your second Targets with some discretion applied.

For Most Organisations, a matrix like this can be completed in a few months and usefully inform the Architecture Priorities; All the while you are getting on with the basic establishment of Architecture Processes, Governance Bodies etc.

So now armed with an approach to prioritising EA Artefacts, and an approach to prioritising the Business-Areas. the EA programme looks less overwhelming, and questions about when it will start to pay off, can easily be answered.