Skip to main content

Solution & System Architect

Design coherent systems within organizational constraints, balancing business goals with technical feasibility.

TL;DR​

The Solution (or System) Architect translates business requirements into technical designs, making critical decisions about system boundaries, quality attributes, and technology choices within enterprise guidelines. They own the coherence and long-term viability of their system, ensuring it serves business needs while remaining maintainable and operationally sound.

Learning Objectives​

  • Understand the scope and responsibilities of a Solution or System Architect
  • Learn how to balance business requirements with technical constraints
  • Master techniques for designing system boundaries and quality attributes
  • Develop skills in communicating architectural decisions to stakeholders
  • Apply escalation criteria to know when to involve Enterprise Architects

Motivating Scenario​

You're asked to design a new payment processing system that must handle peak loads of 100,000 transactions per second, integrate with legacy systems, comply with PCI-DSS regulations, and be deployed within six months. The business wants it built cheaply; operations wants it simple to run; security wants it impenetrable. You must balance these competing demands, respect organizational technology standards, and create a design that teams can actually implement and operate successfully.

Core Concepts​

System Boundaries and Ownership​

A system architect defines what belongs inside their system and what stays outside. Clear boundaries make responsibilities obvious, enable independent deployment, and constrain blast radius of failures.

Quality Attributes & Trade-offs​

Every design decision involves trade-offs. Fast systems are often complex. Secure systems require overhead. Scalable systems are expensive. A good system architect makes these trade-offs explicit, quantifies them, and ensures stakeholders understand the implications.

tip

Use quality attribute scenarios to make abstract requirements concrete: "The system must handle a 10x load spike in 5 minutes without service degradation." This is testable and measurable, unlike vague requirements like "it must scale."

Technology Selection Within Constraints​

Enterprise architects set technology standards; solution architects choose within those boundaries. Choices must align with organizational standards unless documented exceptions exist. Even within constraints, many decisions remain: which database, which framework, which deployment model.

Stakeholder Communication​

System architects bridge technical and business worlds. You must explain why a decision matters to both engineers (who care about implementation) and business leaders (who care about time and cost). Documentation like ADRs helps, but direct communication is essential.

Practical Example​

# Payment Processing System - Architecture Overview

System Purpose:
  Process customer payments safely and reliably, with fraud detection
  and compliance with PCI-DSS standards

System Boundaries:
  INSIDE:
    - Payment processing and routing
    - Fraud detection and risk scoring
    - Transaction logging and audit
    - Regulatory compliance (PCI-DSS)

  OUTSIDE (via integration):
    - Customer authentication (Auth system)
    - Card data storage (PCI-compliant vault)
    - Settlement (Bank integration)
    - Analytics (Data warehouse)

Key Quality Attributes:
  - Availability: 99.99% uptime (max 52 minutes per year downtime)
  - Latency: P99 < 200ms for transaction processing
  - Security: PCI-DSS compliant; no cardholder data in logs
  - Auditability: All transactions logged with audit trail
  - Scalability: Handle 100k transactions/second peak

Technology Choices (with rationale):
  - Language: Go (low-latency, built-in concurrency)
  - Database: PostgreSQL for transactions, Redis for caching
  - Message Queue: Kafka for audit logging and fraud analysis
  - Deployment: Kubernetes with auto-scaling
  - Monitoring: Prometheus + ELK for logs and metrics

Design Decisions:
  - Synchronous processing for initial validation (fast, consistent)
  - Asynchronous fraud analysis (can be delayed without user impact)
  - Multi-region deployment (high availability, regulatory spread)
  - Encrypted communication with all integrations
  - Circuit breakers for external dependencies

Core Responsibilities​

1. Translate Requirements to Design​

  • Gather and clarify business and stakeholder requirements
  • Define system boundaries and integration points
  • Document key design decisions through ADRs

2. Define Quality Attributes​

  • Identify and quantify quality requirements (performance, security, availability)
  • Make trade-offs explicit and communicate them
  • Create testable acceptance criteria

3. Technology & Framework Selection​

  • Choose technologies within organizational standards
  • Evaluate build vs. buy decisions
  • Document rationale for choices

4. Design for Operability​

  • Plan monitoring, alerting, and observability
  • Design for safe rollout and rollback
  • Prepare for failure scenarios

5. Stakeholder Communication​

  • Explain decisions to technical and non-technical audiences
  • Gather feedback and iterate
  • Manage expectations around trade-offs

Characteristics of Effective System Architects​

✓ Systems thinking: See connections between components and understand emergent behaviors ✓ Business acumen: Understand business drivers and translate them to technical requirements ✓ Technical depth: Hands-on experience with distributed systems, databases, and deployment ✓ Communication: Explain complex ideas simply to diverse audiences ✓ Pragmatism: Balance ideals with delivery constraints (time, budget, team capacity) ✓ Curiosity: Stay current with technologies and patterns ✓ Decisiveness: Make decisions with incomplete information and move forward

Pitfalls to Avoid​

❌ Premature optimization: Designing for scale problems you don't have yet ❌ Technology chasing: Adopting shiny new tools instead of proven solutions ❌ Over-engineering: Creating complexity that the team can't maintain ❌ Ignoring operations: Beautiful designs that are nightmare to run ❌ Siloed decisions: Designing without consulting stakeholders ❌ Analysis paralysis: Endless design documents without implementation ❌ Underestimating integration: Assuming external dependencies work as advertised

Versus Other Roles​

RoleFocusScopeAuthority
System ArchitectSystem design and boundariesSingle systemOwns design; E.A. can veto
Enterprise ArchitectOrg-wide coherenceAll systemsSets standards and policy
Tech LeadTeam execution and practicesSingle teamOwns daily decisions
DevOps/PlatformInfrastructure and deploymentShared platformProvides tools and support

Checklist: System Architect Readiness​

  • Requirements clearly documented in writing
  • System boundaries defined and agreed upon
  • Quality attribute scenarios created for each major requirement
  • Architecture Decision Record (ADR) for each major decision
  • Technology choices justified and within organizational standards
  • Operational strategy documented (monitoring, alerting, runbooks)
  • Stakeholder review conducted and feedback incorporated
  • Team understands the architecture and can implement it

Self-Check​

  1. Can you draw your system on a whiteboard and explain it to a new team member in 15 minutes? If not, your architecture is too complex or poorly understood.
  2. Does your design make trade-offs explicit? If you're claiming "we have everything," you're fooling yourself.
  3. Have you involved security, operations, and platform teams in design? If not, expect surprises later.
  4. Can you explain why each technology choice was made? If you chose it because "it's popular," reconsider.

Takeaway​

System architects succeed by staying grounded in both business reality and technical feasibility. The best designs balance multiple concerns—performance, security, cost, simplicity—without optimizing for just one. Your job is not to build the most impressive system but to build the right system within constraints, operate it reliably, and document it so your team can maintain and evolve it.

Next Steps​

  1. Gather requirements thoroughly: Interview stakeholders, document constraints
  2. Define system boundaries: What's in scope? What's external?
  3. Create quality attribute scenarios: Make requirements testable
  4. Document key decisions: ADR for each major choice
  5. Review with stakeholders: Get feedback before implementation

References​

  1. ISO/IEC/IEEE 42010: Systems and Software Engineering Architecture Description ↗️
  2. Martin Fowler: Architecture Decision Records ↗️
  3. Bass, Clements, Kazman: Software Architecture in Practice ↗️