Wednesday, February 20, 2008

Implementing IT Architecture is all about change

Implementing an IT Architecture is changing the way we look at the IT systems, the way we deal with them and so on. A change management approach appears to be best method to drive the implementation. Now change management in IT is a subject for a book on it's own, so for now I will only give some practical suggestions for IT architects how to position themselves during the implementation phase. Because this is where 90% of the architect's work is done.

As many can attest, change also seem to cause resistance. Almost like the third Newton law "actio et reactio". Why do people seem to resist to change? Well they don't, people change all day. Who sticks to his plan every day? Lack of insight what is going to happen, or even worse lack of influence on what is going to happen results in lack of control, which creates the anxiety and stress that people hate so much.

You typically see that there are many roads to Rome. The choices often makes implementers nervous whether their choice was right. The desire of people to control things in life and the fact that there are many ways to reach a destinations is something you should take advantage of. Let the people involved decide for themselves how to get to Rome. Appeal on their own brain power. Don't worry where they currently are and what they are doing. Waste of energy.

The lead IT architect should be very clear what the destination (reference architecture) is, this is no subject for debate. Those in doubt about the validity of the destination should search their own, but not argue with the IT architect. But how one gets to the destination can be very different for various stakeholders. And when they can create their own marching orders, they feel much more confident to pursue the change instead of resisting them. The lead IT architect should just join the program leader in his helicopter and make themselves available for anyone who is or seems to be lost.

Now I don't want to suggest that the destination is final. IT systems are very dynamic in nature and therefor the IT architecture is not so rigid as in the physical world of architecture. People may get confused when they are heading in a certain direction that the destination has moved. Instead of allowing the concept of a "moving target" which creates a lot of uncertainty, I prefer to explain that it is journey. We have therefor intermediate destinations. And let the organization decide themselves if and when it is worth continuing the journey.

© Peter Bodifée 2008. All rights reserved

No comments: