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:

  1. Business Value: design decisions aligned to the business strategy
  2. Domain: design decisions aligning boundaries with the problem domain
  3. Sociopolitical: design decisions driven by the needs of the people building the systems
  4. Technical: design decisions affected by the technical requirements of a system (e.g. performance, security)
  5. 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.


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?



Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)