James Taylor's Decision Management

A colleague pointed me to this article - Southwest Airlines Weighs Assigning Seats - and the comment "Southwest officials have openly considered the idea for years, but the $5 million upgrade of the reservations system will for the first time make it possible".

This is an example, and perhaps an extreme one, of why business agility is so key in information systems. In this case, as it is so often, the determining factor in when a company makes a change to how it does business is not when it thinks it should but when it is able to change its systems to support the new approach. In survey after survey, we find that this is increasingly the case with companies reporting averages of "months" to make changes with multi-year waits not being uncommon.

So what can you do to make sure that the new systems you are building today are not going to be the roadblocks in the way of progress for your company in the future? Several things:

• Architect systems on the basis that they will need to change, because they will. Not every piece of a system will need to change the same amount so try and identify "high change" pieces during the design and architect them to be particularly easy to manage over time using business rules management technology. I blogged about this here and particularly like Roy Schulte's comment that systems must be "built to change" not "built to last".
• Remember that well designed systems are just as likely to need changes as poorly designed ones. Poorly designed ones need changes to correct them but well designed ones get more use and will need changes because the world keeps changing. Maintenance work is not something that only happens to bad programmers.
• Find ways to engage IT and the business in a collaborative process to build and maintain applications. Don't throw requirements or code backwards and forwards across a metaphorical wall but choose technologies and approaches that help them work on the system together. Business rules management systems, templates, good testing and simulation tools and methodologies that emphasise joint development and flexibility (like agile development) are all key. I had a great conversation with Scott Ambler on rules and agile development, reported here.

I blogged about a nice article on the inevitability of change here and about why improving requirements won't help here.