Michael Waterman

Please Note

This person can no longer be contacted through the School of Engineering and Computer Science at Victoria University of Wellington

Website:

http://agile.cribbwaterman.net

How much architecture?

Plan-driven software development methodologies are those such as the traditional “waterfall model”. These methodologies are known as “big up-front design” methodologies because the software design is completed before implementation starts – and thus they require a full understanding of the customer's requirements and specifications before implementation can commence.

Unfortunately the big up-front design does not suit a large number of software projects (particularly business applications), in which specifications are not – indeed cannot be – entirely understood prior to development.

To deal with this shortcoming, agile methodologies closely involve the customer throughout the process, with the specifications being developed simultaneously with the product. The advantages of agile are “increased customer satisfaction, lower defect rates, faster development times, and a solution to rapidly changing requirements” (1).

Agile methods are driven by customer value; architectural activities have little or no customer value and so are given little attention (2).

The necessity of architecture in agile

Architecture can be viewed as a collection of design decisions describing the system’s components, their responsibilities and interactions (3) – elements that are difficult to change (4).

In agile methodologies, these design decisions are identified on a just-in-time basis during an iterative development process (5).

However even agile-based projects need some explicit architecture. Not only does the lack of architecture leave the project exposed to the risk of missing milestones, exceeding budget constraints and project failure but also leaves the project bereft of other benefits of architecture such as accountability of technical decisions and design checks and balances (6).

Taken to its extreme, minimal or non-existent architecture results in a purely evolutionary design that “ends up being the aggregation of a bunch of ad-hoc tactical decisions” (4). This increases the risk of the development becoming directionless (degrading into hacking (5)), particularly with changing requirements, and can lead to incorrect architectural choices relating to key design parameters such as technology, interfaces and patterns (3).

Reconciling architecture and agility

This proposed research will attempt to determine the appropriate level of architecture design when using agile methods.

It will use a grounded theory methodology using a multiple case study strategy. Each case study will involve interviewing a number of agile architects and planners, and studying documentation to determine the degree and style of architecture used. The analysis of the gathered data will attempt to extract theory on the most appropriate level of architecture that will enable agile development to minimise risk and maximise the effectiveness of the method.

References

(1) B. Boehm and R. Turner, “Balancing agility and discipline: Evaluating and integrating agile and plan-driven methods”, International Conference on Software Engineering, pp. 718–719, 2004.

(2) P. Kruchten, “Agility and architecture: an oxymoron?”, SAC 21 Workshop: Software Architecture Challenges in the 21st Century, June 2009.

(3) A. Johnston, The role of the agile architect”, 2003.

(4) M. Fowler, “Is design dead?”, 2004.

(5) S. W. Ambler, “Agile architecture: Strategies for scaling agile development”.

(6) G. Booch, “The defenestration of superfluous architecture accoutrements”, SAC 21 Workshop: Software Architecture Challenges in the 21st Century, June 2009.

Awards

This research is funded by a Victoria University PhD scholarship.