By Scott Ambler
(Editor’s Note: Part II will follow later this week.)
Architecture, whether you care to admit it or not, is an important aspect of any software development method. At one end of the methodology spectrum architecture is captured as an explicit phase, such as with serial/traditional lifecycles, and at the other end architecture is left up to you to weave into the method, such as in Scrum. Between those two extremes architecture strategies are woven right into the method, such as with Disciplined Agile (DA). How architectural thinking and practices are woven into agile software development is the focus of this two-part series.
Look Beyond Scrum
Many software architects are confused about how architecture strategies fit into agile software development, the primary source of this confusion being the rhetoric around Scrum. This likely sounds strange given how many organizations claim to be following Scrum, but the fact is that Scrum is a very small part of the overall picture. Scrum purposefully does not address technical practices around architecture, design, testing, and so on.
In Scrum you’re expected to tailor in fit-for-purpose techniques to address these aspects, and to do that you need to look for other sources of information. In the case of agile architecture strategies, that source would be the Agile Modeling method. While it is possible for your team to weave architecture strategies into Scrum, it proves to be a lot of work in practice and as we’ve seen it’s hard to get right. This is work that was successfully done in DA by focusing on both the mindset that enables agile architecture and the practices required to execute on that mindset.
The Agile Architecture Mindset
Agilists like to say that agile is a way of thinking, a mindset. The goal is to “be agile.” This is a great starting point, and the focus of this article, but you also need to know how to “do agile” too, the focus of the second article in this series. Here are the philosophies that define a mindset for agile architecture:
- Collaborate closely with stakeholders. Effective architecture addresses both the short and long-term needs of its stakeholders, and those stakeholders have a wide range of backgrounds and interests. Agile architects work closely with stakeholders to understand their needs, which evolve over time, to ensure that the architecture evolves in kind.
- Take an evolutionary approach. Agile architecture, like other modeling and planning efforts, is evolutionary (iterative and incremental) in nature. Disciplined agilists will invest some time up front to identify a high-level architectural vision to provide direction to the team. Then they will collaboratively evolve the architecture over time to reflect new learnings and changes in priority.
- Be humble. Effective architects, and professionals in general, have the humility to realize that they don’t have all of the answers. This is why collaboration with others is critical – you need to work with others closely so as to leverage their knowledge and expertise.
- Follow a fit-for-purpose approach. Tailor your way of working (WoW) to reflect your situation. The way that you approach architecting a web site is very different than the way you would approach architecting the operating system for a car. Similarly, your approach to working with a co-located team varies from working with a globally distributed team, or working with a 10-person team rather than a 500-person program. Context counts.
- Embrace change. The environment within which your organization operates evolves constantly. The technologies you work with evolve. The priorities of your stakeholders evolve. Your stakeholder’s understanding of what they want evolves. Change is constant, and it isn’t sufficient to merely accept this fact, you need to embrace it and adopt WoW that is fluid in nature.
- Model just enough. A fundamental agile concept is that artifacts, such as models and documents, should be sufficient in that they are just barely good enough (JBGE)for the context in which they are used. If they are not sufficient then you should invest more effort to make them so. Once they are sufficient then any more work in them is a waste. The implication is that you want to model just enough to explore an idea, or to think through something, and no more. Sufficiency is determined by the complexity that you face (harder problems required more modeling than simpler problems), the skills of the people involved (the more skilled you are, the less modeling you’ll need to do), and the availability of stakeholders (the more available people are to answer questions, the less modeling you need to do now).
- Model just in time (JIT). The rate of change that you face and the desire to model sufficiently motivate you to model in a JIT manner. When you perform significant modeling up front, as traditional methodologies implore you to do, much of that effort is wasted because you need to evolve your work later in the life cycle to reflect the new situation that you face. Lean advises you to leave modeling activities to the last most responsible moment so that you’re acting on the best, most up-to-date information available to you.
- Capture concepts visually. Modeling enables you to think things through, to collaboratively come to a shared understanding. Unfortunately, in the software world we’ve learned the hard way that models are unlikely to be kept up to date, and more so the more detailed that they are. This is why the Agile Modeling method recommends to high-level concepts should be captured visually via overview diagrams that are supported by concise descriptions. Such models are more likely to be used in practice to provide overviews and are more likely to be maintained over time because they are sparse.
- Capture details using tests. Detailed specifications should be captured as executable tests whenever possible. This way the tests perform double duty, they both specify and validate. They also provide free traceability from specification to code to test. Executable specifications are far more likely to be kept up to date by developers than static specifications (documents) because they provide real value to the developers because they are regression tests. The primary downside of this strategy is not everyone has the skill required to write effective tests.
Mindset is a great start. In the agile world we like to say that it’s all about “being agile.” But that’s only part of the overall picture, you also need the skills to “do agile.” In the second article of this two-part series, we’ll look at common agile architecture practices for agile software teams.