Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • Who ?
  • What ?
  • How ?
  • Outcomes
  • Pros

Was this helpful?

  1. Software craftsmanship
  2. Practices

Co-designs

From high level Architecture to Solution Design by working collaboratively

PreviousCode ReviewNextDesign sessions

Last updated 4 years ago

Was this helpful?

Co-construct the design of the solutions / solution architecture in order to :

  • Guarantee the quality of the deliverables

  • Be more confident on the Solution we design → "If you want to go fast, go alone. If you want to go far, go together." - African proverb

  • Their compliance with the expectations of the various technical stakeholders (Security, Ops, DB experts, ...)

Who ?

Required

  • Tech leads / team members from the teams concerned by the High Level Architecture

  • At least 1 member of the Architecture team

  • 1 facilitator

Optional

Regarding the topics other people can have a real added value :

  • Other teams representatives concerned by the High Level Architecture

  • Enterprise Architects

  • Ops

  • Security

  • Domain experts

  • Other technical experts

What ?

For each new big feature, bring together the team that will work on the topic as well as the technical experts in order to co-construct the future solution including for example :

  • Definition of the Architecture Characteristics (Non Functional Requirements)

    • Based on business needs

  • Definition of the expected logs / monitoring solution

  • Definition of the integrations

  • Data models

  • Taking into account infrastructure and security constraints

  • ...

How ?

  • Prepare the session :

    • Define the subject (the need)

    • Define the objective (the solution)

    • Prepare something to "break"

      • It can be draft of diagrams on a white-board for example

    • Identify who must / need to be there during the session

  • A session is ready when it respects the Definition Of Ready (DOR)

    • In a DOR you could find : Business capabilities concerned, Draft of API contract, Collaboration diagram depending on the topic of the session

Outcomes

  • ADR (Architecture Decision Record)

    • Explaining which decisions have been taken and why

  • Diagrams drawn and agreed during the session

    • Serve as an input for the Solution Design

  • Update of the Tech-radar (add something in Assess for example)

Pros

  • Tackle complex problems in small sessions

    • You have all the brilliant mind in the same space to solve the problems

  • Shorten feedback loops

  • Increase organizational Knowledge Sharing