Rebecca Wirfs-Brock and I developed a workshop on decision making in software architecture. This is an extract from a paper from the IEEE International Conference on Software Architecture (ICSA 2019) that describes the workshop. The final version is in the ICSA proceedings. A preprint of the full paper is available here.
First, we shape our architecture. Then, our architecture shapes us. As architects we bring part of ourselves to the systems we work with. We evolve with our architectures. In this tutorial we consider the metaphor of “terroir” to understand architectures and their sense of place. Terroir comes from the French word used to describe the set of all environmental factors that affect the observable characteristics of an organism, e.g., the unique set of contextual characteristics of place that influence food crops, coffee, tea, or wine. So too in systems, architectures are uniquely shaped by the culture and context of a place. Factors include people, organization, culture, technology, and tenets shared among the architects and makers. Understanding an architecture is a first step towards evaluating it. The set of concepts and practical tools covered in this tutorial are well suited to being used in conducting architecture analyses and reviews and integrate with any other processes an organization might be using.
Structure and Outline
- Part 1: Making sense of system architectures. The tutorial begins by introducing some concepts that help people to make sense of a system architecture. The outcome includes insight not just into the architecture itself, but also the wider context, including culture, decision-making processes, attitudes, constraints, and assumptions that contribute to the architecture. We will demonstrate how to see and interpret patterns to understand architecture context and understand the decision-making landscape of which architects are part.
- Part 2: Decision models for architects. Having established a sense of place for the architecture, we will move into discussing decision models. Different kinds of decision are necessary to evolve our architectures. Sometimes we need to make high-stakes decisions under conditions of uncertainty, with insufficient information, and too little time. Other times we need to balance deep thought, collaboration, and trade-offs among different architecture qualities.
- Part 3: Taking action to evolve our architectures in conditions of uncertainty. Once we have a sense of place, and we have decided how we will make decisions, we will move into action. In this tutorial we focus on making decisions and acting in conditions of volatility, uncertainty, complexity, and ambiguity. We explore the roles of heuristics and experimentation for making decisions under such conditions, and how this influences the evolution and evolve-ability of our architectures.
- Part 4: Practical considerations for the dimension of time in architecture decisions. In this section we will look at the temporal dimensions of architecture decisions. We will look at the time factors that affect our architectures. These include when decisions are made, the cadence of decision making, the impact of decisions over time, and challenges around ensuring follow-through and consistency of decisions over time.
- Part 5: Summary and closing activities. Summary of concepts, decision models and tools; Q&A. In this section we spend time to ensure participants have at least one or two practical things they are ready to try when they get back to the office.
This is the abstract and recommendations from a paper on understanding the context in which architects make decisions that I co-wrote with Rebecca Wirfs-Brock. We presented the paper at the 2018 European Conference on Software Architecture (ECSA 2018) in Madrid. The full paper is available in the ECSA 2019 proceedings, published by Springer. A preprint version is available here.
Many organizations struggle with efficient architecture decision-making approaches. Often, the decision-making approaches are not articulated or understood. This problem is particularly evident in large, globally distributed organizations with multiple large products and systems. The significant architecture decisions of a system are a critical organization knowledge asset, as well as a determinant of success. However, the environment in which decisions get made, recorded, and followed up on often confounds rather than helps articulation and execution of architecture decisions. This paper looks at aspects of architecture decision-making, drawing from an industry-based case study. The data represents findings from a qualitative case study involving a survey and three focus groups across multiple organizations in a global technology company. Architects in this organization are responsible for multiple products and systems, where individual products can include up to 50+ teams. The impact is not just on others in the system; architecture decisions also impact other decisions and other architects. The findings suggest recommendations for organizations to improve how they make and manage architecture decisions. In particular, this paper notes the relevance of group decision-making, decision scope, and social factors such as trust in effective architecture decision-making.
- Consider the space-time separation of teams, and how that impacts architecture de- cisions. When dealing with teams who are separated in space (through multiple ge- ographies) and time (through multiple time zones), make an effort to compartmental- ize the scope of responsibility of teams such that coherent architecture decisions can be made in each location.
- Establish clear decision-making boundaries. Articulate who is responsible for which type of decisions. This can be based on scope of decision (product, system, compo- nent, etc.), nature of decision (product, technology, etc.), or something else.
- If your organization is using an agile development approach, then take the time to articulate how architecture fits.
- Understand who is impacted by decisions made by architects. Establish a feedback loop so that architects understand that impact in a timely manner.
- Start with why. Architects in this study expressed a much higher degree of success in decision adoption when other people understood why a decision is being taken. This is an important part of the context of architecture decisions.
- Take the time to foster trust among architects and those impacted by decisions.
- Consider how architecture decisions are retained and communicated. We see a need for retaining and communicating architecture decisions and their rationale, espe- cially when decisions have broad impact. Documenting decisions, to be effective, should fit into existing processes.
- Some decisions are necessarily made for short-term expediency, e.g. to address an immediate customer need. Perhaps there needs to be some mechanism to flag these types of decisions and manage them, perhaps in a product debt backlog (especially those that will incur architecture debt) for periodic review.
This is the abstract from a paper I co-wrote with Kieran Conboy and Meghan Drury. It was published in the June 2012 issue of Journal of Systems and Software. The full paper is available from Elsevier.
Drury, M., Conboy, K., and Power, K. (2012). “Obstacles to decision making in Agile software development teams.” Journal of Systems and Software, 85(6), 1239-1254.
The obstacles facing decision making in Agile development are critical yet poorly understood. This research examines decisions made across four stages of the iteration cycle: Iteration Planning, Iteration Execution, Iteration Review and Iteration Retrospective. A mixed method approach was employed, whereby a focus group was initially conducted with 43 Agile developers and managers to determine decisions made at different points of the iteration cycle. Subsequently, six illustrative mini cases were purposefully conducted as examples of the six obstacles identified in these focus groups. This included interviews with 18 individuals in Agile projects from five different organizations: a global consulting organization, a multinational communications company, two multinational software development companies, and a large museum organization. This research contributes to Agile software development literature by analyzing decisions made during the iteration cycle and identifying six key obstacles to these decisions. Results indicate the six decision obstacles are unwillingness to commit to decisions; conflicting priorities; unstable resource availability; and lack of: implementation; ownership; empowerment. These six decision obstacles are mapped to descriptive decision making principles to demonstrate where the obstacles affect the decision process. The effects of these obstacles include a lack of longer-term, strategic focus for decisions, an ever-growing backlog of delayed work from previous iterations, and a lack of team engagement.