Most (all ?) of the EA frameworks exist to guide and structure change. The TOGAF framework starts with a Vision for the future so it must be about change ! The implementation of that change, the delivery of that new Architecture causes the business to change. I have seen many initiatives fail, not because the Architecture was wrong but because the business either didn’t want to change or wasn’t ready to do so. It wasn’t the architecture that caused the failure but ‘the business’ itself. I put ‘the business’ in quotes because architects often see it as some amorphous blob that is being changed, rather than real people with real emotions and skills.
Business Change is the discipline that encourages the business to change. Business Change is about understanding the amorphous blob and encouraging it to change both from the inside and from the outside. It’s about employee engagement, communcations, measuring customer experience before and after change and an awful lot more. As architects, we traditionally deal with the ‘hard’ (as opposed to ‘soft’) change: changing processes and tools and organisations. The mechanics of how they are changed is often not our concern, we just know that ‘the business’ needs to change and we’ve defined what it needs to change into. Unfortunately, ‘the business’ won’t change unless the Business Change discipline is used. It’s arguably more important than the architecture. The reasons that many initiatives fail was a failure of Business Change.
There are plenty of Business Change frameworks out there, in the same way that there are plenty of EA frameworks too. This is just one of them, taken from Google (http://www.sourcingmag.com/) and I make no assertion that it’s correct, complete or even well drawn but it does provide me with something to discuss:
Each time that I look over these, I think that ‘Business Change’ needs to be another bubble inside TOGAF. It’s arguably part of Migration but the Business Change activities need to start during Vision so I think that it needs to be at the centre, in the same way that Requirements is at the centre. There are a lot of things that need to change in TOGAF so I’ll leave that debate for another day. (Before you light the flamethrower: there are also a lot of things that are right in TOGAF too.)
I’ll go from left to right across the model, picking out the important boxes, starting with ‘Communication’. Just saying that ‘Communication’ is important does its importance a disservice. It’s communication that opens the way for change and it’s communication that faciliates change. ‘Doing’ communication is hard though. Finding the right messages and communicating them in the right way at the right time is both a science and an art.
The next box, entitled ‘Business Change’, contains a lot of very very difficult activities. The words ‘HR Alignment’ are sufficient to chill the heart of anybody that’s been involved in a redundancy consultation process but it’s a necessary part of ‘Change’. Employee communications, especially once they’ve understood what the ‘Change’ is supposed to be, is also difficult. If that ‘Change’ message is not communicated successfully then the employees with the skills that need be retained start to disappear, either redeployed or through resignations. Transition Support is also absolutely vital and often overlooked. Whilst it can be an enjoyable experience for those supporting the change, it’s a tiring time for those that are ‘being changed’: another new system to learn, a different process to follow and new people to interact with.
Finally ‘Training and User Support’ is never given the importance that it deserves. Too often it’s overlooked or left as ‘train the trainer’-type support. After all of the money that’s been spent on the change, sufficient should be kept back to (re-)train the employees that are expected to follow new processes and use new tools. Maybe we need to remember to do change from the outside in – starting with the employees and what they need.