Software Architecture - Agile vs Waterfall

The decision of Agile vs Waterfall in software development is not often linked to architecture.  However, there is a difference in your approach that depends on the SDLC you choose.  This choice is one you will probably be asked to make when starting from scratch.  While not entirely the domain of the architect, this decision often seems to be driven by them. Agile vs Waterfall - Different Mindsets The most significant impact this decision will have is the one on your mindset.  A waterfall approach front-loads a lot of the architecture decisions.  You can define a relatively static and complete architecture without as much fear of substantial changes.  This includes common concerns like performance, cost, and extensibility. An agile approach is going to change as you go.  That is the nature of this approach to software development.  While you can always go back and re-architect the solution, that is still often a costly way to create your application.  Instead, your architecture needs to be more flexible and extensible than one in a waterfall project.  While you can prioritize performance and a tight architecture with waterfall, Agile demands a priority on flexibility. Architecting Into a Corner One of the most common questions I find myself asking when architecting via Agile is whether something will need to be adaptable or an approach can set in stone.  This is a trade-off we often see in building software.  We can remove system flexibility to improve performance (even to the point of hard-coding values).  However, that can bite us down the road if we suddenly have to support a different requirement. The most common example of this is the desire to store one or more addresses per (client, user, customer, etc.) object.  We can model the address as a part of the main object, or we can have a one-to-many relationship.  If we choose the one-to-one initially, then we can be forced to recode in the front, middle, and back tiers later in the project, if one-to-many is required.  These costly changes are essential to avoid in an Agile environment. A Firm Foundation Is Always Critical While there are different concerns for architecting a solution based on our SDLC choice, there are some excellent first steps in every case.  We will almost always need to maintain, modify, and extend our design.  This requires us to provide a solid foundation for the architecture that avoids too many fragile structures.  The Agile approach may be more unforgiving of bad architectural decisions early on; it seems we will pay the price for those mistakes sooner or later in any case.  

There are no comments yet.

Please log in to write the first comment.