James Coplien and Kevlin Henney gave a talk at QCON London 2007 addressing the myth that architecture can’t be agile. It is heavy weight and the magic of Agile makes it unnecessary to bother with up front design.
They define a good architecture as something you can do upfront that is light weight that helps you understand the significance of the decisions that you are going to make. It allows you to look at the system make judgments about what things you can differ and what things you should not differ. To be agile you must be fit. You must be standing on a firm foundation. Agile is about understanding what changes we can ignore. You cannot defer all important decisions. Later you will have a lot in place that you can’t do anything about it. A lot of things have to be pushed upfront. Understand the repercussions of a given decision. See the big picture, make a shared vision across the team and use it as a tentative foundation. Describe the things that really matter. Make the critical design decisions. Architecture is not something that lives in a document. It is not a blueprint. The design document is in the code. Architecture is a shared vision that builds on the knowledge of your people. It is about understanding the thing we need to build and how we will build it. It provides a foundation for team structure, a foundation for the GUI and reflects the system architecture.
According to the Oxford dictionary, the some definitions of agile include quick motion, nimble, active, or ready.
They discuss prioritizing and mention that you do not want everything to become significant. We need to know what to care about to reduce the significance of other decisions. Making hard decisions early makes easy decisions easier. Doing the easy ones 1st constrains you and makes the hard ones even harder.
Then they address big upfront design (BUFD), no upfront design (NUFD), and rough upfront design (RUFD) and suggest that there is tension between the levels of detail and a balance is required. The right amount of design depends on the size of the domain and the recommend 1 or 2 weeks. If using Scrum, then have a single Sprint that delivers the architecture as abstract classes.
They wrap up by illustrating what happens if you start immediately without any design and how if you don’t pay now you will end up paying a lot later. They stress on trying to figure out what is critical and what is not critical and spending time on the critical upfront.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
