Can architects play a meaningful role in agile projects, or does their tendency to do “big design up front” make them a sideline resource? Nick Malik, an Enterprise Architect with Microsoft, recently explored this topic in a blog post and concluded that architects can absolutely play a key role in software projects that use Scrum.
Malik’s blog post was inspired by a project where he attempted to affix architecture practices to a Scrum process. His post began by immediately claiming that software architecture is not at odds with agile development processes. However, given the short delivery cycles associated with Scrum, Malik concedes that the traditional architecture practice of taking months to document and diagram a system is “pretty silly.” But any software project – including one delivered via Scrum development processes – has a fundamental software architecture that must be acknowledged.
The value of software architecture is that key decisions are made about the core infrastructure of the system itself: where will generalizations lie? Will a layered paradigm be used, and if so, what are the responsibilities of each layer? What modules will exist in each layer and why will they be created? How will the responsibilities of the system be divided up among the layers and components? How will the modules be deployed at scale? How will information flow among the modules and between the system and those around it?
The way these questions are answered will indicate what the architecture of the system is.
According to Malik, each of these choices is made by carefully balancing a set of system quality demands. These demands come into play as software architects work within the three different layers of software accountability.
The topmost layer, labeled Aligning Processes, occurs quarterly or semi-annually and addresses the organization-wide information and business strategy. The output of this layer is the “to be” software models for the organization. The second layer includes the Balancing Processes and is associated with a given software project and likely occurs alongside development of the first few Scrum sprints. Malik explains that this is where the logical system architecture is crafted.
These processes consider the needs of a single system but only from the level of deciding why the software will be divided up into modules, layers, and components, how that division of responsibility will occur, and what the resulting system will look like when deployed in specific technologies in a specific environment.
Finally, the bottom layer of this model is where Realization Processes reside. According to Malik, here is “where the architecture becomes software” and architects make the specific design decisions that the software developers use when building the system. Malik admits that developers may not adopt the design patterns chosen by the architect, although “the team will very likely implement the software architecture as described, but may choose to improve upon it.”
So how does this work in practice for a given Scrum software development process? Malik added a step immediately before the sprint planning session. Instead of proceeding from the prioritized product backlog directly to the sprint planning session and subsequent software sprint, teams should inject a “pre-sprint story review” where stories can be improved and architecturally assessed.
Malik suggests executing this new architecture-focused step one week before the sprint planning session.
In that week prior to sprint planning, those folks, working with the product owner, can improve the stories, add constraints, refine the description and acceptance criteria. And here’s where the architects get to play. Architects fulfilling the role of “Balancing” in the model above will have (or can create) an outline document describing the architecture of the software system, and can “link” that document to the SPECIFIC STORIES that are impacted by that design.
Malik concludes that an architect is a “chicken” or “pig” in an agile project based on which layer of architecture is being addressed. The architect is an involved member of the team when crafting the first two layers, and an invested participant when working in the third layer. This exercise by Malik continues his investigation into the role of “architecture” in agile practices. In a blog post earlier this year, Malik proposed that Enterprise Architects are inherently agile and that their focus on completing high value activities through incremental progress is directly in sync with the spirit of agile. The intersection of agile and architecture continues to be an area of great interest as the industry tries to improve the efficiency of software development while not incurring architectural debt.
