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.