By Scott Ambler
(Editor’s Note: Part I appeared Monday here.)
In Agile Architecture for Software Development Teams: Being Agile we explored the mindset required to be successful at architecture on agile teams. This mindset is based on the ideas that agile architecture is highly collaborative and evolutionary in nature, that you want to work in a just-in-time (JIT) manner, and that you want to produce artifacts that are sufficient (and no more) for the context that you face. In this article we focus on strategies for “doing agile”, on how to execute effectively.
The Architecture Owner Role
Disciplined agile teams include the role of architecture owner, which in effect is an agile solution architect. An architecture owner is a senior team member with the additional responsibilities of coaching the team in architecture skills and guiding them through architecture decisions. Architecture owners differ from traditional solution architects in that they work very collaboratively with the rest of the team to develop the solution, rather than just dictating the architecture strategy to the team.
Your team’s architecture owner, there should be one architecture owner per team, collaborates closely with other architects within your organization. This includes enterprise architects, program architects (if your team is part of a larger program), and specialized architects such as data architects or security architects. The goal is to ensure that the architecture owner understands the overall organizational direction being evolved by these other architects, leverages any specialized help they can provide, and shares any learnings from the team they are currently part of.
Architecture Throughout the Agile Lifecycle
Figure 1 summarizes a three-phase agile project lifecycle that includes an explicit initiation phase, a construction phase, and a deployment phase. The initiation phase, often called “Sprint 0” or inception, is when initial architecture, scoping, planning, and other activities occur to get the team going in the right direction. Construction is where the team incrementally builds a consumable solution. The deploy phase, which is hopefully a short activity given sufficient automation, is where you release your solution to your customers.
Figure 1. Architecture practices throughout the agile project life cycle.
Agile Architecture Modeling Practices
Agile architecture modeling should occur throughout the entire lifecycle. There are several agile modeling practices that are key to architectural success:
- Inclusive modeling. Agilists work together closely in an iterative and highly collaborative manner in all aspects of their work. When it comes to modeling we want to include our stakeholders as much as possible, so we’ll use simple tools and techniques such as whiteboards and sticky notes. In general, we try to stay away from complex diagrams when working with our stakeholders. As architects we often think abstractly and lean towards visual thinking, but this may not be true of our stakeholders. Similarly, we are likely very familiar with modeling notations such as those of the UML, whereas our stakeholders often struggle to understand these notations due to lack of familiarity. In short, know your audience.
- Active stakeholder participation. The people who are best suited to model what they want are the stakeholders themselves. Similarly, the people who are best suited to model how something will be built are the people who are going to build it. The implication is that when you are requirements modeling you want to work closely with stakeholders and when you’re architectural modeling you want to work closely with developers.
- Initial requirements modeling. Early in an initiative you will work collaboratively with business stakeholders with the goal of gaining a high-level understanding of the requirements as input into your architecture, planning, and construction efforts. Note that these requirements will evolve over time as your initiative progresses, hence the need for flexibility.
- Initial architecture modeling. In parallel to initial requirements modeling, you should also do just enough modeling to gain a high-level vision of a potential architecture for your solution. Note the use of the word potential – until you’ve proven that your architecture strategy is viable, more on this below, it is merely a good guess. The goal is to do enough architectural thinking early in the initiative to get going in the right direction and thereby address major technical risks, but to allow the details to evolve over time.
- Just in time (JIT) model storming. Lean advises us to make decisions at the last most responsible moment. This is because the situation will change over time, with your stakeholder’s understanding of their requirements evolving over time and your understanding of the solution similarly evolving. The later you wait to make a decision the better the information you have to go into that decision. The implication is that you want to perform targeted architecture and design modeling on a JIT basis when you need to think through the details of a specific aspect of your overall strategy, and thereby make the best decision that you can at the last most responsible moment.
Agile Architecture Development Practices
In addition to agile modeling practices, there are several development practices that are critical to architectural success on your agile team:
- Proof of concept (PoC). A PoC is a technical experiment, sometimes a project in its own right, to determine when a key technology is appropriate for your environment. PoCs are typically one or more weeks of effort, sometimes taking months depending on the complexity of the technology being explored and your organizational culture. Agile PoCs are very similar to traditional PoCs, although they are more likely to be executed in a pragmatic and collaborative manner.
- Spikes. Spikes, sometimes called architecture spikes or technical spikes, are small experiments used to explore a technical issue. Spikes are often a few hours, or a day or two at most, of quick prototype coding to discover whether something works in your environment. For example, you might write spike code to determine if a database technology includes critical features that you need or if new features of an updated release to a technical component work better than the features you’re currently using. Spikes are effectively small PoCs, originally introduced by the Extreme Programming (XP) method, that are used to address a technical risk faced by your team.
- Prove it with code. Early in construction, as early as possible in fact, we want to prove that our architecture strategy actually works in practice – or discover where it doesn’t work so that we can iterate and fix it. We do this by implementing the highest priority requirements that also stress critical aspects of our architecture. The implication is that your architecture owner needs to negotiate with your product owner to reprioritze those architecturally critical requirements. Once these requirements are successfully implemented you’ve effectively proven that your architecture works, with executable code rather than the wishful thinking represented by models. This is a fundamental software engineering strategy that was popularized by the Rational Unified Process (RUP) in the 1990s to reduce technical risk on a software initiative.
- Executable examples. Few people like to read whitepapers, even the incredibly interesting architecture whitepapers that you’ve written. Developers, in particular, tend to prefer working code over detailed documentation. The implication is that if you want developers to follow common architecture conventions then you are best advised to produce working code that provides examples of those conventions so that developers can work with, and likely copy into their own code.
- Test driven development (TDD). In the previous article we learned that visual models are effective at capturing and communicating high-level details, but that executable tests are best suited to capture detailed specifications. When a test-driven approach is taken, which means that tests are written before code or schema is written, they serve as both a validation mechanism (regression tests) as well as executable specifications.
There are many opportunities to include architectural activities in your agile software development process. Architecture is so important to agile teams that we address it all the way through the lifecycle, it isn’t just a phase that we work through at the beginning of a project. In future articles I will explore the practices that I’ve summarized here in greater detail.