Design for Change as an Agile Architecture principle

The best definition of a legacy system: The system that works in production. Unfortunately, I can’t remember from whom I heard this definition.

Your customer or employer runs his company with legacy systems. The technology in use might be very old, but it does deliver business value. That can’t be said for a system that you might be designing right now. The chances are that, if you are lucky as an architect, your system will shortly after hits the production be marked as legacy or ready for replacement soon. If you are even more lucky, the system will be extended and somewhat adjusted for few years to come.

Eventually, the inevitable will happen. IT management decides that operational costs are too high, time-to-market for changes is too long, technology is not supported any more and so on. It seems that nowdays with all the technology changes this problem is only worsened.

But, is it really inevitable that so many large systems are replaced completely?

One of the main causes is tendency to prevent this problem in first place. The main words used by architects are flexibility and generic solutions. If our system is flexible and generic enough, then we can handle our future requirements. The result is usually wishful thinking and just more complex solutions. Complex IT systems are always sooner outdated than simple ones. It is nowdays more and more difficult to predict the future, considering the pace in which business people change their mind.

It is much safer and cheaper to build system which will NOT last very long as it is designed. More precise: defined architecture will not last for long. If you build a system that is designed to be changed, than you are NOT building generic components, but only making sure that specific solution is cheap in case of partial replacement. This goes hand in hand with Scrum where you are always making sure that you are able to embrace the change, no matter how extreme this change might be.

Principles in achieving this:

  1. The simplest possible solution is cheapest one to replace.
  2. When introducing new system part or technology, you should find out how much it will cost to replace it.
  3. Prevent depending on underlaying technology as much as possible.
  4. Make sure services / interfaces are based on well defined loosely coupled functions your user and business understands. Do not make generic SOAP interface or some other technical standard interface. Replacing one technical standard with another is much cheaper than changing functionally highly coupled systems.
My belief and experience is that when equiped with these principles, your system will have a bigger chance of evolving instead of being replaced completely.

3 thoughts on “Design for Change as an Agile Architecture principle

  1. Interesting statement, to which I at least partly agree. I'm looking forward to some examples that elaborate all of the statements. I can also imagine the statements are valid for the presentation and business logic layers in an application, but you do need tight architectural controll on the data layer and interfacing between different applications.

  2. In the following postings, I'll give concrete examples instead of just nice sounding statements. πŸ™‚ Even data layer can be just as changeable as any other layer. Interfaces are different story and will be my next posting.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s