The Web Gambit

Thoughts on Web Development

How Agile is your Architecture?

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.

Further reading:

Jeff Palermo’s blog post – Focus on the Core

Refactoring Databases: Evolutionary Database Design


4 responses to “How Agile is your Architecture?

  1. Kalpesh July 16, 2007 at 1:16 pm

    IMHO, "Responding to change over following a plan" refers to change in the software as per the client needs & not architectural change.
    I agree that having a software designed in an abstracted manner, such that it is able to handle winforms,, wpf etc is great to have. However, how many of the clients would have this as a requirement?
    This is applicable to companies who are into product development & see it a potential for multiple platform. Even then, it will be better to go for one platform, deliver it, see the results/mistakes & develop things later – finding common things between platforms & making plug-n-play components.
    Also, shipping something is important than having a general purpose architecture (which would handle everything that it comes its way)
    Since you work with Telligent (a product company) – can you do me a favor & ask the architects about – is it required to have such an architecture?
    I think these people are smart to decide than me having said things.
    I would love to hear views from the team at your end.
    You know me already ;)
    You can mail me at shahkalpesh at gmail d0tc0m.

  2. Karthik Hariharan July 16, 2007 at 2:17 pm

    Good point, Kalpesh.  For the purposes of my discussion, I was mainly focused to software built around products being developed.
    It’s one thing to focus on completing the task at hand, its quite another to keep in mind things that may come down the pipeline in the future and how to be prepared for them.
    While it is important to ship something initially, as a company its important to recognize that initial success may not translate to long term growth.  Long term growth typically requires flexibility and foresight.  I would advise anyone building software to think about things like reuse and best practices up front rather than simply focus on shipping something that "just works".
    As for Telligent, we definitely like to reuse components and elements of our architecture as much as possible.  As time progresses, we only get better and better at doing this.

  3. James Taylor July 16, 2007 at 3:58 pm

    Interesting post. I posted on this topic as I think making sure that you have an agile layer of services in your architecture is critical. Check out…/decisions-and-t
    Author of "Smart (Enough) Systems" –

  4. David O'Hara July 17, 2007 at 8:10 am

    Excellent post Karthik. I think the best way to do this is to keep the boundaries clean and well defined. By doing this, you're able to have the flexibility for future paths without the need to generalize too much (YAGNI). Being sure that testability is a focus will help with this and provide a framework to lean on if, or rather WHEN, those changes come.

%d bloggers like this: