Summary of "How to Become a Great Software Architect • Eberhard Wolff • GOTO 2019"

High-level theme

The talk (GOTO 2019) by Eberhard Wolff describes what makes a great software architect. Key points:

Architecture is about technical decisions, quality attributes, team interaction and communication.
The architect’s role is to facilitate decisions and enable teams, not to be a lone coder or a single source of truth.
Success comes from shared ownership and practical trade-offs, not idealized solo designs.

Architecture and system-quality concerns

Focus on measurable quality attributes and operational realities:

Primary quality attributes to consider:
- Availability
- Reliability / fault tolerance
- Performance
- Security
- Maintainability
- Scalability
- Operability
Use concrete scenarios (failure cases, crashes, load spikes) to validate requirements and make them testable.
Quantify availability goals (e.g., uptime percentage) and define recovery time and graceful degradation behavior.
Include operational concerns early:
- Backups and disaster recovery
- Encryption and secure connections
- Monitoring and observability
- Ongoing cost and maintenance of infrastructure and vendor solutions
- Compliance with standards (ISO, etc.)
Treat security as cross-cutting: design end-to-end protection and integrate secure operations from the start rather than as an afterthought.

Documentation, verification and quality management

Architecture must be usable and verifiable, not just theoretical:

Document the architecture in a way that enables verification and testing.
Produce “quality scenarios” with concrete steps and expected behavior so teams can validate the system (examples: user flows, incident/hotline scenarios).
Adopt a holistic view of quality — usability, operability and reliability are as important as functional correctness.
Record rationale and scenarios alongside diagrams so future teams can understand trade-offs and re-verify decisions.

Design principles and practices

Practical design guidance to support change and real-world constraints:

Favor clean, modular architecture that supports change and scalability.
Design for change: identify parts most likely to change and make trade-offs explicit.
Keep solutions pragmatic: balance ideal architectures with operational cost, team capability and delivery constraints.

Team, process and the architect’s role

How architects should work with teams and processes:

Act as facilitators and communicators:
- Synthesize expert input
- Set visions and boundaries
- Enable self-organizing teams rather than centralizing decisions
Build cross-functional teams with domain experts (operations, security, performance, domain specialists) to inform architectural choices.
Make decisions in a timely manner:
- Take interim decisions when necessary
- Implement feedback loops
- Adapt when new information emerges
Avoid the myth of a single architect doing everything — architecture succeeds when the team owns and implements it.

Practical takeaways

Actionable guide-style steps to apply immediately:

Start by identifying the most important quality attributes for your system and writing scenarios for them.
Test architectural assumptions with concrete failure and recovery tests.
Consider operational costs, vendor lock-in and standards when selecting components.
Document the architecture plus rationale and scenarios so successors can verify and evolve the system.
Empower teams and establish feedback cycles for architectural decisions.

Referenced examples and context

The talk references modern architectural patterns and real-world enterprise examples to illustrate challenges in large systems:

Topics: microservices, continuous delivery, enterprise-scale systems
Example companies cited: BMW Group, Apple, Facebook, Software AG (used as illustrative cases)

Main speaker / sources

Eberhard Wolff — presentation at GOTO 2019
Companies and examples mentioned in the talk: BMW Group, Apple, Facebook, Software AG

Architects should be facilitators and communicators: enable teams, make trade-offs explicit, and ensure architecture is testable and operable — not a set of unreachable ideals.