The Role of an Architect and Architecture Types (Solution vs System)

Software architecture is the set of significant decisions about the organization of a software system — the selection of structural elements and their interfaces, their behavior as specified in collaborations among those elements, and the composition of these elements into progressively larger subsystems. But before diving into styles and patterns, we need to understand who makes these decisions and why different contexts call for different roles. This lesson covers the architect's job, the skills it demands, and the taxonomy of architecture types you will encounter in industry.

The popular image of an architect — someone who hands down diagrams from an ivory tower — is obsolete. Modern architects operate across four overlapping dimensions: technical leadership, system design, organizational communication, and continuous learning. They define quality attributes (performance, scalability, security, maintainability), translate business goals into structural constraints, mentor development teams, and own the decisions that would otherwise be made inconsistently across teams.

Architecture is one of the few roles that demands both extreme depth and extreme breadth. A senior engineer can be world-class in one area; an architect must be competent across many. The classic metaphor is the T-shaped skill set: deep in at least one technical domain, but broad enough to converse credibly across others. Mark Richards and Neal Ford add a second dimension — the 'frozen caveman' anti-pattern describes architects who stopped expanding their breadth and now apply decade-old solutions to modern problems.

Architecture is not one discipline — it is a family of overlapping concerns at different scales. The two most commonly confused types in industry are Solution Architecture and System Architecture (also called Software Architecture). Understanding the difference is critical because each operates at a different scope, answers different questions, and produces different artifacts.

These two are often conflated, yet they answer entirely different questions. Solution Architecture asks: 'Which systems, services, and vendors do we combine to solve this business problem, and how do they connect?' System Architecture asks: 'How do we structure the internals of this specific system to meet its functional and non-functional requirements?' A Solution Architect designs the map; a System Architect designs the city blocks.

Neal Ford, Rebecca Parsons, and Patrick Kua introduced the concept of 'evolutionary architecture' — architecture that guides change rather than resisting it. Central to this is the fitness function: an objective function that measures how well the current architecture meets a specific architectural characteristic. Fitness functions can be automated tests (checking for unwanted dependencies, verifying response time SLOs), manual processes (security audits), or metrics dashboards. The key insight is that architecture is not a one-time design — it is a continuous property of the system that must be actively maintained and measured.

// ── Dependency fitness function using ArchUnit ────────────────────

@ArchTest

static final ArchRule NO_DOMAIN_DEPENDS_ON_INFRA =

  noClasses().that().resideInAPackage("..domain..")

    .should().dependOnClassesThat()

    .resideInAPackage("..infrastructure..");

// ── Performance fitness function (JMeter / Gatling) ─────────────

// assert p99 latency < 200ms for /api/checkout

// assert error rate < 0.1% under 500 concurrent users

// ── Security fitness function ─────────────────────────────────────

// OWASP Dependency Check: no HIGH CVEs in production deps

Most architects come from a development background — and the transition is harder than it looks. The skills that made you an excellent developer (deep technical focus, solving concrete problems, delivering working code) are necessary but insufficient for architecture. The transition requires developing new muscles: systems thinking (how does this decision affect things ten steps away?), stakeholder management (how do I align people with competing interests?), and comfort with ambiguity (how do I make a good decision when I don't have all the information I want?).