At the inaugural O’Reilly Software Architecture conference, Molly Dishman and Martin Fowler discussed the role of architecture within agile software development. Key takeaways included; architects must remain ‘hands on’; architecture should focus on reducing irreversibility; adaptable documentation is essential in order to ensure clear communication of the architecture; exemplars of related good code and architecture should be shared when defining stories; and architecture is a collaborative effort across the business, and throughout the entire technical team.
Dishman, senior consultant at Thoughtworks, began the keynote by stating that agile principles and practices, as introduced by the agile manifesto, have now been used within the software development industry for quite some time. However, these practices tend to focus on the team space, for example, creating user stories, daily team standups and pair programming. It is essential that architecture is not forgotten in this context, but not everyone can agree what ‘architecture’ is.
[Dictionary definition of] architecture: The conceptual structure and logical organisation of a computer or computer-based system.
Fowler, chief scientist at Thoughtworks, stated that he often finds the word ‘architecture’ troubling, and has actively avoided using this word when writing. Instead, Fowler prefers to talk about ‘design’:
People with the word architect in their title often seem very divorced from the realities of software development on a day-to-day basis...
Dishman suggested that architects should not be removed from the actual process of coding software. Architecture should be about identifying things that are hard to change, for example, things will be expensive to change in the future in terms of money or effort. Fowler clarified that architecture is essentially the ‘important stuff’ within a software system, whatever that happens to be, but there is often a strong correlation between importance and things that are hard to change.
Fowler stated that the core driver of complexity within software is often irreversibility. As a metaphor to software development, traditional manufacturing focuses on managing complexity by reducing the number of possible states within system, whereas lean manufacturing attempts to reduce complexity by removing irreversibility. Software architects should embrace this core concept of lean.
People are adopting change and making that the norm, such as environment provisioning and infrastructure as a service. These are all things that 10 years ago or 15 years ago would have been on the list as hard to change.
Examining the agile manifesto, Dishman suggested that favouring ‘working software over comprehensive documentation’ has often been interpreted as ‘create no documentation’. Architecture in the traditional sense of waterfall projects often created documentation as an output of the process. Although agile teams may be tempted to abandon this, it is often the case that just enough documentation and diagrams of the architecture within an agile project is vital. However, within an agile project the architecture diagrams cannot simply be created and handed to the development team - it must be a collaborative process:
If you are a team lead working with architecture, you must be doing some coding.
In regards to the agile manifesto’s preference for ‘responding to change over following a plan’ this has also been interpreted as ‘there is no need for a plan’, and accordingly there is no need for architecture within a software system. Fowler cautioned that this is often not true - architectural plans are required, but they must be adaptable and changeable. Within an agile project, the role of architecture can be analogous to city planning. Things are changing all of the time, but plans must be applied to maintain coherence across this process. In this respect, architecture is not necessarily about diagrams, but should be focused on communication of design.
Dishman discussed that during project inceptions, the key stakeholders gather, but often there is no architectural representation. This may be because business stakeholders don’t perceive the value of architecture. However, Dishman suggested that we need to be talking about things that are hard to change early in the project, when we know the least. An agile team should be focused on how can things can be made irreversible, up until the ‘last responsible moment’.
[Architects should identify] where are the things that are hard to change? And how can we make them easier to change?
As part of a project inception user stories can be created that contain spikes to explore the things that may hard to change. Dishman also cautioned that throughout the project, the team may be dealing with architectural changes even if a user story isn’t explicitly focused on architecture. Time must be provided for the team to assess and deal with this. Fowler suggested that code and architecture exemplars are important. When the team plans work for the upcoming iteration, related good code examples should be highlighted. These exemplars can then reinforce and become drivers of good architecture.
People when writing code, they often look to examples currently in the codebase, and use them as inspiration for how to do things. What you want to do is make sure that the really good bits are highlighted and people copy those.
Dishman highlighted the benefits of showcases, both from a functionality and technical perspective. It is important to communicate to stakeholders that architectural and technical thinking is evident, and to demonstrate that how the team is implementing the code is just as important as to how the business problems are being solved.
Fowler strongly recommended that an architect spends time working with the application codebase. One example of this is to ensure time is booked into the architect’s schedule for examining code commits. Some level of triage should be applied to this process, for example, if a developer is working on an area of the codebase that they don’t know well, or is implementing an architecturally challenging part of the application. If the architect is not fully happy with the implementation, they can spend time working alongside and pair programming with the developer.
One of the things that always amused me about the traditional waterfall style, is that when the architect or designer came up with a grand design, no one ever asked them if the code written actually matched the design.
Dishman began summarising the keynote by stating that architecture is a two-way street, between business and development. Business analysts and project managers should always be talking to the development team about changes, and exploring what the impact will be. Development teams must become comfortable with reporting the architectural status, and asking for permission and time for changing the architecture to remove technical debt or support future enhancement.
Dishman and Fowler concluded the talk by stating that much progress has been made at reducing the irreversibility of technical decisions, but this does not remove the need to communicate the architecture and architectural drivers. The most important resource for the development team is often time, and time must be given to the architects and technical leads to think, communicate and implement a good architecture throughout the team.
Like so many things in software, getting a good architecture for your system is primarily a people problem.
Additional details of Molly Dishman and Martin Fowler’s “Agile Architecture” keynote at the inaugural O’Reilly Software Architecture Conference can be found at the conference website, and the video recording for the talk can be found on Youtube.
