Value-based Architectural Decisions in Agile Development
Jeromy Carriere, chief architect at eBay, received the Architecture in Practice award at the SATURN 2011 conference for his experience report on introducing sustainable architecture practices at Vistaprint, a fast-moving agile company. Jeromy described how economical accountability and ownership for architectural transformations set the ground for autonomous yet consistent design decision-making by the agile teams.
Jeromy also referred to the challenges of overcoming the mental barrier of developers equating architecture to big upfront design activities and the architect’s role to a standards enforcement officer. He engaged in frequent conversations with teams to understand project issues and provided assistance whenever asked in order to gain credibility in the organization. Eventually the view of architecture being a tool for quantifiable decision making and architect being a shared role among all engineers got across.
By assigning an economical value (in terms of project impact) to architectural transformations a rational and transparent decision making process could be followed by the project teams to decide whether to go ahead with the transformations. In order to factor in the transformational needs of the organization together with the project needs, a minimal set of guiding principles was followed in the decision making process, including for instance:
- Articulate distinct choices and selecting the one that maximizes full economic value
- Choose designs that will result in the smallest, least coupled software
- Utilize standardization to increase predictability and scalability
LAAAM (Lightweight Architecture Alternative Assessment Method), a decision making process inspired on the Software Engineering Institute’s rigorous ATAM (Architecture Tradeoff Analysis Method), played a critical role in structuring and weighting relevant qualities at different levels, as he explains:
In the context of making decisions that need to consider both local (e.g. project) and global (e.g. enterprise) concerns, I typically try to build a composite quality tree – one in which, perhaps, the qualities and subqualities are specified at the enterprise level, with a partial ordering of rankings (e.g. performance is more important than security and reliability is more important than security; the relative importance of performance and reliability aren't specified), and projects specify a total order of the quality attributes compatible with the partial order. Projects then also specify the scenarios that are relevant in their particular contexts.
LAAAM provides a straightforward calculation of the value of each architectural alternative based on their fitness (poor, fair, adequate or excellent) to address the relevant scenarios (weighted according to their ranking in the quality tree) for the project and the enterprise. The goal is not to blindly pick the “winner” alternative but instead validate that sensitive scenarios are effectively addressed. In some situations when the ranking difference between alternative decisions is too narrow a good strategy is to refine the scenarios into sub-scenarios and re-apply the method.
Jeromy told InfoQ his priorities for the evolution of LAAAM: integrating a cost model (opportunity cost due to late feature delivery and cost of technical debt in terms of productivity loss and operational cost) as well as providing tooling support.