One of the common misperceptions with agile software development is that agilists don't "do architecture." This completely ignores the 11th principle of the Agile Manifesto which states that the best architectures evolve over time. More importantly, when you observe agile teams in action, you find that the majority of them do some initial architecture modeling at the beginning of the project. But, perhaps because agilists are not creating detailed architectural specifications as the result of a "big design up front" (BDUF) approach, many people think that we're not doing architecture. Nothing can be further from the truth, and in this article I overview an agile best practice called "architecture envisioning" which enables you to gain the value from modeling without the cost of needless documentation.
Agile Model Driven Development (AMDD) explicitly includes an initial requirements and architectural modeling effort during Iteration 0 of an agile project (see Figure 1). [i] Iteration 0 has various names, for example Eclipse Way calls this the Warm-Up phase and Open Unified Process (OpenUP) calls it the Inception phase. The basic concept is that this is the period of the project where you try to get the project off on the right foot. Your goal is to understand the scope of the effort and to identify a plausible technical strategy. The information garnered from these efforts will help you to do initial high-level estimating and scheduling, which in turn enables you to gain funding and support for your project. Before you say that Agilists don't work this way, note that the DDJ 2007 Agile adoption survey found that 77% of agile were doing initial high-level agile architecture modeling, and that 88% of those teams found the effort worthwhile. [ii]
Figure 1 also shows that you model, on a just in time (JIT) basis, throughout construction iterations. At the beginning of each iteration you'll do some modeling as part of your iteration planning efforts where you determine what you're going to do and how you think you're going to do it. You'll also "model storm" regularly. A model storming session is an impromptu event where you model with one or more people to explore a feature or to think through the high-level design strategy to implement a feature. Most agile teams will specify the requirements and design detail via a test-driven design (TDD) approach in the form of tests, which in effect are executable specifications.
With architectural envisioning you perform some high-level architectural modeling early in the project to help foster agreement regarding your technical strategy within the team and with critical stakeholders. The goal at this point is to identify an architectural strategy, not write mounds of documentation, enabling you to do this swiftly. The secret is to keep things simple. You don't need to model a lot of detail, you simply need to model enough. If you're writing use cases this may mean that point-form notes are good enough. If you're domain modeling a whiteboard sketch or collection of CRC cards is likely good enough. For your technical architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough. I cannot say this enough: your goal is to build a shared understanding, it isn't to write detailed documentation.
What Models Should You Create?
When you're initially envisioning the architecture you'll typically focus on a few high-level free-form diagrams which overview how you think you'll build the system. When envisioning the architecture for a business application, you should consider creating:
- A technology diagram . Often some form of technology