Agile development is more than a buzzword. It has given rise to popular methodologies like Scrum & XP. The Agile Manifesto [1], sums it up nicely:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Items on the left are valued more in agile development. It embraces changing requirements & its primary measure of success is working software. Simplicity is at the core of agile development. One might argue that there’s nothing simple about Test Driven Development (TDD) & refactoring, but if you look closely TDD is about developing a feature in small steps, by first writing one test at a time and refactoring is about restructuring code in small steps. So, continuing on the same theme, it is no surprise that it also advocates simple design, which effectively means that striving for the simplest design/architecture that works. This is also known as the YAGNI (You Aren’t Going to Need It) principle [2], which discourages putting the architecture in place for future functionality.
The Myth Surrounding Architecture in Agile Projects
As highlighted in the previous section, simplicity is valued in all agile methodologies. On the other hand you have architecture, which is perceived as complex & heavyweight. This traditional view is known as ivory tower architectures [3]. So, there’s no surprise that architecture takes little recognition in agile projects & often completely ignored.
One of the most common myths with regard to agile development is that upfront architecture or design is bad. The problem comes from how people perceive ‘architecture’. They still seem to have the traditional view of architecture (when Waterfall approach was prevalent), where it was time consuming & difficult to get right & also done by a single experienced person in an authoritative manner.
Architecture was time consuming simply because of communication delays with the concerned stakeholders (in other words, poor stakeholder engagement) & it was error prone because we were concentrating on getting all the requirements nailed down upfront. This was a recipe for disaster because at the beginning of the project, requirements are not evolved enough for us to make concrete decisions. This leads to costly rework in development & worse, features that are not being used by the customer.
Agile methodologies evolved from the fact that requirements are always changing & consequently in each iteration (a mini development cycle) we develop the software product which reflects the requirements at that point. Therefore, the weight of ‘architecture’ appeared to hamper the ‘agility’. Also, agile methodology discourages Big Design Up Front (BDUF). There is no doubt that BDUF is harmful & a waste of time, but that doesn’t mean there aren’t any architectural issues & design decisions we can make early. In fact, agile principles (stake holder involvement, self organizing teams, no single architect – every stake holder plays some part in it, etc.) make architecture lightweight.
Towards Agile Architecture
We need to look at architecture in a different light. We need to make it lean. Traditionally architects who were responsible for architecture were mostly disconnected with other stakeholders & developers didn’t have any say in it, so there were little or no ownership of code. The lean secret – “Everybody, altogether, early on” [4], helps in one aspect. It suggests everybody has some part to play in architecture & all the parties are involved from early on.
Agile practices frowns upon Big Design Up Front (BDUF), but most developers make this an excuse to skip design completely. Therefore, architecture, which is part of design, is ignored. However, there are architectural issues that can be resolved upfront & design decisions that can be made early [5]. Some agile projects have an iteration zero [6] for up-front design work. In fact XP (Extreme Programming) advocates initial up-front design.
Fairbanks [6] suggests that architecture is (Mostly) orthogonal to functionality, which means that it is the most stable part of a software system compared to frequently changing functionality. Coplien [4] has a similar idea when he suggests the separation between system form (what the system is) & system functionality (what the system does).
So, to wrap up: Architecture is important in Agile projects. A little 'lightweight' investment upfront on architecture will go a long way in the Sprints that follow.
References
· [1] Kent Beck, Martin Fowler, et al. Manifesto for Agile Software Development. [Online]. Available: http://agilemanifesto.org/
· [2] Robert C. Martin, Agile Software Development, Principles, Patterns, and Practices, 1st. ed., Prentice Hall, 2002.
· [3] Scott W. Ambler. (2011.). The Agile Architecture: Strategies for Scaling Agile Development.[Online].Available: http://www.agilemodeling.com/essays/agileArchitecture.htm
· [4] James Coplien and Gertrud Bjornvig, Lean Architecture for Agile Development, 1st. ed., John Wiley & Sons Ltd., 2010.
· [5] Robert C. Martin. (2009, April.). The Scatology of Agile Architecture. [Online]. Available: http://blog.objectmentor.com/articles/2009/04/25/the-scatology-of-agile-architecture.
· [6] George H. Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach, 1st. ed., Marshall & Brainerd, 2010.
