Introduction
Welcome to the third part of the Socio-Technical Engineering series. This series explores the practical application of treating socio-technical systems like any other system. While Systems Engineering deals with technical systems, and Organization Science focuses on social aspects, Socio-technical Engineering aims to holistically apply the knowledge from both disciplines to broader socio-technical systems. These systems can be found in software projects and any organization involved in product creation or service offerings.
In the previous post, we discussed requirements analysis for socio-technical systems. Now, let's delve into the next step: system design based on these requirements. System design involves making decisions about how to arrange system elements. In this post, we will explore the types of elements present in socio-technical systems and the decisions we can make regarding their arrangement.
Elements of Socio-technical Systems
Have you ever wondered what happens in a project on a daily basis? Here is a secret insight. People work on tasks related to artifacts, guided by their assigned roles. These four nouns—people, tasks, artifacts, and roles—serve as the basic elements of socio-technical systems. By arranging these elements, we can express the design of any organization.
People refer to concrete individuals, such as Eva.
Artifacts encompass everything created, elicited, or operated by a project. They include not only components of the final product, such as code or technical infrastructure, but also technical infrastructure, business, and operational aspects.
Technical artifacts: code, tests, automation scripts, configurations, build pipelines, architecture and design documentation, technical specification, etc.
Infrastructure artifacts: databases, message brokers, servers, cloud instances, etc.
Business artifacts: customer value proposition, business case, requirements, etc.
Operational artifacts: project plan, product roadmap, project handbook, staffing plan, organizational structure, controlling documentation, product backlog, sprint backlog, etc.
Tasks represent the work items that individuals undertake, with the aim of achieving a desired goal. Tasks are organized in a hierarchical structure known as a Work Breakdown Structure.
Q: Why is "Goal" not a basic element? A: Because any goal can be expressed as a state of artifacts. For example, a product release is a "Deployed" state of a collection of technical artifacts, such as services and databases.
Q: Why are there no "blocks/blocked by" relations between tasks, as one used to in the tools like Jira? A: Tasks depend on each other because the underlying artifacts do. For example, tests for component X depend on component X itself. We used to say that a task on testing depends on the implementation task. But the real dependencies are between the artifacts. The dependencies between tasks are derivatives.
Roles define the responsibilities individuals have for specific artifacts. Roles are more than just decision-making authority; they encompass the ownership and accountability for artifacts. For instance, the "Lead Software Architect" may not be the one creating the Software Architecture Documentation artifacts, but they are responsible for it. Similarly, the "Product Owner" is responsible for the backlog.
Requirements for Artifacts
Requirements in socio-technical systems are multi-layered. Just as there are system requirements, each artifact has its own set of requirements. These requirements arise from the needs and concerns of stakeholders associated with the artifacts. A role carries the responsibility of meeting these requirements and ensuring the quality attributes align with stakeholder expectations.
For example, imagine the role of a maintainer for component C, which is assigned to team T. The stakeholders of component C include the Product Owner, who wants a new functionality implemented by Friday; the developers of team T, who want an easily extendable component; the system architect, who wants the component to adhere to the agreed-upon design; and the testers, who want to be able to test the component. Understanding the stakeholders and their needs is crucial for making transparent prioritization decisions. By prioritizing only the Product Owner's needs, the component may be extended by Friday, but in a non-maintainable and non-testable way, compromising the overall software design.
Bonus: Impostor-Test
An interesting test to identify impostors is to evaluate whether a person contributes positively to any artifact that serves the stakeholders. Those who merely jump from one meeting to another without adding value may be identified as impostors. This test helps highlight the importance of active participation and contribution within the socio-technical system.
Bonus: Assessing Performance
To assess a person's performance, consider the following questions:
What role(s) does the person have?
Which artifacts fall under their responsibility?
Who are the stakeholders of these artifacts?
Are the stakeholders' needs and concerns being adequately addressed by the artifacts?
Decision Types
In socio-technical systems, decision-making revolves around four types of elements. These decisions, though often unconscious, consist of three atomic components:
Decomposition: How to divide and structure things? Decomposition decisions involve dividing, clustering, modularizing, and structuring elements. Examples:
How to split teams?
How to carve the system into system components?
How to cut tasks or user stories?
How to divide which information goes into which document?
How to segregate school pupils into classes? (by age, by gender, by interests, by zodiac sign, etc.)
Integration: How to connect the divided elements? Integration decisions focus on connecting the elements that have been divided. Examples:
Once teams are split, how will they sync on common issues? (For example, team leads daily, Scrum of Scrum, etc.)
Once the system components are carved, how will they be connected? (For example: via message broker, HTTP, etc.)
Once the tasks are cut, what are the dependencies between them?
Once it is clear what goes into which document, how to organize the referrals from one knowledge base to another and keep it up to date.
Once pupils are segregated (for example, usually by their age, and then randomly in the classes such as 5a, 5b, and 5c), how to connect them with their teachers? Classical solution: there is classroom teaching in the school, and then pupils get homework.
Allocation: How to assign entities or resources? Allocation decisions involve assigning entities or resources to other entities or resources.
Who goes on which team? Example: Alice (a person) goes to Team A, Berta goes to Team B.
Where does the system component get deployed (on a company server, in the cloud, in the web browser, on PCs, or a smartphone)? Example: The web-client runs on an employee desktop, the service X runs in the cloud, and the user's preferences are explicitly stored on the user's smartphone.
Who is the assignee for User Story X? Example: Alice is assigned to story X in Jira.
Who is responsible for document Y? Who are the reviewers? Example: Berta is responsible for Software Requirements Documentation; Alice and Zelda are reviewers.
Who is the math teacher of class 7b? In which room should the chemistry class take place? Example: John is the math teacher of class 7b. Example: The room for chemistry classes is 404.
To whom is the role R allocated? Example: The Role of the Project Lead is allocated to Jack.
We used to say: Jack has the role of the Project Lead. However, it is better to put it like the Role of Project Lead is allocated to Jack because if Jack goes on vacation, the Project Lead role doesn't go on vacation. There are two options. If the role is reallocated to another person, then the role stays operational. Otherwise, the role of the Project Lead has downtime. It depends on the allocation decisions we make. Note: It is impossible to reallocate a role to someone else without changing the design. Services that are designed for scale and services that are not designed for scale have very different architectures, just because the first ones have to share data with siblings and the second ones don't. The same applies to roles. That's why effective delegation is impossible if the socio-technical architecture doesn't enable it. We will elaborate on this topic in future posts.
Conclusion
In conclusion, socio-technical systems comprise four fundamental elements: people, roles, tasks, and artifacts. By understanding the relationships between these elements and employing three atomic decision types—decomposition, integration, and allocation—we can effectively design and reason about socio-technical systems. The language of elements and decisions provides a framework for analyzing and creating these systems. In the next post, we will explore the application of design best practices in the realm of socio-technical systems, utilizing the elements and decision types discussed here. Stay tuned for more!
Appendix: Socio-Technical Engineering Workshop
Socio-Technical Engineering is a practical discipline that requires work. A good start to this work is a workshop. In the Socio-Technical Engineering Workshop, we will put the theory of this article series into practice. Specifically:
We will identify the scope and context of your socio-technical system.
We will conduct requirements elicitation for your socio-technical system.
We will create an artifact map, listing the stakeholders and their concerns for each artifact.
We will analyze which roles are present in your organization and define these roles in terms of responsibilities for artifacts.
We will extract important architectural structures in your socio-technical system by analyzing which atomic decisions manifest the system.
We will draft socio-technical design for your socio-technical system to meet the requirements using design elements and atomic decisions.
We will troubleshoot issues in your socio-technical system, such as communication overhead, too many meetings, too many bugs, suboptimal team structures, etc.
If you want to learn more about the Socio-Technical Engineering Workshop, feel free to contact me.
Comentários