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 🙂

Virtualising Enterprise Architecture for Sustainability

This post was written by Carl Haggerty and Martin Howitt.

We are currently facing some of the toughest times in the council,  budgets are being reduced and staff will inevitably be made redundant. The future for some looks very grim and whether the Enterprise Architecture Team (EA Team) survives the next 12 months in its current form is very much unclear.

One thing is certain, though: in periods of rapid and deep change, enterprise architecture as a discipline provides a whole range of value-adding tools, methods, models and attitudes that could make the difference between a well-executed shrinkage of the organisation and one that destroys much more value than it should.

Therefore some (well all of us really) in the team believe that it is better to equip and build capacity in order to drive forward the disciplines and methodologies of Enterprise Architecture than to simply naval gaze and try and justify whether or no we should exist when front line services are being threatened – Carl has blogged previously about the future of EA is no EA.

To some degree the fate and future of the team is in the hands of the political powers and they have the unenviable task of balancing the needs of communities with priorities for the council. That will mean people losing their jobs.

To be clear about what services the EA Team currently provides, let us just share with the outline and scope of what we do. Martin has blogged broadly about EA Services before.

Research
Examples of the value we add are:

• key trends, risks and methods for strategic change
• Communication of vision
• challenge & lateral thinking
• translation of strategy into different formats
• direction setting for solution architecture/design
• reduce friction for projects/programmes
• “values” input to portfolio management
• market intelligence to improve IT/business relationship

Consultancy
Examples of the value we add are:

• Increased value of project outcomes (Internal and External)

Education
Examples of the value we add are:

• Awareness of current issues in technology and business
• Context around certain projects and developments with the organisation
• Local Government Perspective on certain trends
• Knowledge
• “Art of the Possible” (eg if we implemented practice x or solution y, what could we achieve)

Assurance
Examples of the value we add are:

• Standards, work load control
• Visibility of work
• Communication of situation, management of expectations

Modelling
Examples of the value we add are:

• Linking National to Local; Influence National Strategies
• Key Trends; Shared Service Design; Externalised Services; Integration; Co-ordination
• Accessibility, Accountability, Facilitation
• Visioning; Cost Reduction, Risk Reduction, Organisational Performance, Design, Business Modelling
• Planning Strategic Change; Service Delivery Models;
• Key Trends; Local Service Design
• Strategy; Standards, Architectures, Assurance
• Strategic alignment; Architecture Definition; Standards Definition
• Consulting uses models to assist customers: Education uses models to educate and inform; Assurance uses models to guide decisions

Since we adopted the service model over 12 months ago, it’s become clear that we are overlapping with other parts of the organisation – our Learning and Development team, for example, provide an Education service even if it doesn’t focus on the same subject matter as us.

Understanding these overlaps gives us an opportunity to form partner relationships which will have the effect of driving EA thinking deeper into the organisational fabric. This process of understanding where the overlaps exist has also made us think about whether we should be leading these services for the council, or whether we could simply instill Enterprise Architecture disciplines into other parts of the organisation and in effect virtualise the services across different teams and functions and therefore perhaps creating a more sustainable approach to Enterprise Architecture in the council.

In our next post we are going to outline the process we are using to make this happen.