Effective architecture requires both the right organizational structures and the right decision-making processes. This article explores how architecture guilds and tribes enable architectural alignment, and compares two essential decision-making tools: Architecture Decision Records (ADRs) and Request for Comments (RFCs).

Organizational Structures: Guilds and Tribes

The Spotify Model

The Spotify model provides a scalable organizational framework that balances autonomy with alignment. While originally designed for product teams, its principles apply equally well to architecture governance.

Squads

Squads are small, cross-functional product teams (typically 6-10 people) that own a specific problem space. Each squad includes:

• Product owner
• Designers
• Engineers (frontend, backend, mobile)
• Data analysts

Key Characteristics:

• Autonomous and self-organizing
• Owns a specific product area or feature
• Has clear goals and success metrics
• Can deploy independently

Tribes

Tribes are collections of related squads (typically 40-150 people) organized around a product area or value stream. Tribes are led by a Tribe Lead who:

• Provides vision and strategic direction
• Creates enabling conditions for squads
• Removes impediments
• Ensures alignment across squads

Key Characteristics:

• Multiple squads working on related products
• Shared infrastructure and platforms
• Common goals and metrics
• Regular tribe-wide communication

Chapters

Chapters are discipline-based groups that cut across squads within a tribe. Examples include:

• Backend engineers chapter
• Frontend engineers chapter
• Designers chapter
• Data engineers chapter

Key Characteristics:

• People management and career development
• Craft leadership and skill development
• Knowledge sharing within discipline
• Standardization of practices

Guilds

Guilds are voluntary communities of practice that span the entire organization. They bring together people with shared interests regardless of their squad, tribe, or chapter affiliation.

Key Characteristics:

• Voluntary participation
• Cross-organizational knowledge sharing
• Informal learning and collaboration
• No formal reporting structure

Architecture Guilds

An Architecture Guild is a specialized guild focused on architectural concerns. It typically includes:

• Architects from different tribes
• Senior engineers with architectural responsibilities
• Technical leads
• Platform engineers

Purpose:

• Establish architectural principles and standards
• Review and approve architectural decisions
• Share architectural knowledge and patterns
• Resolve architectural conflicts between teams
• Guide technology choices and migrations

Activities:

• Regular meetings to discuss architectural topics
• Review of ADRs and RFCs
• Architecture decision forums
• Knowledge sharing sessions
• Architecture documentation and guidelines

Architecture Tribes

An Architecture Tribe (or Architecture Chapter within a tribe) focuses on architectural concerns within a specific domain or product area. This structure ensures:

• Domain-specific architectural expertise
• Alignment with product goals
• Close collaboration with product teams
• Practical application of architectural principles

Decision-Making Tools: ADR vs RFC

While guilds and tribes provide organizational structure, ADRs and RFCs provide processes for making and documenting architectural decisions.

Architecture Decision Records (ADR)

An Architecture Decision Record is a document that captures a single architectural decision that has been made, along with its context and consequences.

Structure

A typical ADR includes:

• Status: Proposed, Accepted, Deprecated, Superseded
• Context: The situation and problem that led to this decision
• Decision: What was decided
• Consequences: Positive and negative impacts
• Alternatives Considered: Other options that were evaluated

Characteristics

• Retrospective: Documents decisions that have already been made
• Immutable: Once written, ADRs are not changed (new decisions create new ADRs)
• Historical Record: Provides a timeline of architectural evolution
• Concise: Focuses on the decision, not the discussion

When to Use ADRs

• Documenting decisions that have already been made
• Creating a historical record of architectural choices
• Explaining why certain approaches were chosen
• Onboarding new team members
• Auditing architectural decisions

Example ADR Topics

• “ADR-001: Use PostgreSQL instead of MySQL”
• “ADR-002: Implement microservices architecture”
• “ADR-003: Adopt GraphQL for API layer”
• “ADR-004: Use Kubernetes for container orchestration”

Request for Comments (RFC)

A Request for Comments is a document that proposes a solution to a problem and invites discussion and feedback before a decision is made.

Structure

A typical RFC includes:

• Summary: Brief overview of the proposal
• Motivation: Why this change is needed
• Proposed Solution: Detailed description of the proposed approach
• Alternatives Considered: Other options and why they were rejected
• Open Questions: Issues that need discussion
• Implementation Plan: How the solution would be implemented

Characteristics

• Prospective: Proposes solutions before decisions are made
• Collaborative: Invites feedback and discussion
• Exploratory: May propose multiple solutions for comparison
• Comprehensive: Includes detailed analysis and reasoning

When to Use RFCs

• Proposing significant architectural changes
• Exploring multiple solution options
• Gathering input from multiple stakeholders
• Documenting complex technical proposals
• Making decisions that affect multiple teams

Example RFC Topics

• “RFC-001: Migration to microservices architecture”
• “RFC-002: Adoption of event-driven architecture”
• “RFC-003: Standardizing API design patterns”
• “RFC-004: Database sharding strategy”

ADR vs RFC: Key Differences

Aspect	ADR	RFC
Timing	Documents decisions already made	Proposes solutions before decisions
Purpose	Historical record	Discussion and decision-making
Audience	Future readers, auditors	Decision-makers, stakeholders
Scope	Single decision	May explore multiple options
Mutability	Immutable (new decisions = new ADRs)	Evolves through discussion
Detail Level	Concise, focused	Comprehensive, exploratory
Outcome	Decision documented	Decision to be made

Complementary Workflow

ADRs and RFCs work best when used together in a structured workflow:

1. RFC Phase: Exploration and Discussion

1. Write RFC: Document the problem, proposed solutions, and alternatives
2. Review Period: Allow 1-2 days for async review and comments
3. Discussion Meeting: Hold focused meeting (30-60 minutes) to discuss
4. Iterate: Update RFC based on feedback if needed

2. Decision Phase: Making the Choice

1. Decision Meeting: Architecture guild or relevant stakeholders make decision
2. Document Decision: Capture the chosen solution and rationale

3. ADR Phase: Documentation

1. Write ADR: Document the decision on the same day it’s made
2. Link to RFC: Reference the RFC that led to this decision
3. Update Status: Mark RFC as “Accepted” or “Rejected”

Benefits of Combined Approach

• Transparency: RFCs ensure all stakeholders understand proposals
• Documentation: ADRs provide clear historical record
• Efficiency: RFCs enable async review before meetings
• Accountability: ADRs document who decided what and why
• Learning: Both documents serve as learning resources

Best Practices

For Architecture Guilds

1. Regular Meetings: Schedule consistent meetings (e.g., bi-weekly)
2. Clear Agenda: Focus on architectural decisions and reviews
3. Documentation: Maintain ADR and RFC repositories
4. Communication: Share decisions widely across organization
5. Evolution: Allow guild structure to evolve with organization

For ADRs

1. Write Promptly: Document decisions immediately after they’re made
2. Be Specific: Focus on single, clear decisions
3. Include Context: Explain the situation that led to the decision
4. Track Status: Keep ADR status current (Accepted, Deprecated, Superseded)
5. Link Related: Reference related ADRs and RFCs

For RFCs

1. Be Comprehensive: Include enough detail for informed discussion
2. Propose Alternatives: Always include alternative approaches
3. Set Review Period: Define clear timeline for feedback
4. Respond to Feedback: Address comments and questions
5. Close the Loop: Update RFC status and create ADR after decision

Common Patterns

Pattern 1: RFC → ADR

Most common workflow:

1. Team writes RFC proposing architectural change
2. Architecture guild reviews RFC
3. Decision made in guild meeting
4. ADR written documenting the decision
5. RFC marked as “Accepted” with link to ADR

Pattern 2: ADR Only

For smaller, localized decisions:

1. Team makes decision
2. ADR written immediately
3. Shared with relevant stakeholders
4. No RFC needed for low-impact decisions

Pattern 3: Multiple RFCs → Single ADR

When exploring multiple approaches:

1. Multiple RFCs written exploring different solutions
2. Architecture guild reviews all RFCs
3. Single decision made
4. One ADR documents chosen solution
5. Other RFCs marked as “Rejected” or “Superseded”

Tools and Templates

ADR Template

# ADR-XXX: [Title]

## Status
Accepted | Deprecated | Superseded

## Context
[Describe the situation and problem]

## Decision
[Describe the decision that was made]

## Consequences
### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Drawback 1]
- [Drawback 2]

## Alternatives Considered
- [Alternative 1]: [Why it was rejected]
- [Alternative 2]: [Why it was rejected]

## References
- Related RFC: [RFC-XXX]
- Related ADRs: [ADR-YYY]

RFC Template

# RFC-XXX: [Title]

## Summary
[Brief overview of the proposal]

## Motivation
[Why this change is needed]

## Proposed Solution
[Detailed description of the proposed approach]

## Alternatives Considered
- [Alternative 1]: [Pros/cons, why not chosen]
- [Alternative 2]: [Pros/cons, why not chosen]

## Open Questions
- [Question 1]
- [Question 2]

## Implementation Plan
[How the solution would be implemented]

## References
- Related ADRs: [ADR-YYY]
- Related RFCs: [RFC-ZZZ]

Conclusion

Architecture guilds and tribes provide the organizational structure needed for architectural alignment, while ADRs and RFCs provide complementary processes for decision-making and documentation. By combining these approaches:

• Guilds enable cross-organizational architectural alignment
• Tribes ensure domain-specific architectural expertise
• RFCs facilitate collaborative decision-making
• ADRs provide historical documentation

Organizations that effectively combine these structures and processes create environments where architectural decisions are transparent, well-documented, and aligned with organizational goals. The key is to use the right tool at the right time: RFCs for exploration and discussion, ADRs for documentation and historical record.

References

• Spotify Engineering Culture
• Architecture Decision Records
• RFC Process
• How to Make Architecture Decisions: RFCs, ADRs, and Getting Everyone Aligned