My desire to produce excellent architecture is what started my pursuit of excellence in requirements management. As difficult as it is to produce good software systems using any methodology, it is impossible if the requirements are not communicated and/or managed properly. I thought use cases would be an appropriate solution… until I used them on several projects that did not yield the ROI I had expected. Yet we were so close. On one use case driven project the system was so complex that the use cases had 10+ scenarios each dependent on the execution of multiple business rules. The team started developing the use cases but found that it was not possible to develop all the use case scenarios in one iteration so they divided up the scenarios across multiple iterations. They used spreadsheets to help keep track of what was done and what was not done. Problems arose though when test plans based on use case completion could not be executed and project tracking based on use case completion showed no progress. If only they could have been persuaded to use the spreadsheet too! That story did not have a happy ending, but on my next assignment I had the opportunity to see scrum in action – and the light went on – BIG TIME. I am now a user story and scrum fanatic. But how does architecture fit into the agile scheme of things? My first scrum team wanted nothing to do with architectural planning, analysis and design even if just on a whiteboard.
Last summer, I took scrum master training from Peter Borsella of Winnow Management. At the end of the course, I asked him to recommend some books that could read help with my transition from RUP to scrum. He recommended Agile Software Requirements by Dean Leffingwell and User Stories Applied by Mike Cohn. Both books are quite good but I found Dean Leffingwell’s book to be extremely helpful given that he also wrote Managing Software Requirements: A Unified Approach and Managing Software Requirements: A Use Case Approach. Both of these books were fundamental in my understanding and practice of requirements management in the RUP. He was also the co-founder of Requisite Inc., the makers of RequisitePro that is a requirements management tool that I used for several years to manage requirements for large-scale projects. So I was not at all surprised to find tucked into the final chapters of his book on agile requirements management, some pretty intense discussions on agile architecture. The interdependency and interconnectedness of detailed requirements and architecture is the foundation of the RUP.
In Part IV, the section on Portfolio management, chapter 20 is titled – Agile Architecture. I was thrilled. On page 385 he asks, “Does all architecture emerge in agile?” and proceeds to answer that at the level of teams and programs that yes indeed it does but relying on solely emergent architecture for the portfolio (enterprise) level was counter to his experience. In my experience, relying solely on emergent architecture for the program level doesn’t work either. But, I’ll get into that in a future article. Right now I would like to discuss the eight principles of agile architecture.
1. The teams that code the system design the system. Development teams are staffed with architects who are active participants in architectural governance and are completely responsible for sub-system design. The team needs to have at least one member that scores high in Optimize Technical Architecture and Optimize Application Architecture in addition to Optimize Implementation.
2. Build the simplest architecture that can possibly work. Use the simplest design that supports the current features. This does not mean the simplest design for the current sprint. Considerations need to be made for near-term features as well. See principle #5
3. When in doubt, code it or model it out. When making hard design decisions the iterative nature of the agile life-cycle can be used to explore alternatives with actual code in a single iteration (or two) using design spikes (a type of backlog item) to manage the work. A model may be used alternatively if the problem is too big to code.
4) They build it, they test it. “It is the responsibility of the development teams themselves to develop, test, and maintain a system-testing framework that continually assesses the system’s ability to meet its functional and non-functional requirements.”
5) The bigger the system, the longer the runway. The runway is the system architecture that supports the current and near-term features of a product. The Lifecycle Architecture Milestone! Smaller projects might skip the Elaboration phase altogether but larger projects need to plan out and test the runway because “an agile team’s ability to meet value delivery commitments is far more reliable when the foundation for the new features is already in place.”
6) System architecture is a role collaboration. Related to principle #1, system architects (architectural governance) work with team-based tech leads and architects to define design spikes they will use to collaboratively develop an agreed-to system architecture.
7) There is no monopoly on innovation. “You do not have to be an architect to make a big contribution to design” Innovation may be encouraged by planning sprints with the sole purpose of reflecting on the current solution and how to make it better.
8) Implement architectural flow. This is the Agile Release Train which is the management of architectural epics is discussed in detail in Chapter 21.