Notes by Ian De Silva
The Conflict Between Agile and Architecture: Myth or Reality?
Simon Brown, Coding the Architecture
Agile is about working in small increments, getting feedback, and improving the process or product. Architecture is about structure and vision. There is no conflict between agile and architecture because every software project has an architecture. There is, however, a conflict in the approach and team structure.
The agile approach is about moving fast, while typical architecture approaches are about understanding everything before moving forward. The “responding to change over following a plan” aspect of the Agile Manifesto is often misinterpreted. This does not mean you don’t do up-front design. Even test-driven development (TDD) needs a context. Architecture provides this context. A large architecture document does not establish the shared vision. Without a structure, we end up with spaghetti code.
“Every development team needs a master builder”—someone who has both depth in technology and breath of patterns and techniques. Some teams will have an architect role, a person who is the master builder, while other teams will be composed of people who are all good at architecture. However, “software development is not a relay sport.” The architecture should not just be thrown over a wall to the design or development teams.
How much up-front architecture is necessary? “Just enough.” How much is that? Well, we need to understand, for example, the significant elements and how they fit together or how the system will be secure. We don’t have to know up front all of the design. We want to “understand the structure … and create a shared vision,” but this is not sufficient. We also need to “identify and mitigate [our] highest priority risks.” How do we identify the risks? Brown suggests “risk-storming.” You can read more about it in his book Software Architecture for Developers.
In summary, Brown says to create an architecture, understand the structure, create a shared vision, and identify high-priority risks. Unfortunately, most teams don’t architect, or understand how to architect, software. Our responsibility—your responsibility—is to educate people. It is not about processes, it is about architecture.
Agile Architecture and Design
Pradyumn Sharma, Pragati Software Pvt. Ltd.
When do you do architecture in an agile project? In traditional waterfall, the architecture is done up front, before we have a complete understanding of the project. Agile evolves the architecture iteratively after some initial envisioning. In an agile process, we learn more about the project from implementing the stories and getting feedback.
How do we do this? Involve the entire team not just in architecting the solution but also in grooming the backlog, modeling the system, and other related activities. An architecture and the process to create it is given to a team member to “own.” The architecture owner does not dictate the architecture; rather, he or she helps establish the shared vision within the team. An architectural vision is created iteratively by holding an architecture workshop for the team and product owner.
What goes on in the architecture workshop? The team will do domain modeling and UI design, establish and prioritize the architectural qualities (SEI terms these “quality attributes”), and discuss how to achieve the qualities (without committing). For example, if a quality we are concerned with is concurrency, strategies for achieving this might be use of transaction managers and optimistic/pessimistic locking.
Cross-cutting requirements (such as audit trails or alerts), and other nonfunctional requirements such as the life of the product, must be identified. Further, the risks must be identified and analyzed.
After everything has been identified, the team must take stock of reusable architectural assets.
Finally, the team must prioritize architectural features by business value and the cost of implementing early or late in the development effort and put these requirements in the product backlog.
After the vision is created, the team can begin development (Iteration 1 and later). Architectural stories are completed incrementally as they appear in the sprint backlog. To perform this implementation, the architectural decisions are made with the help of the customer. As needed, the architecture is refactored, evolving the architecture iteratively.
An Emerging Set of Integrated Architecture and Agile Practices that Speed Up Delivery
Stephany Bellomo, SEI
Bellomo presented her group’s work in two research studies on integrated architectural practices. More detail can be found in the full paper to appear in the proceedings of the International Conference on Software Engineering (ICSE 2013).
Study 1: This study attempts to answer the question “What activities lead or contribute to agile project success in the industry?” They questioned a number of teams using agile techniques. Many of the techniques were not interesting (the typical sorts of things you see in literature), but after looking a bit further, they found some interesting things.
Bellomo and colleagues noticed that projects try to stay within a “desired” state—their development “groove,” a state that has been established and is fairly stable. This state might be a predictable velocity. To achieve this, teams would integrate architectural practices with their agile or Scrum practices such as release planning with architecture considerations (e.g., quality, performance, etc.), prototyping with quality attribute focus, and release planning with joint prioritization. They also found several velocity inhibitors such as a desire for features limiting requirements analysis or stability-related work. In fact, there seemed to be a relationship between the integrated practices and the inhibitors. More work is necessary to explore this relationship further.
Study 2: The teams participating in the study had different experience levels, so Bellomo and colleagues captured the prototyping guidelines from one of the mature organizations. They found that the mature organization was weaving architectural analysis into the sprints. Architects contribute to the prototyping of the system, setting up some of the architecture for the iteration. Later, while the customers were demo-ing the system, the architects would probe for information, gaining better insight into the requirements of the system.
Study 1 found that software engineers integrate architectural practices into agile development, while Study 2 validated that one particular practice, weaving architectural considerations into release planning, is being used by another mature organization. More work is necessary to validate the other architecture-related measures and to draw further conclusions.