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.