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

Visualizing sociotechnical architectures with Context Maps

Visualizing sociotechnical architectures with Context Maps

When designing a system, we usually make sure to document the technical integration towards other systems. We thereby make call- or consume-relationships explicit. This approach ignores an important aspect, which often is hidden implicitly: the other teams who are owning these systems and their domain models. However, we must consider the impact of teams, organizational aspects and political dynamics.
Context Maps, are a part of strategic Domain-driven Design and aim at delivering a holistic overview over such sociotechnical architectures. They make the implicitly hidden organizational dynamics explicitly visible. This talk introduces you to the motivation and the benefit for Context Maps. It also digs deep into the patterns which explain various relationship-types between systems, teams and the associated domain models. The talk concludes with a consistent visual representation of Context Maps in practice.

Michael Plöd

February 06, 2020
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Visualizing
    Sociotechnical
    Architectures
    with
    Context Maps
    Michael Plöd

    View Slide

  2. 2
    Speaker
    Michael Plöd
    Fellow at INNOQ
    Twitter: @bitboss

    View Slide

  3. 3
    My assuptions / prerequisites
    You know about (Sub)domains, Bounded Contexts, Domain Models
    and Integration. You don’t need to be an expert.
    I will talk about
    Context Maps: their motivation, the patterns, their use cases, a
    few heuristics and how to apply them. In addition to that I will also
    look at other options.
    I will NOT talk about
    REST, WebServices, Apache Kafka, Microservices or other technical
    integration stuff.

    View Slide

  4. Get my DDD book
    cheaper
    Book Voucher: 7.99 instead of (min) 9.99
    http://leanpub.com/ddd-by-example/c/speakerdeck

    View Slide

  5. 5
    McKinsey: „At larger companies, structural issues are
    the top hurdle to meeting digital goals“
    Quelle: https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/the-digital-tipping-point-mckinsey-global-survey-results
    „Focus on organization-wide impact.
    Companies expect much of their near-
    term growth to be driven by digital, but
    impact remains elusive. What’s more,
    effective organizational structures,
    accountability, and meaningful metrics
    and incentives are largely lacking. As
    executives become more involved in
    digital efforts, they must work to
    ensure that their structures and
    business processes are set up to take
    full advantage of the opportunities that
    digital efforts offer.“

    View Slide

  6. 6
    Domain-driven Design
    contains sociotechnical aspects which
    can enable teams to be autonomous and
    to deliver value at speed by decentralizing
    governance aspects

    View Slide

  7. 7
    Centralized models lead to many dependencies

    View Slide

  8. 8
    The language for loan application form may differ
    Loan Application Form
    Loan Applications
    Loan
    Application
    Form
    Scoring
    Applicant
    Scoring Cluster
    Financial
    Situation Scoring
    Cluster
    Applied Credit
    Scoring Cluster
    Credit Decision
    Credit Decision
    Template
    Contracting
    Contract
    Proposal
    Contract

    View Slide

  9. The bounded context is
    a linguistic boundary
    around the meaning of
    a (domain) model
    9

    View Slide

  10. 10
    In an ideal world we want to align Subdomains and Bounded Contexts
    Loan Applications Scoring Credit Decision Contracting
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract

    View Slide

  11. „Team assignments
    are the first draft
    of the
    architecture”
    Michael Nygard
    Author of „Release It“
    11

    View Slide

  12. 12
    Let’s say we have a total of 50 people to build teams? How do we
    distribute them?
    Loan Applications Scoring Credit Decision Contracting
    Credit Sales
    Funnel
    Document
    Check
    Internal Scoring
    Security
    Assessment
    External Scoring
    Credit Decision Contract
    Proposal
    Contract
    Creation
    Credit
    Application
    Applicant
    Document
    Rule
    Clusters
    Securities
    External
    Rating
    Decision
    Template
    Decision
    Hierarchy
    Decision
    Contract
    Proposal
    Contract
    or

    View Slide

  13. Heuristics
    for team
    distribution
    13
    Things to keep in mind
    5-9 people per team
    Mind cognitive load of a team
    „You design it, you build it, you run it“
    Mind communication bandwith
    Take subdomains into account

    View Slide

  14. 14
    Categories for Subdomains
    Subdomain
    Core (Sub)domain
    • Most important subdomain
    • The heart of an organization’s business
    • Differentiation against competitors and
    complexity
    Supporting Subdomain
    • Vital for the operating of core (sub)domains
    • Lack of strategic relevance with regards to
    competition
    • Can be complex or simple
    Generic Subdomain
    • Needed functionality, which is not critical at all
    • „We need some solution of problem x“
    • No way to differentiate

    View Slide

  15. 15
    The categorization of subdomains should have an impact on staffing,
    make or buy decisions and even IT-procurement
    Core
    (Sub)domain
    • In-House development
    • Excellent teams with excellent working conditions
    • Staffing strategy should be „insourcing“
    • No Near- / Off-Shore development
    • No „Custom Off The Shelf“ (COTS / Standard) Software
    Supporting
    Subdomain
    • In-House development with external support is possible
    • Some Near-Shore development is an option
    • „Custom Off The Shelf“ (COTS / Standard Software) products
    that fits your processes with minor customizations
    • Avoid complete outsourcing and / or major customizations of
    COTS products
    Generic
    Subdomain
    • Look of COTS or SaaS Products that get „the task done“
    • Staffing strategy can be „outsourcing“
    • Look for cost saving opportunities
    • Don’t put your best employees into generic subdomains
    • Vendor Management is a key skill in this area
    Focus
    Cost

    View Slide

  16. Wardley Maps can also provide valuable insights
    Image Credit: https://medium.com/@rbouma/lean-agile-scotland-2016-c3756adcb18d

    View Slide

  17. Make sure that your core
    (sub)domains and / or your most
    valuable contexts in genesis and
    custom built phases are perfectly
    staffed
    17

    View Slide

  18. 18
    Fundamental Team Topologies
    Complicated Subsystem
    Enabling
    Platform
    Stream-aligned

    View Slide

  19. 19
    Subdomains + Team Topologies
    Core
    (Sub)domain
    Supporting
    Subdomain
    Generic
    Subdomain

    View Slide

  20. 20
    Coupling of bounded
    contexts
    Although bounded contexts aim for
    a high degree of decoupling there
    needs to be some kind of connection
    between:
    •The teams
    •The software
    •The business capabilities

    View Slide

  21. Team B
    Team A
    ?

    View Slide

  22. 22
    “An architect should be thinking:
    Which team interaction modes
    are appropriate for these two
    teams?
    What kind of communication do
    we need between these two
    parts of the system, between
    these two teams?“

    View Slide

  23. Team Interaction Modes
    Collaboration
    X-as-a-Service
    Facilitating
    Image taken from the Team Topologies book

    View Slide

  24. Team Interaction Modes
    Image taken from the Team Topologies book

    View Slide

  25. Context Maps aim to
    deliver a holistic overview
    with regards to coupling
    of bounded contexts
    25

    View Slide

  26. 26
    Dependencies between teams
    Team
    Dependencies
    Mutually Dependent
    • Two software artifacts or systems in two
    bounded contexts need to be delivered together
    to be successful and work.
    • There is often a close, reciprocal link between
    data and functions between the two systems.
    Free
    • Changes in one bounded context do not influence
    success or failure in other bounded contexts.
    • There is, therefore, no organizational or technical
    link of any kind between the teams.
    Upstream /
    Downstream
    • An upstream context will influence the downstream
    counterpart while the opposite might not be true.
    • This might apply to code but also on less technical
    factors such as schedule or responsiveness to
    external requests.

    View Slide

  27. 27
    Systems calling each other or consuming events
    Some Bank Schufa
    WS
    Calls a WebService
    Scoring
    Credit
    Application
    Sales Funnel
    Domain
    Event
    Consumes

    View Slide

  28. Some Bank Schufa
    WS
    Scoring
    Credit
    Application
    Sales Funnel
    Domain
    Event
    28
    The propagation of models
    Schufa
    Result
    Credit
    Application

    View Slide

  29. 29
    Teams communicating with each other
    Some Bank Schufa
    WS
    Scoring
    Credit
    Application
    Sales Funnel
    Domain
    Event

    View Slide

  30. 30
    Teams communicating with each other
    Some Bank Schufa
    WS
    We will adjust the
    interface and the
    underlying model with
    the next release.
    Ok no problem, just
    send us the
    documentation.

    View Slide

  31. 31
    Teams communicating with each other
    Scoring
    Credit
    Application
    Sales Funnel
    Domain
    Event
    We will deprecate
    the domain event and
    replace it with a new
    one.
    We have neither
    the budget, nor the
    capacity to implement
    that change.

    View Slide

  32. Schufa
    REST
    32
    Actions of one team have an impact on others
    Some Bank WS
    We will replace the
    WebService with
    RESTful Resources next
    week.
    Some Bank


    View Slide

  33. These patterns address a diverse variety of
    perspectives
    33
    The context map uses patterns to describe the
    contact between bounded contexts and teams
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Partnership
    Big Ball Of Mud

    View Slide

  34. Schufa
    OHS
    34
    Open-host Service
    WebService
    The Open-host Service is a public API
    •One API for several consumers
    •No point-to-point API
    •Has a common, general purpose model
    and functionality
    •The team providing the Open-host
    Service is an upstream team
    Bank
    A
    Bank
    B
    U
    D
    D

    View Slide

  35. 35
    Anticorruption Layer
    The Anticorruption Layer translates one
    model to another one
    •Transforms an external model from
    another team / bounded context /
    system to another internal one
    •Reduces the amount of coupling to a
    single layer
    •The team implementing an
    Anticorruption Layer is always
    downstream
    Credit Sales Funnel
    Scoring
    OHS
    ACL
    U
    D
    Credit
    Application
    Person
    Scoring
    Credit
    Scoring
    Security
    Scoring

    View Slide

  36. 36
    Conformist
    The Conformist slavishly adheres to the
    upstream model
    •There is no model-to-model
    transformation
    •Motivation: Simplicity, contracts, force
    or delight (for the upstream model)
    •The team implementing a Conformist
    is always downstream
    Credit Sales Funnel
    Scoring
    OHS
    CF
    U
    D
    Credit
    Application

    View Slide

  37. 37
    Conformist couples
    the core of your
    domain model to
    the external model
    Anticorruption
    Layer reduces
    the coupling to
    the adapters

    View Slide

  38. 38
    Heuristics for choosing a Conformist
    The degree of coupling and also connascence of a Conformist is higher
    compared to an Anticorruption Layer but there are a few situations in which a
    Conformist may still be the better choice.
    •One Bounded Context provides computations, that are highly regulated by
    legal authorities (collateral value of a real estate for example)
    •One team / Bounded Context is considered to be a specialist in
    aggregations or computations and we don’t want others to alter their
    results.

    View Slide

  39. 39
    Shared Kernel
    Shared Kernel is a subset of a domain
    model that two teams share
    •„Physically“ shared artifact between
    two teams
    •Examples: shared JARs or database
    •High degree of coupling requires a high
    amount of coordination between the
    involved teams
    •Shared Kernel is no Anti-Pattern but
    use with caution
    Credit Sales Funnel
    Scoring
    Credit
    Application
    SK

    View Slide

  40. 40
    Heuristics for Shared Kernels
    A Shared Kernel introduces a high degree of coupling between the teams and
    their software and is, therefore, often considered not to be a good option.
    However, there are situations in which a Shared Kernel may be a good idea:
    •One team is responsible for two or more bounded contexts which have an
    overlap in terms of language
    •Strictly avoid a Shared Kernel when two teams are in a competitive
    situation or where a lot of backdoor politics are being played
    •When two teams have a Shared Kernel, they should form a Partnership…

    View Slide

  41. Scoring
    Credit
    Sales
    Funnel
    41
    Partnership
    Partnership is about cooperative
    relationships between teams
    •Establishes a process for coordinated
    planning of development and joint
    management of integration
    •Not technical at all, Partnership is
    plain organizational
    •Recommended for teams which
    depend on a Shared Kernel
    We want to adjust
    something
    Ok, let’s
    coordinate
    our efforts

    View Slide

  42. 42
    Customer-Supplier
    A Customer-Supplier development gives
    the downstream team some influence
    •Downstream requirements factor into
    upstream planning. Therefore, the
    downstream team gains some
    influence over the priorities and tasks
    of the upstream team
    •Customer-Supplier is organizational
    •Mind „vetoing customer“ and customer
    against an OHS as anti-patterns
    Credit Sales Funnel
    Scoring
    CUS
    SUP
    U
    D
    We need
    more fields in the
    application
    Ok

    View Slide

  43. 43
    Separate Ways
    A bounded context has no connections to
    others
    •Sometimes integration is too
    expensive or takes very long
    •The teams choose separate ways in
    order to focus on specialized solutions
    •Interesting pattern for minimum viable
    products or organizational solutions in
    uncertain market conditions
    Credit Sales Funnel
    Contract Offering and
    Creation
    Manual process for
    entering credit
    application data in
    contract
    SW

    View Slide

  44. 44
    Published Language
    A well documented language shared
    between bounded contexts
    •Every bounded context can translate
    in and out from that language
    •Sometimes defined by a consortium of
    the most important stakeholders /
    teams
    •Often combined with Open-host
    Service
    •Examples: iCalendar, vCard, ZugFerd
    Credit Sales Funnel
    Credit
    Application
    Scoring
    Real
    Estate
    Rating
    Contract
    Proposal
    PL

    View Slide

  45. Core Banking System
    45
    Big Ball Of Mud
    A (part of a) system which is a mess by
    having mixed models and inconsistent
    boundaries
    •Don’t let the (lousy) model of the Big
    Ball Of Mud propagate into your
    context
    •Anticorruption Layer is the pattern of
    choice on the downstream
    •Demarcation of bad model or system
    quality
    BBoM
    Contract Creation
    ACL

    View Slide

  46. 46
    The patterns address various aspects
    Team
    Relationships
    Model
    Propagation
    API / „technical“
    Open-host Service (✅) ✅
    Anticorruption Layer ✅
    Conformist ✅
    Shared Kernel ✅ (✅)
    Partnership ✅
    Customer-Supplier ✅
    Separate Ways ✅ (✅)
    Published Language ✅ (✅)
    Big Ball Of Mud ✅

    View Slide

  47. 47
    Some of the patterns reflect team relationships
    Team
    Relationships
    Mutually Dependent
    • Partnership
    • Shared Kernel
    Free
    • Separate Ways
    • Published Language
    Upstream /
    Downstream
    • Customer-Supplier
    • Anticorruption Layer
    • Conformist
    • Open-host Service

    View Slide

  48. 48
    Mind team communication
    Team
    independence
    Tight Coupling /
    Integration
    Shared Kernel
    Customer / Supplier
    Conformist
    Anticorruption Layer
    Separate Ways
    Open / Host Service
    Published Language
    Team
    Communication

    View Slide

  49. 49
    System ABC
    Upstream
    Downstream
    System Y
    Open Host Service
    Anticorruption Layer
    You can visualize
    different perspectives
    Customer
    Supplier
    • Call Relationship
    • Team Relationship - Level 1
    • API Level
    • Model Propagation
    • Team Relationship - Level 2

    View Slide

  50. Ask those
    questions
    50
    Subdomain categories and the context map
    Should a generic or supporting subdomain be a
    customer for a supplier in a core domain?
    Should a core domain conform to the model of a
    generic or supporting subdomain?
    How do we deal with a Big Ball Of Mud in a core
    domain? Conform to it in the other categories?
    Do we want Partnerships or mutually dependent
    teams between core and the other subdomains?

    View Slide

  51. 51
    Also look at bounded context model traits
    Influence of an
    Octopus Enforcer?
    Bubble Context for
    Bubble Context?
    Mind the Enterprise
    Integration Patterns!

    View Slide

  52. Some examples in
    which Context Maps
    make implicit issues
    explicit
    52

    View Slide

  53. 53
    System ABC
    Open Host Service
    Upstream
    Downstream
    System X
    Anticorruption Layer
    System Y
    Anticorruption Layer
    System Z
    Anticorruption Layer
    POLITICAL
    FOUL PLAY
    „Vetoing“ Customer
    „Helpless“ Supplier

    View Slide

  54. 54
    The model propagation from hell
    U
    D
    D U
    U
    D
    Credit
    Application
    Scoring
    Credit
    Agency
    Customer
    Customer
    Contact
    O
    H
    S
    C
    F
    S
    K
    CF
    ACL
    OHS
    O
    H
    S
    Rating
    Model
    Customer
    Model

    View Slide

  55. 55
    Context Map
    Scenarios
    Taken from my Domain-driven
    Design book
    •These scenarios showcase various
    options / alternatives
    •Domain: retail mortgage loans
    •https://www.leanpub.com/ddd-
    by-example

    View Slide

  56. 56
    How teams gain influence

    View Slide

  57. 57
    Degrading influence of a team

    View Slide

  58. 58
    Using a Published Language

    View Slide

  59. 59
    Dealing with a Big Ball Of Mud

    View Slide

  60. 60
    Where should context maps help?
    Governance
    A Context Map helps to identify governance issues
    between applications and teams.
    Transformation
    A Context Map is an excellent starting point for future
    transformations: it gives an in-depth insight into
    integration aspects and subdomain / context relations
    Bad Models
    By introducing a Context Map we get a clear view
    on where and how bad models propagate through
    application landscapes
    Politics
    By not just looking at technical integration aspects
    the Context Map also helps us in seeing how teams
    communicate and „play politics“.

    View Slide

  61. 61
    Context Map
    The context map is a powerful tool
    for
    •making implicitly hidden
    organizational processes visible
    •identify the flow of bad domain
    models
    •establishing a decentralized
    governance model
    •PS: managers LOVE context
    maps ;-)

    View Slide

  62. Get my DDD book
    cheaper
    Book Voucher: 7.99 instead of (min) 9.99
    http://leanpub.com/ddd-by-example/c/speakerdeck

    View Slide

  63. Krischerstr. 100
    40789 Monheim am Rhein
    Germany
    +49 2173 3366-0
    Ohlauer Str. 43
    10999 Berlin
    Germany
    +49 2173 3366-0
    Ludwigstr. 180E
    63067 Offenbach
    Germany
    +49 2173 3366-0
    Kreuzstr. 16
    80331 München
    Germany
    +49 2173 3366-0
    Hermannstrasse 13
    20095 Hamburg
    Germany
    +49 2173 3366-0
    Gewerbestr. 11
    CH-6330 Cham
    Switzerland
    +41 41 743 0116
    innoQ Deutschland GmbH innoQ Schweiz GmbH
    www.innoq.com
    63
    Thank you!
    Michael Plöd
    Follow me on Twitter: @bitboss

    View Slide