Intro to Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact

@emgsilva
Sociotechnical Architecture:
co-designing technical & organizational
architecture to maximize impact
Eduardo da Silva
@emgsilva | [email protected] | esilva.net

View Slide

@emgsilva
@emgsilva
LEt’s talk about Restaurants...

View Slide

@emgsilva
@emgsilva
Important ”traits” to look for
when setting up a Restaurant for
success*
* Success ⇒ defined clear business goal & mission (the direction for our developments)
Please do not “blindly” follow my recommendations
to open your restaurant

View Slide

@emgsilva
@emgsilva
Trait 1: Your staff deﬁnes your cooking and
experiences
If you want an amazing French food and
drink experience you need to have
French chefs and French wine experts;
and they have to work together to come
up with great combinations

View Slide

@emgsilva
@emgsilva
Trait 2: Chefs cannot cook, serve and do the dishes at
the same time...
If you want to run your restaurant
smoothly and have a strong team for
a long time, you need to have
enough people and skill to support
the different tasks without having
people “burning out” (or leaving)

View Slide

@emgsilva
@emgsilva
Trait 3: Kitchen + Serving + Wine + ... = Restaurant
Your restaurant has different
parts and people working on them
(in parallel); however, you want
to understand and optimize how it
all comes together in order to
maximize your “product” (value to
customer)

View Slide

@emgsilva
@emgsilva
Trait 4: don’t hand recipes to your chefs… Empower
them to discover new recipes
Do you want to achieve unique
experiences (and value exchange) for
your customers? Then enable your crew
to "experiment & discover" how to
maximize that!

View Slide

@emgsilva
@emgsilva
Trait 5: because #1 restaurant does something it does
not mean it will work for you and your crew
Your restaurant will have
specific constraints, context,
mission, etc. Understand those
elements and design your
restaurant from there!

View Slide

@emgsilva
@emgsilva
Trait 1: Your staff deﬁnes your
cooking and experiences
the same time...
Trait 4: don’t hand recipes to your chefs…
Empower them to discover new recipes
Trait 5: because #1 restaurant does something it
does not mean it will work for you and your
crew

View Slide

@emgsilva
@emgsilva
Trait 1: Your staff deﬁnes your
cooking and experiences
the same time...
Trait 4: don’t handle recipes to your chefs…
Empower them to discover new recipes
Trait 5: because #1 restaurant does something it
does not mean it will work for you and your
crew
These traits revolve a lot around “people”
and “organization”... and how to have
an holistic approach to design

View Slide

@emgsilva
@emgsilva
This is
Sociotechnical
Architecture!
Credit: Nick Tune, KanDDDinsky 2018

View Slide

@emgsilva
@emgsilva
Deﬁnition: Sociotechnical architecture
“Sociotechnical Architecture is
about taking an holistic co-design
approach to technical and
organizational systems, given the
inherent impact they have on each
other.” --Eduardo da Silva
Source: Sociotechnical Architecture Definition thread
“When we are architecting a software
system, we must consider the impact
on the teams in the organisation and
vice-versa.” --Nick Tune

View Slide

@emgsilva
@emgsilva
Nick Tune’s Sociotechnical Evolution (Loop)
Credits: Primary Sociotechnical Design Heuristics, Nick Tune

View Slide

@emgsilva
@emgsilva
STOP to just focus on
the systems of software;
teams are equally important, they listen to
the customer and build product

View Slide

@emgsilva
@emgsilva
“why” are Sociotechnical
traits important And “How” to
address them
(...to build software products & teams who
build them)

View Slide

@emgsilva
@emgsilva
Trait 1: Your staff deﬁnes your cooking and experiences
>> Conway’s Law
Any organization that designs a system
(defined broadly) will produce a design
whose structure is a copy of the
organization's communication structure.
-- Melvin E. Conway
In a nutshell: “Software systems
architecture always follows organization
systems architecture”

View Slide

@emgsilva
@emgsilva
>> Conway’s Law
Conway's Law is unavoidable!
If you don't explicitly
address it, it will
organically reveal itself…
…and (in many cases) HR (as
org designers) become the
accidental architects of our
software systems
Credit: Accidental Architects - how HR designs software systems, Team Topologies

View Slide

@emgsilva
@emgsilva
>> Conway’s Law
Design an organization that mirrors
your desired system architecture.
How? => Inverse Conway Maneuver*
- What system Architecture we want?
(think business/product mission/goals; enable
high velocity and autonomy for team; etc.)
- What is the team/org arrangement we
need to make it happen?
* Credit: James Lewis

View Slide

@emgsilva
@emgsilva
Trait 2: Chefs cannot cook, serve and do the dishes at the same time…
>> Team Cognitive Load
“Software that fits in your (team)
head(s)” --Daniel Terhorst-North
“We should be thinking about limiting the
size of software, services, and products
to the cognitive load that the team can
handle…” --Team Topologies
Credits: Team Topologies

View Slide

@emgsilva
@emgsilva
Goal: Maximize capacity for “Germane” Cognitive Load!

View Slide

@emgsilva
@emgsilva
Team Topologies’ “Team-first” approach:
- Before jump into implementing the
“dream technical architecture”, check
the team(s) can successfully build &
own it
- Namely: do they have enough cognitive
load available?* If the answer is “No”
and you do nothing, YOU will fail!
Credits: Team Topologies | * Team Topologies provides tools for assessing Cognitive Load on team

View Slide

@emgsilva
@emgsilva
>> Teams Boundaries & Interrelations
Effective Teams cannot have “a lot people”*:
- ~5: close personal relationship & working
memory (~> team)
- ~15: can experience deep trust (~> closely
related teams)
- ~50: can have mutual trust (~> directly
related teams or product)
- ~150: can remember (~> department/domain)
* From Team Topologies, based on Dunbar’s number & observations from typical team < family < department sizes

View Slide

@emgsilva
@emgsilva
>> Teams Boundaries & Interactions
Goal: maximize Stream
Aligned Teams available
Cognitive Load

View Slide

@emgsilva
@emgsilva
>> Teams Boundaries & Interactions
Team Topologies “team + interaction
types” don’t necessarily address the
“discovery of proper team boundaries”
This can be done in different manners,
Domain-Driven Design (DDD) provides
excellent mechanisms for these
activities.

View Slide

@emgsilva
@emgsilva
>> Continuous Discovery & Delivery in team
Product team should be
empowered to continuously
discover (brainstorm) new ways
to make the product better
(bottom-up / emergent)
…while aligning with
overarching org strategies
(top-down, multi-product/team)
Credits: 2020 Product Management Insights Report, Alpha

View Slide

@emgsilva
@emgsilva
>> Continuous Discovery & Delivery in team
Enable your team to be
continuously on Discovery &
Delivery mode* (a.k.a.:
“Dual-Track Agile”)
This is a capability/skill
that should exist in the team
* “Dual-Track Agile” | Image credit: Nick Tune

View Slide

@emgsilva
@emgsilva
Trait 5: because #1 restaurant does something it does not mean it will work for you and your crew
>> Understand your context & design based on that
Credits: Tweet Thread
Your organization has a
particular context that
need to be taken into
account when designing your
Sociotechnical Architecture
Don’t just copy Spotify!

View Slide

@emgsilva
@emgsilva
Don’t (just) do Analogy (copy
Spotify).
Apply First Principles Thinking:
boil things down to their
“fundamental truths” and from
there design solutions for your
specific challenge

View Slide

@emgsilva
@emgsilva
Fact: organizations are continuously
changing… so should your
sociotechnical architecture
Listen for the signals and act
Create an Operating Model that
embraces change and improvement
(Continuous Change / Continuous
Improvement => CC/CI)

View Slide

@emgsilva
@emgsilva
Sociotechnical Architecture
>> (small) Howto / State-of-the-art*
* Work-In-Progress (WIP)

View Slide

@emgsilva
@emgsilva
typical phases of
(sociotechnical)
architecture

View Slide

@emgsilva
@emgsilva
Design (sub-domains and their
relations) the “to-be architecture”;
to best realize the business goals
Define sub-domains/parts do
you want to invest on; and the
most suitable org design /
teams setup
Go into tactical mode in each part
of your architecture (and their
teams) and get clarity about their
relation and how to implement it
Align the business priorities
and mission and get a clear
understanding of your domain
(where are you; and where you
want to go)
typical phases of (sociotechnical) architecture
Remarks: greenfield,
brownfield, etc.,
products/orgs will
require different flows
& emphasis per phase
You will go back and
forth; 2 <-> 3 is
particularly interesting
for sociotechnical
optimization (tech + org
arch)
1: Align & Understand 2: Strategic Architecture
3: Strategy & Org Design 4: Tactical Architecture

View Slide

@emgsilva
@emgsilva
“Domain-Driven Design Starter Modelling Process”
github.com/ddd-crew/ddd-starter-modelling-process
Domain-Driven
Design (DDD) mixed
with several other
elements (Team
Topologies, Wardley
Maps, product
thinking, etc)
Great start for
Sociotechnical
Architecture design
1: Align & Understand 2: Strategic Architecture
3: Strategy & Org Design 4: Tactical Architecture

View Slide

@emgsilva
@emgsilva
1: Align & Understand / Event-Storming
Focus: collaboratively (no technical
barriers) discover & create “big
picture” shared understanding of the
domain; involve “everyone with
knowledge”
Image from: https://medium.com/@springdo/a-facilitators-recipe-for-event-storming-941dcb38db0d
Event Storming,
Alberto
Brandolini

View Slide

@emgsilva
@emgsilva
2: Strategic Architecture / Context Maps
Focus: understand the parts
(bounded contexts) we have
and how they relate with each
other
Credits: https://github.com/ddd-crew/context-mapping - Michael Plod

View Slide

@emgsilva
@emgsilva
Focus: visualize perform all
sorts of analysis and strategy:
portfolio overview,
dependencies, team setup, etc.
3: Strategy & Org Design / Core Domain Chart
Credits: https://github.com/ddd-crew/core-domain-charts - Nick Tune
Core, Supporting and Generic
are types of domains in DDD

View Slide

@emgsilva
@emgsilva
4: Tactical Architecture / Bounded-Context Canvas
Focus: provide a
clear template to
design and document
the design of a each
bounded context.
This enables to have
a clear overview of
the main aspects
relevant to a
bounded context.
Credits: https://github.com/ddd-crew/bounded-context-canvas - Nick Tune

View Slide

@emgsilva
@emgsilva
Books
(the team organizational -
topologies/interrelations
aspects)
(the metrics to track and
optimize for when building
and scaling tech org)
(the foundations to
strategically arrange our
org domains, sub-domains
and their relations)
(collaborative discovery
and understanding of your
domain and its parts)

View Slide

@emgsilva
@emgsilva
Thank you!
More on this in:
http://esilva.net/sociotechnical
@emgsilva | esilva.net | [email protected]

View Slide

@emgsilva
@emgsilva
Other great resources
(https://github.com/ddd-crew: a lot of
resources for Strategic DDD and
Sociotechnical Architecture)
(Nick Tune’s overview
of resources and how
to use them to develop
your Sociotechnical
Architecture [link])
(Michael Plod’s
overview on the use of
Context Maps to
visualize
Sociotechenical
Architectures [link])
(Patterns for teams
topologies, especially
DevOps teams [link])

View Slide

Intro to Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact

Intro to Sociotechnical Architecture: co-designing technical & organizational architecture to maximize impact

Eduardo da Silva

More Decks by Eduardo da Silva

Other Decks in Technology

Featured

Transcript