Over the years I’ve talked with a lot of architects about the concept of change. Change both as an agent (process improvment) and also change as a cause (forced).
Interesting that to a person most architects profess a dislike of change.
Yet change is the very factor by which architects exist.
So let’s talk about change. Change is a componet of architectures, in the sense that anything designed today will not ultimately be what gets deployed (and often the variance itself then becomes a separate archtiecture). Technology changes at a faster rate today, then business or IT can. Business often runs upgrades and other IT project over a two and three year period. Yet Moore’s law has us doubling processor speeds every 18 months. SO what is our project window? Can we push IT faster as architects to enable change within the change window we have (18 months) or is change itself a component of the architecture?
The second component of change is forced change. This is a situation where often a competitor or even the market itself (or customers) force an organization to change how things are done. This type of change can be painful. Where we know, in architecting a solution that what is deployed is seldom completely the same as what is designed, in the case of a forced change we now have the additional variable of less time to plan the change. In a forced change there is often the rapid implementation plan desired by the process improvement, but without the longer time for planning and testing the architecture.
Archtiects dislike the fact that nothing is ever deployed as designed and of course that when we forced things are never as clean as wel would like. My favorite old saying about IT is the classic line "on a clear disk you can seek forever." The funny thing is that all the architects I talk to, tend to be senior people in their organization who should in fact be the best people for managing change.
To me, change seems like the component of architecture that is fluid and as such is something that must be considered as well as measured. If we plan for change 18 months into the project, our architecture will then be closer to the final deployed solution.
The only problem we have, is that most people give up their crystal balls 🙂
Now if only we could count on roadmaps and capabilities!