How did we get here? A little History
Architects traditionally worked in a gated environment where they delivered their work through documents that contain the definition of an architecture, or design. These documents are painstakingly reviewed, because errors that slip through this phase are expensive to fix in later phases.
Along with useful statements, review comments may be about the documents conformance to the documentation standards. I have seen a design review delay a project by two weeks because the colour of table surrounds was slightly wrong! Value add here is missing, but the pedants were happy.
In the agile world architects may be team members or they may be working at a programme level. Their main role is collaboration with members of the development teams and other stakeholders. These collaborations in some ways are handoffs between the developers and the architects. But they happen all the time rather than at the review time only.
The product owners and architects operate in a similar way. In fact (in my opinion) an architect is a type of product owner. They get their objectives achieved through technical stories which they prioritise through the backlog in collaboration with the product owner.
The traditional way of design is called BDUF, or big design up front. This is the waterfall or gated approach, as described by Winston W. Royce, but not advised by him. A traditional waterfall based project lifecycle can be viewed as in Figure 1 below.
Figure 1
The stages are laid out end-to-end and pass through review and governance gates before the next phase starts. Fine in theory but not often practiced in its pure sense. Each phase requires a different skill set and therefore different people. Also it assumes there is minimal change to requirements after the requirements gate is achieved. After that point, change is achieved through a change management process, which can be expensive, time-consuming and effectively discourages change.
In theory, the waterfall-based requirements and design stages are completed before any coding is performed. The design is available to the development teams who use it as a starting point. There is no formal feedback loop from coding to design although in practice there are often some updates. Testing is not used to drive design or development – it is a phase that occurs after development although some planning and test specification can occur earlier. The approach is based on silos and the focus is on the handoffs.
There is little feedback between phases in this approach. In some of the more extreme examples the people who performed a stage are gone while the next stage is being performed. This happily is rare in practice, however in some distributed examples they are very difficult to get in touch with and speak a different language. This approach also encouraged the ivory tower for design and architecture.
There are a number of inherent risks and assumptions here, some of which are addressed through a more iterative lifecycle. The risks are based around the length of time it takes to conduct the waterfall cycle and on the need to get it right the first time through. There are also risks associated with making decisions early in an information poor climate. The data needed to inform these decision comes about during the development itself. Late integration is a risk that is inherent in this approach.
Dissatisfaction with the waterfall and indeed other approaches has lead us to the agile way of working. This shortens the cycles and moves design and other concepts from events to continuous activities. We began to recognise the value of ensuring decisions are made at the latest responsible moment. This is when we have as much information as we are going to be able to accumulate. While these stages are well known, RAD/JAD, DSDM, RUP, Rolling Wave and Spiral none specifically addressed design in detail. A design gate was often assumed.
Agile is moving past this. Keep reading to see where this has gone.
Leave a Reply