In anticipation of Amal Tahri's session, "Evolution Patterns of Sociotechnical Systems", we asked her a number of questions, e.g.: Why are sociotechnical systems relevant for software architects? And what are evolutionary patterns in sociotechnical systems?
Not every software architect has heard of sociotechnical systems. Can you explain in a few words how relevant the topic is from a software architect’s perspective?
The Sociotechnical system is relevant for any software architect because it includes the people that he/she is working with and their interactions such as development teams, POs, business owners, and C-level. Their interactions are based on communication, either for information exchange, explanation, or decision-making. The quality of this communication impacts the technical system, i.e., the software or product being developed. As Conway's Law states "Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure".
Software architects are familiar with design patterns but probably not with evolution patterns. Could you elaborate on the concept of evolution patterns within sociotechnical systems?
Patterns are recurring problems, observed from the real world, that provide teaching or solution. Design patterns are best practices shared in coding to prevent potential issues in code quality and to ensure software "itilities" such as modularity, maintainability, and evolutivity. Evolution patterns are inspired by systems thinking and describe characteristic behavior of an organization including people and processes implicitly governed by organization culture, i.e., "how things are done here". These patterns are described as causal feedback loops where a cause leads to an effect, and the effect leads back to the initial cause. The pattern is detected in the loop between the cause and effect. For example, a bug in production can be caused by errors in development, these errors are originally due to pressure to deliver in a short time, and as long as the same pressure persists, bugs in production will occur inevitably. These patterns are detected in system behavior "the dynamics driving the system" and can be related to people interaction, processes in place, and decision-making.
What are some common challenges that organizations face when managing the evolution of sociotechnical systems, and how do these challenges impact the success or failure of the evolution process?
Common challenges faced by organizations in managing evolution are first of all "awareness" and recognizing these patterns, if the organization is not able to recognize these patterns it will continue to have the same outcomes. Once the pattern is recognized, another challenge is to identify when and where to intervene in the system to change this pattern effectively. Once the change is defined and made, another challenge is its persistence in time. Will it be adopted by the organization or just abandoned after a given time and back to the same pattern?
In your talk, you mentioned the impact of leadership and decision-making on the success of evolution cases. Leadership sounds more like a top-down approach, evolution sounds more like self-organization. Could you share an example of how effective leadership played a crucial role in a successful evolution process?
Leadership is any person responsible for making decisions that can be at the executive level or a day-to-day operation level. The only difference between both levels is the cost of error when making a decision that is not fitted to the situation. So, in order to enable a successful evolution process, both approaches top-down and bottom-up (or self-organized) must meet at a given point. This can be achieved with the model "freedom in a frame":
1) The executive-level leaders provide sponsorship to the day-to-day operation leader: he/she sets the direction and the vision of the evolution.
2) The day-to-day leader contributes to what works best in real-life situations, as they create a feedback loop on the feasibility of such a vision. An atmosphere of co-construction, mutual challenges, and a certain degree of team autonomy (in opposition to micro-management) is mandatory to make sure that the evolution process is on track, and most of all the right to error (in a frame of course), evolution means experimentation, research, dead-ends and repeat till you succeed. That must be shared and understood by all the parties participating in the evolution process, funded along with time allocation.
As sociotechnical systems are inherently unpredictable, how do you recommend organizations prepare for potential disruptions or unexpected outcomes during the evolution journey? Are there any strategies to mitigate risks associated with such unpredictability?
Considering that sociotechnical systems are complex, unpredictability is an inherent characteristic of the system mainly driven by human behavior. The only way to deal with the unknown, potential disruptions, or unexpected outcomes is to dissect the problem into smaller pieces, get to the root cause if possible, detect where to influence the system, propose a solution, and get quick feedback on the accuracy of this solution in small batches/sprints in order to adapt the trajectory and progress step by step. The effort done by Donella H. Meadows in her book "Thinking in Systems" and the research done by William Braun in his paper "System Archetypes" is to present 10 archetypes of system patterns that describe observed dynamics in the evolution journey. In this talk, I am tackling one archetype named "limits to growth" and applying a strategy to drive change effectively. Each archetype has its own recommended strategy that can be adapted according to the execution context.
Software architecture is also subject to evolution. Can understanding the evolution patterns of sociotechnical systems also help to improve and change software architectures and mitigate risks in this area?
System architecture is the combination of software architecture and organization architecture that must be aligned to drive business outcomes. Evolution is rarely an isolated part of the system. For example, a bug in the production of a newly developed feature is rarely just a bug in production, it can be related to code error, lack of testing, lack of reviews, due to fast and slappy code writing, or missing knowledge of given dependencies, due to missing documentation or lack of communication, due to pressure to enhance team velocity, due to pressure to deliver business outcome faster, etc. Understanding the cause and effect of a given situation can help adjust and mitigate the risks.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
