Virtualising Enterprise Architecture 2: Process

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.

Business Model
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.

Team capabilities
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.

Partner identification
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.

Process maps
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.

Risk mitigation
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 🙂

Advertisements

The Future of EA is no EA

An excellent blog post by Jeff Scott from Forrester on the future of EA has got me thinking about the most likely future state of EA in DCC.

The most obvious future and one which i entirely agree with is that EA as a function will disappear in time. My previous post about mainstreaming ICT functions supports this view as everything becomes a core business competency. But what happens between now and then and what direction are we really moving in and more importantly what direction will the organisation accept us to move in?

In my personal opinion i would suggest the there are two options which are most likely in DCC over the next few years and i think we are likely to end up with both of these scenarios:

Scenario 3: EA remains in IT, largely focused on technology architecture.This seems to be the most likely outcome for small to medium sized IT organizations. In this option business architecture will be developed primarily as input into the technical architecture. The key to success here will be for EAs to evolve from technology planners to true IT strategists.

Scenario 4: EA remains in IT but becomes more business focused.This model will be prevalent in medium to large IT organizations where IT has developed a strong partnership with the business. Here, EAs will be welcome at the business planning table and will be well regarded by business and IT for their ability to match business needs with IT capabilities. The business architecture focus here will be business-IT alignment. EA’s resources will be about evenly split between BA and technology initiatives. Successful architects will be very business savvy but keep their technology roots.

There are some justifications behind my thinking which i will share with you now.

Scenario 3
The likelihood of this future is related to a number of key factors – the ability for the EA team to maintain business people within it.  If this is maintained then this future will become less likely, however without real Business engagement and acceptance across all areas of the organisation to the benefits of Enterprise Architecture as an approach and not just conversations between ICT people and Business people trying to bridge the gap, then we will inevitably resort to Technical Architecture work.

Scenario 4
The likelihood of this future is already taking shape, our new ICT strategy is very much business focused and we already have a team in the business who are leading on Information Architecture. The challenges for this scenario however are again the ability of the team to engage with Business people and to maintain the business skills already developed in the team. However i would suggest that over time the focus of the team will be driving the technical architecture in response to the business. I also think that the business architecture function will not only be about Business/IT alignment but the architecture of the IT function itself.

If we get to a point where the IT function has had appropriate levels of business architecture then it would seem a likely next step to embrace Scenario 1 and 2 – The EA team disappears as a unique function and is absorbed totally by the Business as a core competency.

In my humble opinion we would have succeeded as an Enterprise Architecture function if this outcome is achieved.