Why we need an Enterprise Architecture vision

In some enterprises, it’s already documented what is expected of the architecture team. In other enterprises there is still a lot of ambiguity of what is expected of the architecture team. But in both scenario’s it’s important to develop an architecture vision statement for managing expectations. An architecture vision statement is required for scoping the architecture work. In the scenario of documented expectations, the expectations can be adapted and adjusted if enterprise architecture can provide less, more or different things than what is expected.  Honest and open collaboration from the start with peers, business and IT executives is key for managing the expectations.

An Enterprise Architecture vision statement

Get the vision statement right! It’s essentially the compass for the architecture strategy, the vision statement should at least describe;
• What value architecture can offer to business & IT
• How it aligns with Business & IT objectives and the overall business strategy
• Where we are and where we want to be for architecture (at a conceptual level)
• How it provide guidance for solution design (for example by selecting appropriate architecture standards

Creating the vision statement

An Enterprise Architecture vision needs to be adapted to the Enterprise. Business, application, data and technology architecture is the typical architectural playing field. All architectures need to get the required attention from the start (but not necessarily the same weight or priority).

To get the vision statement right you will most likely need an iterative approach, below is a list of possible steps.

1. Gather input for the objectives.
2. Analyse the input.
3. Create a vision statement version within the architecture department.
4. Present the analysis and the draft vision statement to peers in programme management, operations,… and align with other active initiatives and incorporate their feedback.
5. Present the analysis and the draft vision statement to business and IT management and incorporate their feedback.
6. Repeat 2-5, until there is an agreed and supported vision statement.
7. Formalise executive sponsorship for the final vision statement.
8. Publish, present and sell the architecture vision.

An example for analysing the input is shown below. You list the business, IT & innovation objectives and compare them to the drivers and challenges within the enterprise.

Identify required initiatives, based on cross referencing drivers and challenges versus objectives.

Please note, you should not limit yourself to the matrix shown above (or any other matrix), although this provides guidance for analysis and traceability. During workshops it’s possible that you identify additional initiatives that create business value and they can be very valuable for the organisation.

What is next?

Although creating and having an Enterprise Architecture vision is absolutely critical, as this will provide you the compass for architecture work. I believe this is the easy part, following through with the architecture strategy and implementation will be more challenging. But if there is no documented and agreed architecture vision and it’s unclear what is expected, embedding architecture in an organisation starts to resemble a “mission impossible” assignment.

For expectations that can’t be met by architecture, the architecture team can collaborate with for instance programme management and operations. Some initiatives shouldn’t be lead by the architecture team, architecture is not the silver bullet to overcome all challenges and meet all company objectives.

When you did the effort of aligning with programme management and operations departments during the creation of the architecture vision, collaboration for creating an IT strategy will be more efficient and most likely be more effective.

In the picture below is shown how the architecture vision will influence the IT strategy. A documented architecture strategy next to a proposed project portfolio and a service improvement plan can form a foundation for the IT strategy.

The feedback loop (again an iterative approach) is an opportunity to adapt, based on improved understanding. But this shouldn’t be an endless process and should be timed and managed appropriately.

Defining the architecture vision statement will not be a one-time effort, the vision needs to be reviewed if there are substantial changes to business objectives, organisational challenges, innovation opportunities, drivers and/or IT objectives.

Your thoughts and remarks?

This was my pragmatic perspective on the architecture vision statement. I hope this can help you create, update and most importantly promote your architecture vision.

I love to hear your thoughts and comments!