Architecture Decisions & Leadership

Architect Responsibilities

1. Make Architecture Decisions - Define decisions and principles guiding technology choices
2. Continually Analyze - Assess architecture vitality as business and technology change
3. Keep Current - Stay updated on technical and industry trends
4. Ensure Compliance - Verify teams follow defined decisions and principles
5. Understand Technologies - Technical breadth over depth
6. Know the Business - Understand domain, problems, goals, requirements
7. Lead Teams - Exceptional interpersonal skills: teamwork, facilitation, leadership
8. Navigate Politics - Negotiation skills to get decisions approved

Decision-Making

Architectural Decision Antipatterns

1. Covering Your Assets

Fear of being wrong prevents making decisions.

2. Groundhog Day

Decisions get revisited repeatedly because people don’t know why they were made.

3. Email-Driven Architecture

Decisions lost, forgotten, or unknown.

Architectural Significance

A decision is architecturally significant if it affects:

• Structure (patterns/styles)
• Characteristics (performance, scalability)
• Dependencies (coupling)
• Interfaces (access/orchestration)
• Construction techniques (platforms, frameworks, tools)

Architectural Decision Records (ADRs)

Structure

Title: Numbered sequentially with short phrase

• Example: “42. Use Asynchronous Messaging Between Order and Payment Services”

Approval Criteria:

• Cost thresholds (e.g., >$5K requires review)
• Cross-team impact
• Security implications

Context: Forces at play

• Specific circumstances
• Possible alternatives
• Area affected

Decision: Affirmative, commanding voice

• Example: “We will use asynchronous messaging between services.”
• Include full justification. Why > How

Consequences: Overall impact (pros and cons)

• Example: Better responsiveness (25ms vs 3,100ms) but complex error handling

Compliance: How will it be measured and governed?

• Manual checks

  Automated fitness functions

  Tools (ArchUnit, NetArchTest)

Notes: Metadata

• Author

  Approval date

  Approved by

  Last modified

  Superseded date

Storage

Store in dedicated repository or wiki accessible to all stakeholders.

Team Leadership

Making Teams Effective

Collaboration: Break down architect/developer barriers. Form strong bidirectional relationships. Architecture changes every iteration—tight collaboration essential.

Constraints & Boundaries: Create appropriate constraints forming a “room” for teams. Provide right level of guidance—not too much, not too little.

Architect Personalities

Control-Freak Architect: Too fine-grained decisions, tight boundaries, too many constraints → teams lose autonomy

Armchair Architect: Disconnected, no implementation details, loose boundaries → teams do architect’s work

Effective Architect: Appropriate constraints, ensures collaboration, right guidance level, removes roadblocks

Elastic Leadership

How involved should you be? Consider:

Team Familiarity: Better they know each other → less involvement

Project Duration: Longer → more involvement over time

Team Warning Signs

Process Loss (Brooks’s Law):

“Adding manpower to a late software project makes it later.”

– Fred Brooks, The Mythical Man-Month (1975)

When communication overhead exceeds productivity gains from additional people.

• Indicators: Frequent merge conflicts, working on same code, getting in each other’s way
• Solution: Find parallelism; avoid adding people without parallel work available

Pluralistic Ignorance (social psychology concept):

Everyone privately rejects a norm but assumes others accept it, so publicly goes along.

• Example: Team thinks daily standups are waste of time but nobody speaks up, assuming others find them valuable
• Solution: Smaller teams where people feel psychologically safe to speak up

Diffusion of Responsibility (social psychology concept):

Large teams → unclear ownership → everyone assumes someone else will handle it → work gets dropped

• Example: Bug report in shared channel with 20 people; nobody picks it up
• Solution: Clear roles, explicit ownership, right-sized teams

Providing Guidance

Design Principles

Use principles to form constraint boundaries.

Example: Third-Party Library Decision Framework

Special Purpose (Developer Decision):

• Specific functionality (PDFs, barcodes)
• Developer decides independently

General Purpose (Architect Approval):

• Wrappers on language APIs
• Developer analysis + architect approval

Framework (Architect Decision):

• Entire layers (persistence, IoC)
• Highly invasive
• Architect decides entirely

Business Justifications

Ask for business value to increase awareness and enable better decisions.

Leveraging Checklists

Inspired by Atul Gawande’s “The Checklist Manifesto” (2009)

Useful Checklists:

1. Developer code completion (“definition of done”)
2. Unit & functional testing (edge cases, unusual scenarios)
3. Software release (build/deployment steps)

Hawthorne Effect (observational psychology concept): Perception of monitoring encourages compliance - people perform better when they know they’re being observed or measured

Negotiation Skills

With Business Stakeholders

• Pay attention to buzzwords/jargon (contain clues)
• Gather information before negotiating
• State things in qualified cost and time
• Divide and conquer to qualify demands

With Other Architects

• Demonstration defeats discussion
• Avoid being overly argumentative or personal
• Calm leadership + clear reasoning wins

With Developers

• Provide justification (not dictates)
• Have them arrive at the solution themselves

Integrating with Development Teams

Control Your Calendar

Meetings Imposed on You:

• Ask why you’re needed
• Attend only for relevant topics
• Could meeting notes suffice?

Meetings You Impose:

• Keep to absolute minimum
• Set and stick to agenda
• Schedule at day edges (morning, after lunch, late)

Physical Presence

Respect Developer Flow State

Flow = 100% brain engagement where hours feel like minutes. Don’t disrupt flow. Pay attention to team productivity patterns.

Quick Reference

ADR Template

# [Number]. [Title]

**Status**: [Proposed/Accepted/Superseded]

**Context**: [Situation forcing this decision]

**Decision**: [We will...]

**Consequences**:
- Pros: [Benefits]
- Cons: [Trade-offs]

**Compliance**: [How measured]

Leadership Checklist

• Appropriate constraints (not too many/few)
• Regular collaboration with teams
• Clear business justifications for decisions
• ADRs for significant decisions
• Respect team flow and productivity
• Right-sized meetings (agenda, timing)
• Lead by example, not authority

Team Health Indicators

The 4 Cs of Architecture Leadership

1. Communication: Clear, effective information sharing
2. Collaboration: Working together toward goals
3. Clear: Unambiguous direction and decisions
4. Concise: Direct, to-the-point guidance