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 from a paper I wrote about my experiences using sensemaking in large-scale transformation efforts. I presented this at the 49th Hawaii International Conference on System Sciences (HICSS 2016). The final paper is available as part of the HICSS proceedings. A pre-print is available here.
For organizations undergoing agile and lean transformation, it can be difficult to get meaningful, actionable insights into progress and impediments. Teams and organizations are best understood as complex adaptive human systems. Understanding what is happening in such systems requires approaches grounded in the complexity sciences and social sciences. This paper describes an approach using complexity science and sensemaking that helps an organization understand its culture, how it is progressing with its strategic initiatives, and the types of impediments that are holding it back. It provides a means of qualitative and quantitative analysis that helps teams and organizations improve. This paper also correlates the experiences of the people in the organization to its goals of being a more agile organization.
This is the abstract and conclusions from a short paper I wrote and presented at the 15th International Conference on Agile Software Development (XP 2014) in Rome, Italy. A preprint version of the full paper is available here.
Teams and organizations are complex adaptive systems. Self- organization in complex adaptive systems evolves through a set of Simple Rules. Self-organization is a core tenet of agile teams. Self-organization does not mean everyone gets to do whatever they want to do. Team members create contracts with each other. These contracts create boundaries, or containers, within which self-organization can occur. Teams also create contracts with other teams, the wider organization and other stakeholders. The contracts are both implicit and explicit. Social contracts in complex adaptive systems are more effective if they are based on Simple Rules. Social Contract Theory acts as a lens through which we can better understand these social contracts in agile teams. This paper represents ongoing research that examines the role of Simple Rules and Social Contract Theory in fostering self-organization in agile development teams. The paper discusses four examples of social contracts in agile teams: definition of done, definition of ready, working agreements, and retrospectives.
This paper described the connection between Social Contract Theory and agile teams, viewing agile teams as complex adaptive systems. The field of Human Systems Dynamics provides a suitable lens through which to view teams and organizations as complex adaptive social systems, and defines necessary conditions for self- organization using Containers, Differences and Exchanges. The social contracts in agile teams and organizations are based on the Simple Rules that govern emergence and self-organization.
Simple Rules support coherent behaviors in a system. Definition of done, definition of ready, and working agreements are all examples of social contracts, created using Simple Rules, in agile teams and organizations. In addition, there are examples of social contracts to be found in retrospectives, including the prime directive, second directive and ground rules. These Simple Rules and Social Contracts support emergent behaviors and self-organization.
Teams own their own Simple Rules. As teams adapt their Simple Rules, new patterns are formed in the system. These patterns are governed by the social contracts created by the Simple Rules. Violating the Simple Rules creates a tension in the system that can be resolved by the team enforcing the rules or altering the rules (an Exchange intervention), or by the team membership changing (a Container intervention).
Social Contracts exist within agile teams, between agile teams, between agile teams and management, and within management teams.