By Scott Ambler, Consulting Methodologist, Ambysoft Inc.
Since the Agile Manifesto was published over two decades ago there has been significant confusion over the role of architects and architecture in agile software development. This is due in part to the initial focus on programming in the early days of agile and in part due to the purposeful lack of focus on technical practices in the Scrum methodology. For most agile practitioners the two extremes never met in the middle and for them the advice around agile architecture was lost in the noise. Luckily this was not the case with the Agile Modeling method, the focus of which is on effective strategies for modeling and documentation on agile software teams.
Previously I wrote about how much modeling you should do, a two-part series that explored what it means for an artifact to be just barely good enough (JBGE). You can read more about this in How Much Architecture Modeling Should You Do? Just Enough Part 1 and How Much Architecture Modeling Should You Do? The Factors That Determine Sufficiency Part 2. In this article we explore how to approach initial requirements and architecture modeling at the beginning of a software development initiative.
Initial Modeling and Agile? Really?
Talk to most agilists, and particularly the purists, and they’ll claim that they don’t do any modeling up front. This of course is completely false, they just use different terminology such as “populate the backlog” rather than initial requirements modeling and “identify a runway” instead of initial architecture modeling. Sigh. Some of the more fervent agilists may even tell you about the evils of big modeling up front which is why they choose to eschew anything that smells like up-front thinking. The fact is that agile teams still need to be initiated in some way, and that includes a little bit of up-front thinking.
Figure 1 depicts the key relationships between major concepts that need to be addressed early in the lifecycle. You see that your initial requirements model drives your architecture and plan. Your architecture in turn constrains your requirements as does your plan – it may not be possible to deliver on some proposed requirements or at least not economically viable to do so. Architectural decisions drives, or at least identifies, some of your risks which also drives your planning efforts. Your plan and architecture will drive teaming choices, which in turn constrain both. The point is that your initial modeling efforts need to proceed in a flexible and evolutionary manner if you are to successfully initiate your project team.
Figure 1. Relationships between major concepts during project initiation.
Initial Requirements Modeling
The goal of initial requirements modeling on an agile team is to sufficiently explore the scope of what they are expected to accomplish. Sufficiency is determined by your stakeholders – can you exhibit an understanding of their problem and produce a reasonable, high-level strategy for proceeding? Your initial requirements model should be JBGE to accomplish that because the details will be explored on a just-in-time (JIT) manner at the last-most responsible moment. Regardless of when you model, with an agile approach you should work in a highly collaborative, evolutionary, and inclusive manner.
The requirements artifacts that you capture depend on the context of the situation that you face. Although there is a lot of prescriptive advice about agile requirements artifacts, particularly around user stories, the fact is that you have choices in what types of requirements you explore and how you capture them. To enable this flexibility, I like to think of agile requirements in terms of three categories:
- Usage requirements. The aim is to understand how people will use your solution to gain benefit for themselves or for the people whom they help. Potential usage requirement artifacts include use cases, usage scenarios, user stories, and question stories. Usage requirements should be the primary “functional requirement” artifact(s) for your team.
- Quality of service (QoS) requirements. QoS requirements are known as non-functional requirements (NFRs) or technical requirements. A QoS requirement may address an issue around security, accuracy, performance, usability, scalability or many other “non-functional” concerns. QoS requirements tend to drive key aspects of your architecture and your test strategy/plan.
- Constraints. Constraints are arguably a type of QoS requirement, but I believe in explicitly calling them out. For our purposes, constraints focus on issues such as the need to follow internal guidance (architecture conventions, coding guidelines, …) or regulatory compliance.
My experience is that you want to address each of these three categories in some way. How you do so depends on your context – one approach does not fit all situations.
Initial Architecture Modeling
The goal of initial architecture modeling on an agile team is to identify what the team believes to be a viable strategy for building the solution. Sufficiency is determined by your stakeholders – Can you exhibit an understanding of the existing environment, and the future direction of your organization, and show how your proposed strategy reflects that? Your initial architecture model should be JBGE in that it addresses, at a high-level, the business and technical landscapes that your solution will operate within. This modeling effort is often led, not dictated, by the architecture owner (the agile architect) on your team.
I like to think of agile architecture models in terms of four views:
- Business process. Sometimes called a dynamic model, the goal is to capture the business process supported by your solution. Good options to do this include business process models, capability maps, or event models.
- Data. Sometimes called a static view, this is typically captured using a conceptual model to depict major data entities and their relationships.
- Technology. This model captures a mapping of software components to the hardware components that make up your solution. Good options include a free-form technology diagram or UML deployment model.
- Context. This model summarizes how your solution integrates into, or operates with, other systems in your environment.
As with agile requirements, you want to address each of these views in some way. You may prefer to adopt the views called out by architecture frameworks such as TOGAF or Zachman. Regardless of which collection of views you adopt, the key strategy is to take a multi-view approach that reflects the context that you face.
In Summary
Agile software teams, at least the disciplined ones, explicitly invest time at the beginning of a software development initiative to develop initial requirements and architecture models. This effort should be collaborative and evolutionary in nature, resulting in just barely good enough (JBGE) models. These models reflect high-level visions, respectively, of what you hope to achieve and how you intend to do so. These visions will evolve and explored in greater detail in a just-in-time (JIT) manner during construction, the topic of my next article.