Design for Change

I recently saw a great presentation by Becky Wanta about her experiences as the CTO at PepsiCo. Becky talked about some of the “key capabilities” that needed to be developed in the PepsiCo IT organization. One of these capabilities – which I think is often overlooked – is Design for Change.

Capacity to change is a fundamental aspect of Enterprise Architecture. Many of the failings of Enterprise IT such as lack of agility (rigidity), misalignment with the business, and high cost of ownership have to do with an inability to change, and from this perspective I think many people miss the point of Enterprise Integration. The primary purpose of Enterprise Integration Architecture is to support change.

Enterprise Integration is not about getting data from one place to another…if that were the case, then point-to-point integration using scripts would be sufficient. Enterprise Integration must provide a platform which allows the IT infrastructure (the applications, services and processes) to change in line with the needs of the business. Design for Change is a fundamental aspect of SOA, but it is not something that happens automatically.

So how do we design for change? Here are a few best practices:

• Change must be built into the culture of the IT organization. Too often, people build solutions for release 1.0 and without thought for how those solutions will mature, evolve and become obsolete. All solutions have a natural lifecycle that must be figured into the design, implementation, verification and support of the solution.
• Change processes must be a natural part of the system development lifecycle and should be automated as much as possible. Many organizations struggle with regression testing or integration testing because they treat these processes as one-off activities that are part of a development project – rather than planning for them to occur as “business as usual”.
• Different parts of the infrastructure will change over different timescales. Loose-coupling and location transparency are desirable architectural properties because they enable different parts of system to change with minimal disruption to the system as a whole.

And taking a “change-centric” approach to Enterprise Integration can greatly smooth IT transformation – the process of making radical changes to an IT infrastructure, often accompanied by significant business disruption. Some of the more successful IT transformation initiatives I have seen were successful because they regarded Integration as an enabler of the transformation, rather than just another component. Hence leading the transformation effort with a significant investment in the right Integration Architecture (designed for change) allowed transformation activities to extend over significant periods without significant disruption to the business.