> For the complete documentation index, see [llms.txt](https://yoan-thirion.gitbook.io/knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/practices/co-designs.md).

# Co-designs

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, ...)

![](/files/-MKdhcLHu1NA86b5DSTn)

### 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