Architecture and Business Change

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 ( 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.

Impact Analysis using the capability value chain

The post before last discussed building a model of the enterprise that included dependencies between capabilities:  ‘Make the tea’ depended upon ‘Maintain the kettle’ and so on.  The model can be used to create complex impact assessments, and, if the model has the data in it, a very good architecture for the solution design.  The impact assessment, of course, has to be at the stage where a review at the level of capabilities is appropriate.  This is usually at the early stages of a new idea, maybe to scope how wide and deep the impacts of that idea might be and to set out the high-level architecture.

Once the value-chain model is in place, a quick impact assessment of an idea can be performed very quickly.  The first step is to document the capabilities that are needed by the idea.  Once that’s been done, a quick check against the value chain model shows up the other capabilities that might also need to be changed.  The ones that need to be changed are those that connect with any capability that was documented as being necessary to deliver the idea.  For example, the preceeding capability might need to be changed (to, for example, provide the data correctly) and so might the following capability (to, for example, accept the data correctly) and so might the supporting capabilities (to, for example, accept an updated interface)

The scope of the change necessary for the idea then, are the directly impacted capabilities, the preceeding, following and supporting capabilities.  That’s a high-level impact assessment done almost instantly.  Admittedly, there’s some skill in picking the capabilities necessary to deliver an idea but that’s where the skill of an experienced Enterprise Architect is needed.  It also provides a fact-based definition of the scope of a project and that definition allows people to challenge whether the scope has too many risks associated with it, can be delivered in the available timescales or with the available monies.

If the model had been expanded to include the mapping between capabilities and IT systems, processes and teams then quite a definitive scope can be extrapolated very quickly from the documentation of the capabilities and those that surround it in a value chain.  I’d always advocate that the mappings between capabilities and people, processes and tools are maintained for just this reason: it makes impact assessments so much easier.  Of course, the capability model can be used when the project moves into the more detailed phases too.  The detailed business requirements, for example, can be captured against capabilities.