Where does application architecture fit in the Agile/Rad landscape?

The Manifesto for Agile Software Development states:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Lets look at these one at a time.

Individuals and interactions over processes and tools

Developers are human and humans are social animals.   From a process point of view, when we come together as a group to review architecture, I've noticed that it's one of the most interactive parts of the software development process.  The debates are lively and the conversations are usually friendly and robust.  So, having architectural discussions is a great way to stress individual opinion and group interaction.

A primary tool in architecture development is the design pattern.  Design patterns were inspired by Christopher Alexander, the father of the modern pattern language view of architecture.  By establishing and using design patterns, advocates (...) claim that ordinary people of ordinary intelligence can use it to successfully solve very large, complex design problems.  When you use a design pattern, you are applying an architectural solution.

Working software over comprehensive documentation

This one is interesting.  It says you should spend your time writing and creating working software rather than creating comprehensive documentation.  However, it is not an excuse to not create ANY documentation.  Some of the easiest and most useful documentation can be architectural.  So, if you're trying to minimize the time spent on documentation, make an architectural drawing.  Do it quickly, include just what's important to convey your ideas and constraints, then build it in working software.

Better yet, since working software is your goal, build it and document it once, and then reuse it.   Reuse has gotten a bad name in the last decade or so because it's so hard to do it right.  However, with the NuGet packages, extension methods, and test driven development, we are finally in the position to say that if you are not creating the software you deliver by plugging-in, stitching together, and importing templates, components, and binaries from a familiar and trusted supplier (yourself in many cases), then you are costing someone time and money.

RAD originally meant (in 1991) the use of heavy prototyping as an emphasis on developing software (see Martin, et al).    However today it tends to refer to highly component-ized development using frameworks like Rails, VB, Lightswitch, etc.  (Ruby, by the way is not a RAD language, Rails is a RAD framework because of the level of scripting.)

Since our goal is to create working software we need to focus our effort.  In software we often do that by focusing on one responsibility at a time.  In object-oriented programming, this is know as the Single Responsibility Principle and it is a fundamental principle for creating software using the SOLID guidelines.

You can write software without following these principles, but it won't be object-oriented and it won't be as maintainable as it could be.   It's also highly unlikely that it will be easy to change.  In other words - it won't be a form of RAD.   By creating clarity and focus, you create a landscape where you have individuals interacting to create working software over documentation.   Proper architecture helps make that possible.   Take a quick look at the SOLID guidelines and how many of them help guide good structure and style (architecture):

Initial	Stands for (acronym)	Concept
S	SRP	Single responsibility principle the notion that an object should have only a single responsibility.
O	OCP	Open/closed principle the notion that “software entities … should be open for extension, but closed for modification”.
L	LSP	Liskov substitution principle the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract.
I	ISP	Interface segregation principle the notion that “many client specific interfaces are better than one general purpose interface.”[5]
D	DIP	Dependency inversion principle the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”[5] Dependency injection is one method of following this principle.

Customer collaboration over contract negotiation

One of the biggest values that architecture (and experience) bring in this area is that knowing the architecture helps the technical people to estimate better.  Estimation will remain as flexible as feature scope, but the closer the technical people can come to providing the customer with realistic expectations for quality, cost, features, and schedule the better the collaboration with the customer will be.

Responding to change over following a plan

When good architectural principles (layering, components, and design patterns) are applied, then followed with sound software development practices (Lean, Agile, Scrum) and SOLID object-oriented principles are followed, the software stays flexible to change.   That's not to say that some changes won't take a long time, but it does mean that they will take a fraction of the time to change when compared to a product where these practices and principles were not followed.

These thoughts on architecture are continued in my next post about why discussing application structure and style is so hard.