February 14, 2011 2 Comments
This post was written by Carl Haggerty and Martin Howitt.
In our last post we talked about why we were looking to virtualise the Enterprise Architecture function at our organisation to protect it from potential savage cost-cutting in the near future. In this post we want to dive a bit into the mechanics of how we are going about it to hopefully offer some insight into the way it will actually work in the future. Parts of this approach have been inspired and or triggered by reading books or blogs posts and participating in online conversations with the following people – Chris Potts, Richard Veryard, Tom Graves as well of course conversations between ourselves.
The core of our Architecture function is based around a services model – the value propositions being outlined in the last post – and we are adopting a staged approach:
- understand each service as a stand-alone business model
- understand the capabilities in the team to deliver the aggregated services
- identify partners in each service area that might potentially carry the discipline forward
- design a process map for each service
- fit identified partners into the process
- mitigate against the risk of loss of key capabilities
Let’s look at each of these stages in a bit more detail.
We used the Business Model Canvas to map the various aspects of the individual services – their value, customers, processes etc. If nothing else this was very useful as it got the whole team thinking in the same direction about what the services were there to do and how they fitted together. It also made us start thinking about who our partners were in each service.
For this we had to really look into ourselves to decide if we were really capable of delivering all of the services ourselves and understand what our core strengths were.
As part of the canvas process we identified a number of potential partners, both inside and outside the organisation, that could be involved in some way in delivering the services. These people are our great white hope for maintaining some architectural thinking going forward.
Each service had a simple process map constructed for it. This showed the bits that were specific to our team and which bits might be more generic, delivered by shared services or other parts of the ecosystem.
Fit potential partners into the ecosystem
Our next step is to approach the identified partners and see where their service models might be encouraged to overlap.
The final step is to make plans to mitigate the risk of losing one or more members of the team.
In the spirit of openness a very rough and first draft version of our canvas is available on Google Docs.
So with all of this in mind how might the future of EA look in Devon? To recap on a post by Jeff Scott – Forrester in his post the future of EA where he outlined 5 different scenarios for the future of EA, we suggested that in Devon the most likely outcome would be either scenerio 3 or 4 or a combination of both.
However the Virtualisation of the Services is actually more about building capacity for going beyond scenario 5 (EA Splits into different groups) – we are actually suggesting a 6th scenario where the core competencies and services of EA are mainstreamed into business functions.
This is about creating a truly collaborative approach to Enterprise Architecture, essentially building a network of Architects and in the short term providing them with the methodologies, standards, models etc to deliver and contribute to Enterprise goals.
It is of course work in progress so we value comments and feedback 🙂