Sociotechnical Design Variables
Over the past few years I have focused much of my learning and work choices around learning about the design of sociotechnical systems — how to design software architectures and organise teams around them.
Looking through the history of my talks and my posts you can see evolutions in my thinking. One of my current working models is that there are five main categories of criteria for designing boundaries:
- Business Value: design decisions aligned to the business strategy
- Domain: design decisions aligning boundaries with the problem domain
- Sociopolitical: design decisions driven by the needs of the people building the systems
- Technical: design decisions affected by the technical requirements of a system (e.g. performance, security)
- UX / Brand Perception: design decisions which have an impact on how users experience the system
I’ve recently been collating some of the variables which exist in each of these areas, and they are presented in the remainder of this article.
In general, I believe we have the ability to choose the values for all of these variables. As part of good design, we should consider the effects of changing all of these variables. Perhaps they could be considered as the degrees of freedom with which we need to add constraints.
Keep in mind, as well, that changing one variable impacts another. This is the essence of design, trading off one variable to improve another.
However, depending on the domain and the organisation some variables will have stronger constraints or limitations. For example, an organisation may have existing offices in five countries. While we could theoretically control this variable, in reality it would be difficult and unlikely in many scenarios.
I hope you find these variables useful. I use them whenever designing system boundaries as a checklist to help me consider the many different ways in which a system could be designed. Please keep in mind that this is a current snapshot of my thinking and will change over time. And if you have any ideas or suggestions, I’d love to discuss them with you.
If you prefer to view this information in table format, as I do, you can view the version on my website.
Business Value Variables
Business Model Relevance
Shape boundaries based on importance to business model E.g differentiator business capability vs business necessity.
Business Model Role
Shape boundaries based on role in the business model. E.g. revenue generator or engagement creator.
Strategic Relevance
Shape boundaries based on importance to current business strategy. E.g. strategic vs non-strategic capabilities.
Concept Evolution
Shape boundaries based on evolution of business concept (see Wardley Mapping). E.g. Genesis, commodity.
Risk Level
Shape boundaries based on the level of business risk within each component (e.g. isolate high risk areas).
Domain Variables
Domain Flow Direction
How the business process flows through components. E.g. unidirectional, bidirectional.
Domain Flow Control
How is the business process controlled? E.g. orchestration, choreography.
Domain Flow Duration
What is the duration of the overall business process, or a subset. E.g. seconds, hours, days, months.
Linguistic Boundaries
The classic DDD heuristic. Where are the boundaries in language where certain phrases have specific definitions?
Domain Complexity
How inherently complex are the domain rules and responsibilities within a component?
Communication Verbosity
How information flows between components. E.g. full document vs correlation IDs.
Inward Dependencies
The number of components which depend on a given component.
Outward Dependencies
The number of components which a given component depends on.
System Role
What is the role of a component in the system. E.g. Aggregator, calculator, information source.
Data Ownership
For each piece of data a component depends on, is it the authority for that piece of data or just a consumer?
Sociopolitical Variables
Purpose / Aka Intrinsic Motivation
Varying the shape of a boundary will vary the purpose of the team building it and how motivated they are by that purpose.
Team Autonomy
Varying the shape of a boundary will introduce or remove dependencies on other components, increasing or decreasing the autonomy of a team to complete their tasks without depending on others.
Alignment Efficiency
Varying the shape of a boundary will alter the dynamics of collaboration between teams who need to be aligned, which may be more or less efficient for achieving goals.
Domain Cognitive Load
Matt Skelton and Manuel Pais argue in Team Topologies that boundaries will impact the cognitive load of the teams. The more parts or the more complexity of a domain they are responsible for the greater the cognitive load.
Responsibility Burden
How many parts of a system are a team expected to support. Similar to cognitive load, the more responsibility a team has, the more chance they will be burned out.
Technical Expertise Alignment
Varying the shape of a boundary may affect alignment between skills of the team and the skills required to build, sustain and support a component. E.g. having to maintain components built in multiple technologies.
Personal Growth Potential
Varying the shape of boundaries will impact the types of work and the possible technologies a team is exposed to. This will affect their opportunities for learning and growth.
Concept Mindset
How does the mindset of the team align with the evolution of the concept. E.g. pioneers, settlers and town planners.
Social Complexity
Varying the shape of boundaries can impact the social complexity, which can lead to burnout.
Team Geography
Which locations and timezones will teams and team members be located in?
Stakeholder Alignment
Which parts of the system do the different stakeholders care about? E.g. which parts of the system does a certain stakeholder ask for changes to?
Technical Variables
Operational aka Non-functionals
Consider how to isolate varying performance, scalability, security, etc. needs when designing boundaries.
Coupling Type
Which type of coupling exists between components: e.g. sync rpc vs async events.
Technical Couplings
How many dependencies does a component have an other parts of the system (which may not be visible at the domain level).
Technical Complexity
How technically complex is the solution within a boundary?
Technology Choices
For different parts of a system, boundaries may be shaped to allow different technologies to be used.
Maintainability
How easy is it to support and maintain a given component?
External Dependencies
How many services outside the system does a component interact with?
Data Storage and Access
Do different pieces of data need to be stored and queried in different ways?
Data Consistency
How does the shape of the boundaries determine which data will be consistent (within a transactional boundary)?
Independent Deployability
How will we shape boundaries to determine which parts of the system can be independently deployed?
UX / Brand Perception Variables
Team Ownership Model
Which team(s) is responsible for a UX or user journey? E.g. one team, multiple teams.
Technical Ownership Model
Within which logical boundaries does a given piece of UX exist? E.g. Dedicated experience, within a bounded context, micro-frontends.
Positive Brand Impact
How much can a given UX impact the perception of the company brand in a positive way?
Negative Brand Impact
How much can a given UX impact the perception of the company brand in a positive way?
User Types
Which users interact with a UX? E.g. internal users, external users.
User-level Consistency
Which pieces of information need to be consistent to the user?
