Architecture in the Open: A Hands-On RFC and ADR Workshop

​📍ROOM 4.1

​Architecture is often treated as something produced by architects.
A difficult technical problem appears, a small group discusses it, a decision is made, and eventually the rest of the organization receives a diagram or implementation plan.

The result may be technically correct, but important context frequently disappears.

- Why was this option chosen?
- What alternatives were considered?
- Which assumptions mattered?
- What happens when those assumptions change?

Open-source communities have developed another way of making complex technical decisions: proposals are made visible, people contribute asynchronously, alternatives are debated, maintainers guide the process, and decisions remain accessible after the discussion ends.

In this workshop, participants will experience a lightweight version of that process.

They will receive a realistic architecture scenario involving an AI-enabled product with competing requirements around privacy, cost, scalability, vendor dependency, operational complexity, and speed of delivery.

Working in small groups, participants will:

- identify the important architectural constraints
- formulate an architecture proposal using a lightweight RFC
- describe alternatives and explicit trade-offs
- review another team's proposal
- respond to questions and challenges
- revise their solution
- document the resulting decision using an Architecture Decision Record.

We will then compare the approaches and discuss not only the architectures themselves, but the decision-making process that produced them.

The workshop is designed to demonstrate that architecture does not need to be either centralized or chaotic.

By creating clear contribution mechanisms, transparent decisions, and lightweight governance, organizations can involve more people in architectural thinking without turning every technical choice into a committee meeting.

Learning outcomes

Participants will leave able to:

- facilitate a lightweight architectural RFC process
- structure architecture discussions around constraints and trade-offs
- write useful Architecture Decision Records
- review architecture proposals constructively
- separate architectural authority from architectural gatekeeping
- preserve the context behind technical decisions
- adapt open-source collaboration practices to internal engineering teams.

Workshop structure

Part 1 — The challenge

Introduction to the scenario, constraints, and decision-making framework.

Part 2 — RFC

Teams create a short architecture proposal covering:
- problem and context
- constraints
- proposed solution
- alternatives
- trade-offs
- unresolved questions.

Part 3 — Open review

Teams exchange RFCs and act as reviewers.
Reviewers challenge assumptions, identify risks, and suggest alternatives.

Part 4 — Decision

Teams incorporate feedback and document their final choice using a lightweight ADR.

Part 5 — Retrospective

We compare solutions and discuss:
- what changed because of review
- where architectural disagreements emerged
- how decision ownership should work
- how this process can scale inside real organizations.

Suggested audience

Software architects, senior engineers, tech leads, engineering managers, CTOs, platform teams, and developers who participate in technical decision-making.

No specific programming language or technology stack is required.