Socio-technical architecture is a fairly new term, so it's hard to find precise definitions. But socio-technical systems is not something new. In organizational development a socio-technical system is a system where humans and technology must interact to perform work. In modern society there's few people that are not part of a socio-technical system. Those of us that work in the technology business are exposed to systems like these every single day.
The history of socio-technical systems is interesting and relevant for the trends we are seeing in technology organizations today. The term is attributed to Fred Emery and Eric Trist, who studied workers in coal mines in England in the 1950s. The ruling management practice at the time was Scientific Management - developed by Frederick Winslow Taylor around the turn of the century. In this practice the coal miners were specialized - One worker would work the drill, another would be responsible for cutting, another shoveling and yet another for transportation. Emery and Trist introduced what they called "multi-skilled teams and sharing of tasks". The miners would learn to work multiple tools and perform a variety of tasks. The results were immediate. There were fewer accidents, increased productivity and less absentees. In the old model of specialized workers there was little communication between members on a team. They would blame each other for accidents and errors. In the new model the communication within teams was improved significantly and they possessed the skills needed to handle different, often new and dangerous, situations. It also became natural for teams to focus on preventive work and maintenance, while in the old model that kind of work often did not have a clear ownership in the silo-like model. We see the same kind of behavior happen in what we today call cross-functional product teams.
Another scientist that has had a large influence on socio-technical architecture is Dr. Mel Conway, the namesake of "Conway's Law". Conway's Law says that:
“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure”.
This means that how we organize human beings, and what constrains (or lack thereof) we put on the interaction between them, will be mirrored in our system architecture. This force is also isomorphic, and how our systems are designed will influence how communication pathways are formed in the human system. I've experienced myself how an old technical architecture can lead to an inertia in a re-organization. The old architecture put unintended constrains on which teams had to collaborate, and on what form that collaboration took.
As the microservice trend has gained more traction, many developers and architects have been exposed to the effect of Conway's law. With Team Topologies, published in 2019, the awareness of this law has moved beyond developers and architects. Now you'll meet managers at different levels that understand what you mean when you mention Conway's law (or the now popular "inverse Conway maneuver").
However, we still have a long way to go when it comes to spreading awareness on the intricate interactions between social and technical structures. I observe that a lot of people that have read Team Topologies get fixated on the team types introduced in the book. But for me there was two other things that were far more radical in the book:
- The notion of organizing your teams and system ownership around cognitive load. Obviously this an important human aspect of socio-technical architecture design.
- How you design the interaction between teams, and how this interaction changes over time is a very important part of socio-technical architecture design.
In modern networked organizations with cross-functional teams and a focus on innovation processes it seems that many believe that any collaboration is good collaboration. But what I think Team Topologies highlights is that we need to be very conscious about how teams should interact, and who they should interact with. Not being explicit about this will put a strain on the team's available communication bandwidth. This will then lead both to a high cognitive load in having to interact closely with many teams and wasting a lot of time on coordination activities. We also need to be aware of how interactions changes over time, and explicitly moving fuzzy collaboration in a discovery phase to more standardized interactions in a delivery phase. This will free bandwidth and cognitive load on teams to form new collaborative relationships, or focus on increasing internal productivity when they are moving into delivery mode. As the father of systems-thinking Russel Ackoff said:
An organization is a system and the performance of a system depends more on how its parts interact than on how they act when taken separately.”
I'd like to end this post with my suggestion on the definition of socio-technical architecture:
Socio-technical architecture is understanding that social structures (teams, organizational design, organizational charts or even the physical design of our workspace), and technical system architecture cannot be designed in isolation. It's critical that we take a holistic perspective on the design of the social and the technical system, so these can co-evolve together. We need to embrace that both technical and social structures will constantly be changing, often in unintended and unpredictable ways.
The Evolution of socio-technical system by Eric Trist: http://sistemas-humano-computacionais.wdfiles.com/local--files/capitulo%3Aredes-socio-tecnicas/Evolution_of_socio_technical_systems.pdf
Conway’s Law: https://www.melconway.com/Home/Committees_Paper.html
Team Topologies: https://teamtopologies.com/