Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Traditionally software architecture focuses on designing software systems to provide value to customers. In most organizations there is little emphasis on the design of the organizational structure that will implement and own such technical architecture.

However, in our very competitive and fast moving world this can be a major drawback. We cannot design software systems at high-velocity without considering the organization that will deliver and own them. Architecture must be a co-design activity, considering organizational and software systems aspects. This is what Sociotechnical Architecture aims at.

In this talk I am going to show you what Sociotechnical Architecture is; why it is extremely relevant; and will also inspire you with several examples and patterns. My goal is to make clear that we must always consider these two dimensions to be able to maximize our impact and be able to achieve high-velocity on our product development.

Presentation video here: https://youtu.be/ekMPm78KFj0

Eduardo da Silva

May 28, 2020
Tweet

More Decks by Eduardo da Silva

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. @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

  4. @emgsilva
    @emgsilva
    Trait 1: Your staff defines 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

  5. @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

  6. @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

  7. @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

  8. @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

  9. @emgsilva
    @emgsilva
    Trait 1: Your staff defines your
    cooking and experiences
    Trait 2: Chefs cannot cook, serve and do the dishes at
    the same time...
    Trait 3: Kitchen + Serving + Wine + ... = Restaurant
    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

  10. @emgsilva
    @emgsilva
    Trait 1: Your staff defines your
    cooking and experiences
    Trait 2: Chefs cannot cook, serve and do the dishes at
    the same time...
    Trait 3: Kitchen + Serving + Wine + ... = Restaurant
    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

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

    View Slide

  12. @emgsilva
    @emgsilva
    Definition: 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

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

    View Slide

  14. @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

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

    View Slide

  16. @emgsilva
    @emgsilva
    Trait 1: Your staff defines 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

  17. @emgsilva
    @emgsilva
    Trait 1: Your staff defines your cooking and experiences
    >> 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

  18. @emgsilva
    @emgsilva
    Trait 1: Your staff defines your cooking and experiences
    >> 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

  19. @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

  20. @emgsilva
    @emgsilva
    Trait 2: Chefs cannot cook, serve and do the dishes at the same time…
    >> Team Cognitive Load
    Goal: Maximize capacity for “Germane” Cognitive Load!
    Credits: Team Topologies

    View Slide

  21. @emgsilva
    @emgsilva
    Trait 2: Chefs cannot cook, serve and do the dishes at the same time…
    >> Team Cognitive Load
    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

  22. @emgsilva
    @emgsilva
    Trait 3: Kitchen + Serving + Wine + ... = Restaurant
    >> 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

  23. @emgsilva
    @emgsilva
    Trait 3: Kitchen + Serving + Wine + ... = Restaurant
    >> Teams Boundaries & Interactions
    Goal: maximize Stream
    Aligned Teams available
    Cognitive Load
    Credits: Team Topologies

    View Slide

  24. @emgsilva
    @emgsilva
    Trait 3: Kitchen + Serving + Wine + ... = Restaurant
    >> 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

  25. @emgsilva
    @emgsilva
    Trait 4: don’t hand recipes to your chefs…
    >> 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

  26. @emgsilva
    @emgsilva
    Trait 4: don’t hand recipes to your chefs…
    >> 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

  27. @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

  28. @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
    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

  29. @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
    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

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

    View Slide

  31. @emgsilva
    @emgsilva
    typical phases of
    (sociotechnical)
    architecture

    View Slide

  32. @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

  33. @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

  34. @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

  35. @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

  36. @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

  37. @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

  38. @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

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

    View Slide

  40. @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