An Introduction to Sociotechnical Architecture Patterns

Software systems are inextricably linked to the organisation that builds them, aka the system of work. By co-designing and co-evolving the software system and the system of work, modern organisations gain competitive advantage through faster iterations and higher quality discovery cycles.

As a result, we must all think of ourselves as sociotechnical architects. When we are architecting a software system, we must consider the impact on the teams in the organisation and vice-versa.

A lackadaisical design choice in either the system of work or the system of software can introduce severe bottlenecks that cause weeks of lost effort and exasperating political wrangling. I have the mental scars to prove it, and I’m sure you have as well.

We can avoid these pains and consciously design complex sociotechnical systems through the use of patterns. The patterns help us to understand the challenges of an existing organisation and help us to design and evolve new sociotechnical systems.

Patterns are just a starting point, though. Understanding the patterns teaches us how to analyse new and novel scenarios so we can make judicious design choices in any situation whether in our own organisations or for our clients.

So let’s take a look at a few patterns and see how they can help us in our strategic and day-to-day endeavours.

The Need for Sociotechnical Architecture

If you just want to see patterns, skip this section. If you want a bit more context, keep reading.

As a platform for digital business, the internet changed the economics of product development. Companies can now evolve their products and gain customer feedback in daily cycles.

Continuous iteration speed is now table stakes. If your competitors are continuously improving their product (and most are nowadays) and you’re not, the very existence of your business could be on borrowed time.

Organisations have come to accept that speed is a necessity in the digital age, and hence we have seen the rise of continuous delivery as a mainstream practice, alongside techniques like the Lean Startup and Lean UX, capitalising on the advantages of frequent iteration.

But, frequent iteration is only possible if the teams building the software have the ability to act on customer feedback immediately. This is a challenge in large organisations, where dependencies between teams result in high-levels of coordination. They are bottlenecks that devastate iteration speed.

Sociotechnical architecture patterns are there to guide us into designing sociotechnical systems that channel the flow of work through our systems toward optimal business outcomes. Accordingly, we must diligently co-design the relationships in our social and technical architectures.

Pattern: Activity-oriented Silos

Everyone is familiar with the classic sociotechnical architecture pattern. Activity-oriented silos have been the default sociotechnical architecture in tech companies for decades.

Activity-oriented silos are teams of functional specialists. Frontend developers build the websites, backend developers own the business logic, and DBAs are the database gate-keepers.

Usually, there are more layers, but three is painful enough.

This sociotechnical architectural pattern is based on traditional economics. Each person focuses purely on performing their speciality 100% efficiently so that large batches contain as many features as possible.

As we’ve all dishearteningly learned, this pattern is conducive to handovers and politics at every layer, resulting in longer end-to-end lead times. To get a feature out that cuts across all layers, coordinating teams to agree on a plan and then integrate their systems is invariably slow, depressing, and political.

Pattern: Business Capability Slices

Over recent years, a newer sociotechnical architecture pattern has emerged based on internet-inspired economics — faster feedback over maximum resource utilisation.

The new pattern involves aligning teams and software systems with business capabilities. Individual teams then have the autonomy to gain feedback from customers and quickly apply those changes to their systems. End-to-end ownership precludes expensive cross-team coordination.

Aligning to business capabilities seems like the obvious choice in the internet age. It certainly is a step in the right direction, but it’s not really a pattern, it’s more a heuristic. It’s not possibly to create an organisation comprised of 100% autonomous business capability slices.

In any organisation, business capabilities must interact to provide customers with higher-level capabilities. There will always be dependencies and handovers. We must understand the inherent dependencies in our business domains and design systems appropriately — that is the purpose of sociotechnical architecture.

Pattern: Octopus Context

After years of modelling systems in different organisations and domains, one pattern that frequently appears is the Octopus Context.

An Ocotpus Context is a sociotechnical context — a team responsible for a business capability (or sub-cability) and all the technology needed to deliver their capability — that reaches out and touches multiple other contexts.

One example I saw recently of an Octopus was GDPR. We modelled a GDPR context that would issue commands to all microservices in the organisation, demanding they comply with legislation and reply with a notification of their compliance for the audit trail.

Whenever I see an Octopus Context I am certain that there will be challenging political and technical consequences. One team depends on ten others — when that team wants to make a non-backwards compatible change, it’s usually going to be painful.

The dependendent teams will all have other priorities. If the Octopus’ enhancement does not help the dependent teams achieve their own goals, they will see it as barrier that slows them down, and they won’t treat it as a priority.

At the other end, the octopus team will face a lot of resistance. They will find themselves in lots of meetings and they may resort to management escalations in order for other teams to comply.

At a technical level, many of the pains can be avoided spending time on up-front design. If you can define a stable interface between the octopus and it’s dependants, there are less likely to be breaking changes in the future. The likelihood of undesirable politics will heavily be reduced.

Another technical tactic to aim for is to isolate the communication complexity in the Octopus making it easier for clients to integrate .

Pattern: Dog Food Context

Are you familiar with the phrase “eating your own dog food?” It means to use your own product if you are so confident in it. This pattern can also be applied to business, where a business becomes a faux customer of its own services in order to gain the experience of a real customer.

This is a super-interesting pattern because the economics of this situation are not oriented toward maximising revenue or optimising flow with vertical end-to-end slices aligned with business capabilities.

In my experience, this pattern actually demonstrates a valid use of the much-maligned activity-oriented architecture. We do want a dedicated frontend team who are focused only building websites provided by distant backend teams.

Why? Because the company’s main product is their platform. The goal of the dog food context is to gain valuable experience of what it feels like to be a customer, and use that feedback to improve the core platform.

The main consequences of this pattern are political. Teams responsible for a dog food context don’t acknowledge that their goal is to support other products. Everyone wants to build exciting new products and generate lots of revenue, nobody wants to be the team that builds a loss-leader for other products in the portfolio.

Technically, the dog food context team will also have inside knowledge of the main platform teams and will often have shared technical resources. This can limit the benefits of the dogfooding experience.

Summary

Modern organisations need to iterate at internet speeds. In order to do so, two overlapping systems must be co-designed — the software system that provides business capabilities, and the system of work that produces the software system.

Designing sociotechnical systems requires studious consideration of the economical, political, and technical factors of every design choice.

Since we can’t make changes to one system without impacting the other, we are all sociotechnical architects and we must all accept the responsibility of thinking economically, politically, and technically.

It sounds daunting, especially if you want to just get your head down and code every day, but sociotechnical architecture patterns can help us develop the mental models and the thinking patterns we need to make effective sociotechnical design decisions in any scenario.

I’ve noticed many sociotechnical architecture patterns over the past decade and I’ll be talking about them more in future posts and my upcoming talks. Here are a few examples:

Structural patterns:

• Enterprise Discovery Context
• Expertise Context
• Partner Facades

Evolutionary patterns:

• Slice and Scale
• Slice and Scatter
• Slice and Merge

Superstructure patterns:

• Device Partnership
• Product Partnership
• Begrudging Partnership

Integration Patterns

• Customer/supplier
• InnerSource
• Culture Bubble

Activity Collaboration Patterns

• Centralized Partnership
• DevOps Topologies