One of the cornerstones of the Agile Manifesto is Responding to change over following a plan.
Most of the time, we see this parable being applied to teams of software developers, but not always to the software itself. After a certain point, the software’s architecture becomes rigid and inflexible, and only allows for minute changes to its supported feature set.
This becomes especially true later in the software’s lifecycle as its code base matures. As time passes, most software packages need to be substantially rewritten to support new technology changes. Such changes can include:
- Newly supported database platforms (e.g. SQL Server to Oracle and MySQL)
- Changing the presentation layer to support a different platform or go native (e.g. Web to WPF and Silverlight)
- Changing the application service layer platform (e.g. J2EE to .NET and RoR)
When designing your product architecture, it is easy to remain platform agnostic in some areas, while exceedingly difficult to do so in other areas. Additionally, most organizations are limited by time, money, and the expertise of the developers writing the software and thus make quick decisions with limited resources.
Database support is usually the most flexible part of most application architectures as it is considered a best practice to support the big three database platforms. While this may result in losing some performance benefits specific to a database, most developers are willing to sacrifice these benefits to avoid the excruciating pain later on when support for more databases is injected after the software has been released.
Presentation layers, on the other hand, can be notoriously inflexible as most platform evangelists tend to emphasize Rapid Application Development through the use of platform specific tools. While these tools can help build a demonstrable application quickly, they sacrifice a great deal of flexibility to do so. By emphasizing the use of less visible code, these tools tend to hide the inner workings of large sections in the application’s architecture. Thus it is difficult for any developer to successfully emulate the patterns implemented by these tools when the time comes to change platforms.
Service layers are generally the most difficult to flexibly design as this layer is generally composed entirely of platform specific code. The good news is that of all the pieces of technology that compose your architecture, the Service Layer is the one which tends to have the longest shelf life. The degree of difficulty involved in changing Service Layers leads most organizations to only change this layer once per decade. I believe that a degree of inflexibility in this layer is probably unavoidable in most situations.
Expecting to develop a code base that is flexible to every one of these changes is an ideal situation that is nearly impossible for most organizations.
In turn, most developers are likely to be more successful if they can limit their scope to one platform and leverage the platform specific capabilities to build more efficient, solid code. Introducing an unfamiliar platform to inexperienced developers can result in enormous costs and heavily impact productivity.
However, there are significant advantages to making your architecture agile as it can make you better prepared for unforeseen changes down the road. These changes may include:
- Requests for new platform choices from customers
- Emergence of a competitor with greater platform support and thus a wider audience
- Staff changes resulting in gained or lost technical expertise
Building a more Agile architecture is indeed a daunting task, but I firmly believe that the benefits outweigh the risks. If it may not be possible to make your first product architecture an Agile one, the lessons learned from building it should certainly be utilized when building a second, more Agile architecture.
Jeff Palermo’s blog post – Focus on the Core
Refactoring Databases: Evolutionary Database Design