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.

Reorganising the Reorganisation of the Organisation

We live in a changing, and challenging, world. If we weren’t sure about that before, we certainly are now. So where does Enterprise Architecture sit in the middle of all that change?

We could sit under the kitchen table with out hands over our heads and wait for the noise to stop. We could run out into the street screaming and shouting and generally getting hysterical. Neither fit our style. Instead we chose to continue doing what we do in a controlled, calm and professional manner.

Why?

Because all of this change that is going on only serves to remind me that Enterprise Architecture is needed even more than ever right now. We have the vision, we have the blueprint, blimey – we even have principles! What more could you ask for when looking to answer the tough question that is being asked of us all – “How do we continue to provide the services that the citizens of Devon need, using 25% less resources and with 25% less people?”

My answer to that would be to be clear about what you are trying to do, to do it once, and do it in the most efficient way possible.

Reminds me of the good old days of TQM! In those days though, times were good and resources could be thrown at a problem – sorry – opportunity!

Today times are challenging.

As a team of Enterprise Architects we need to make sure that people take advantage of us (in the nicest possible way!). We need to ensure that everyone knows what we do, what our vision is, what principles are and how they can apply them to their part of the organisation. Personally, I don’t think that reorganisations should take place in silos. People should not be concerned about protecting their “patch”, we have one single purpose and we should be viewed as one organisation – a single enterprise.

Or, maybe, I am just trying to protect my patch?

From IT to Enterprise

Have you tried to reposition Enterprise Architecture out of IT and into the Enterprise? Any advice would be gratefully received!

We in Local Government are living through a time of re-organisation, re-focussing and re-budgetting. In fact our reorganisation is being reorganised as I type! Not an easy world to live in, but one that offers up hope and opportunity. Perhaps not for individuals, but certainly for the organisation as a whole. We have a once-in-a-lifetime opportunity to change the face of local government, and get away from the perception that most non-local government people have about us.

We will no longer be huge anonymous entities who do “stuff” that no-one can name. Almost every day now in the press there is talk of service cuts – not good, but bringing to the public’s attention the amazing, important and varied work that we do, usually quietly in the background – is good. More and more people are appreciating the role we play in society, be it big or otherwise.

Our personal circumstances find this EA team with an opportunity to show the rest of the organisation what we can do, and how we can offer true Enterprise Architecture. Over the next week or so we will be concentrating our efforts on developing our Services Model to communicate what that actually means. Currently it concentrates on IT as that is where we have historically sat in the organisation, and we need to expand it out to the whole. It is an exciting opportunity, and we are really looking forward to developing our thinking.

Meanwhile, we still need to ensure that our IT architecture holds up, and develop a new assurance model for the new way of working.  If nothing else, the start of 2011 is a busy one for us!

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.

Doing the right thing – Todd Biske» IT Needs To Be More Advisory

An excellent blog post by Todd Biske.

IT needs to change its fundamental thinking from provider to advisor or be at risk of becoming irrelevant.

via Todd Biske: Outside the Box » Blog Archive » IT Needs To Be More Advisory.

What i find interesting about this post is that it supports what we are trying to do here in Devon with our Enterprise Architecture Team.

The key point about moving from provider to advisor is as Todd says “stating the obvious” but it clearly does require a fundamental shift in thinking not just within ICT departments but within the wider business as well.

Todd writes:

To illustrate this, take an example from the world of financial services. A broker may simply be someone you call up and say, “Buy 100 shares of APPL at no more than $200.” They are a provider of stock transaction services. A financial advisor on the other hand, should be asking about what your needs are, and matching those against the various financial offerings they have at their disposal. If they don’t understand client needs or if they don’t understand the financial offerings, you’re at risk of getting something sub-optimal.

This is correct, however in a work context, someone has to know that they want an advisor and not a broker, so part of the challenge is shifting the perception of the entire ICT function in the organisation from “provider” to “advisor”. This requires educating and working with your internal customers and delivering value in an advisory role. We believe that our Enterprise Architecture function is part of this transformation here in Devon.

Time will tell but it is reassuring to hear people such as Todd state the obvious and support your efforts.

Just wondering

What are we?

We are Enterprise Architects, thinkers, dreamers, intelligence gatherers, visionaries, police, communicators, persuaders, presenters, sharers, writers, budget planners, strategists, principled … Is there any wonder we find it hard to explain who we are and what we do! 🙂

Making a Difference

In January the Enterprise Architects Team will be a year old and after a few fire-fighting decisions made this week, I am starting to reflect on what difference we have actually made to the organisation.

It has been an interesting time, moving from having to look up the definition of Enterprise Architecture, to living and breathing it. The team have jelled really well (my opinion – I guess the others will have to give theirs), and we have learned an enormous amount. We have a really clear idea about what the business wants from ICT in order for them to move forward, and we even have some principles in place for decision making. Communication is coming on, and we are starting to get the message across. All great progress.

What is proving really hard is actually changing anything. All I seem to do at the moment is provide the spanner that gets firmly planted in the works. Moving from what we do now (and have done since 1845 if you listen to some people), to what we should do, is hard. We have “pie in the sky” ideas, all firmly planted in reality – they are what the business wants, but we can’t seem to deliver because the day job gets in the way. Sometimes I wish I could stop the world turning, just for a week, catch up and start again.

I suppose what we are facing is an inevitable consequence of having a team of people going out and actually asking people what they want – fatal! :O)

I am now looking at this whole programme as turning around the archetypal tanker, it is going to take a long time. We are going to have to keep plugging away with the communication, and adding our 5p’s worth at each and every opportunity that comes our way. We are changing now from our “discovery” phase into a patient dripping tap phase.

I think we will need determination and patience – we can do that – no problem. We can do it because we have a real clear vision. We know where we need to go.

So what does an “enterprise architecture” look like?

Hello! My name is Martin and my particular role in the team is to produce a security layer that will overlay the rest of the EA programme. To do this, of course, we need to know what the EA as a whole will look like. I also need to answer the question I now get asked most often: what does an Enterprise Architect do? So I want to take a short tour through the process of creating an architectural model.

I see EA as being a branch of strategy: a classical strategy formation process weighs the strengths and weaknesses of an organisation against threats and opportunities in its environment, and an EA effort is like a technology-enabled extension of this. I expect that most top-level strategy people aren’t necessarily totally up-to-date on the latest technology trends and what they might do for their businesses – EA can close this gap.

All strategic planning seems to entail the formulation of a vision that sets out where an organisation wants to be, where it is now, and a plan to get there.

formal strategic planning process

formal strategic planning process

We are using the Gartner model: other models exist but they all seem to end up in the same place. This view captures environmental trends and existing business strategies to create a set of requirements stating what the business needs to achieve and – in a large and diverse organisation such as ours – focusing on the common factors of this across all parts of the business. As Sue has alluded to in her previous post, we have created this “Common Requirements Vision” document through conversations with some of the leading strategy people in our organisation.

The next step also parallels some strategic planning models in that it looks at Principles. This is analogous to a set of corporate values but in our case they focus on the use of technology. An example of a principle could be something like “secure information and systems to gain public trust” – something quite close to my heart – and we have about 10 principles at the moment, although this work is still ongoing.

The final piece in the jigsaw of the top layer of this process is to develop models. At this level the model describes two things: what is or is not included in the architecture effort (we generally want to include areas that are common to the whole organisation, such as authentication and collaboration systems, and exclude line of business systems) and how we might slice up the enterprise (for example into business, information, and technical views).

These three items – requirements, principles, and models – together form a vision of the future enterprise. In Gartner terminology, this is our “future state”.

The views developed in the models phase each have their own requirements, principles, and models, future and current states, making the whole architecture like an onion progressing to greater and greater levels of focused detail.

EA process

EA process

The Beginning

As a new team of Enterprise Architects, our first task was to get to grips with what Enterprise Architecture (EA) actually means. There are millions of pages on the Web that will give you various flavours of EA, what to do and where to start. It was evident that we needed a consistent plan and some expertise in the area. To help, we chose Gartner as our consultants and joined their EA programme. This provides us with not only expert research and analysis, but also support from one of the Analysts, allowing us to move at our pace, but towards a tried and tested goal.

Now we have a plan, we are working through the various documents we need to produce. Our first challenge was the EA Charter – this has now been written and has been ratified by our Governance process. Then came the Common Requirements Vision – again this has been done and agreed.

Next on the list are the Principles – the over-arching principles for the Enterprise Architecture. To do this we have started to engage actively with the business, and each Enterprise Architect is now linked with a specific Directorate and member of the Governance group. This has brought many benefits. This close liaison has allowed us to “sanity check” our thinking – making sure what we think the business needs is indeed what the business needs, and to shape the priorities for the future vision. Now we have to agree with them the principles that will guide us towards that vision. It is a challenge – but an immensely rewarding one.