Change Management is not an Implementation Issue

It’s good that we’re taking a greater interest in the relationship between enterprise architecture and change management. The interesting thing about most discussions is that they talk about enterprise architecture as the “development” phase and change management as the “implementation” phase. There’s certainly nothing wrong with this but I don’t think it goes far enough.

The reason I don’t think it goes far enough is that change management should be an input into your enterprise architecture work. It shouldn’t be a handover – we’ve built this great thing and now ‘lets do some change management’ and roll it out.

I’ve got a software background so I’ll use a software development analogy. When you’re designing software you should always take into account the deployment environment. If the application is to be deployed in a Microsoft environment then PHP and MySQL aren’t your best bet. This example is far fetched but the fact remains – deployment is a non-functional requirement, it should not be an afterthought. If you can’t deploy your finished application to the target environment then its not a ‘deployment’ issue – it’s a development issue.

What’s this got to do with enterprise architecture? Some EA teams are full of great ideas that never see the light of day purely because the change management issues are not considered up front. Typically this problem manifests itself it two ways:

  • Organisation issues – EA teams generally don’t have the clout to force large scale organisational changes – even when such changes are the right way to go. If your architecture work requires such changes in order to be of value then you’re wasting your time.
  • Technical issues – the EA team come up with a great ‘target architecture’ but don’t provide any guidance on how to get from ‘here’ to ‘there’. Enterprise architecture is a journey not a destination – so you need to provide a map.

Obviously, you don’t want your EA efforts to be hamstrung completely by organisational issues and technical issues. Enterprise architecture should be about change – and change always leads to some amount of discomfort within the organisation. They key is to find the right balance. Some organisations can handle revolution others prefer evolution. You want to push the envelope – but not to breaking point.

PS: If you’re interested in a good book about a similar topic try High Impact Consulting by Robert Schaffer. In a nutshell the book is about tailoring the work you do to what the client is ready to do. No matter how great the work is, if the organisation cannot use your advice (deploy it) it just becomes useless shelf ware.


One Response to Change Management is not an Implementation Issue

  1. Raf-

    My company, SFI ( offers a service management solution on the IBM Mainframe in support of the entire organization. The suite includes problem, incident, change, request and configuration management. What makes us unique is that we run exclusively on the IBM Mainframe and cater to the largest enterprise environments in the world. I liked your latest blog because we approach service management from an architectural perspective in support of IBM Mainframe customers that run the majority of their applications on the host. Not enough customers consider their architecture when implementing ITIL solutions. We hope more organizations realize the importance of architecture when making application decisions for change management as well as the other service management modules.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: