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 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).
The architecture vision statement is a the result of analysing and filtering what architecture can provide to the organisation based on input like:
To get the vision statement right you will most likely need an iterative approach, below is a list of possible steps.
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.
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.
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!
