Wednesday, March 3, 2010

Architecture-Driven Design

Dave Thomas' talk "Lean and Agile in the Large" mentioned Architecture-Driven Design....

Jim Coplien on Scrum Architecture: Jim started by highlighting that use cases describe what a system does and architecture represents what that system is. A common problem on Agile projects is that a lot of teams become unstuck during the third sprint because there is no architecture. After all, architecture is what enables developers to work together. Jim therefore recommended we assert what we know on an architecture in order to provide a high level design, taking no more than three days, made up of abstract base classes and domain dictionaries (two sides of A4 per domain). Jim went on to say that TDD (Test-Driven Development) does not produce (good) architectures. That architectures cannot be derived from unit tests. That we should adopt architecture-driven design instead of unit-test-case-driven design. The session hit the sweet spot as a technical Agile session: suitably thought-provoking or controversial depending on how you interpreted his presentation.

A design that fulfills all functional requirements but fails to meet non-functional ones is not a valid design. Architecture-driven design offers a mature approach to design because it explicitly considers non-functional requirements from the beginning, and not just immediate requirements such as size and performance, but also easy of maintenance, accomodation of projected changes, understandability and so on.