Software architecture is the set of high-level choices about how a system is structured: where the code runs, how the parts talk, and where the data lives. Those choices have changed dramatically since the 1960s. This guide is a sourced timeline of that change, and, more usefully, an explanation of the forces that drove each shift. Architecture rarely changes for fashion. It changes when the cost of hardware, the reach of the network, the scale of demand, or the structure of teams makes the old shape too expensive.

Three stages on dark slate: a solid cube, a wireframe lattice cube, and the same cube broken into scattered smaller cubes. No em-dashes.
One idea, three shapes. A solid block becomes a structured lattice and then a set of independent pieces, the same path software architecture has walked from the monolith to microservices.

Why architecture keeps changing

Read the timeline below and the same pattern repeats. A new constraint appears or an old one lifts, and the dominant shape of systems moves to match it. Cheap networked PCs pulled work off the mainframe. The web connected those machines to the world. Web-scale traffic and large teams broke the monolith into services. Rentable cloud infrastructure made elastic, pay-per-use design the default. Each era solved the previous era’s pain and created the next one.

The timeline

The mainframe era 1960s to 1980s

The driver: computers were rare, huge, and expensive. The sensible design put one powerful machine at the centre and many simple terminals around it.

  1. 1964
    IBM System/360

    A family of compatible mainframes that served many users from one central machine, announced in April 1964.

    Why One architecture spanning small and large models meant software and peripherals finally worked across a whole product line instead of being rebuilt per machine.

The client-server and web era 1980s to 1990s

The driver: cheap networked PCs let work move off the central mainframe onto the desktop. The web then connected those machines to the entire world.

  1. 1980s 90s
    Client-server and three-tier

    Work split between client machines and servers. Three-tier architecture separated presentation, business logic, and data into distinct layers.

    Why Cheap PCs and local networks made it practical to distribute work and to isolate business logic in a middle tier that was easier to change and scale.

  2. 1989 91
    The World Wide Web

    Tim Berners-Lee proposed it at CERN in March 1989. The first server and browser ran by the end of 1990, and the web went public in 1991.

    Why CERN's distributed researchers needed to share and link complex information across incompatible machines, using hypertext over the network.

  3. 1991
    CORBA 1.0

    A standard from the Object Management Group that let objects written by different vendors and languages call each other across a network.

    Why A world of incompatible systems needed a common way for components to interoperate across machines and operating systems.

  4. 1994
    Design Patterns (Gang of Four)

    Gamma, Helm, Johnson, and Vlissides published a catalogue of 23 reusable object-oriented design patterns and a shared vocabulary.

    Why Teams kept re-solving the same object-oriented design problems and needed proven, named solutions they could talk about.

The services and enterprise era mid-1990s to 2000s

The driver: large organisations ran many systems that had to talk to each other and be reused. That pushed architecture toward services, standards, and clean internal boundaries.

  1. ~1996
    Service-Oriented Architecture (SOA)

    Building systems from loosely coupled, reusable, network-accessible services. The term is commonly attributed to Gartner analysts Roy Schulte and Yefim Natis around 1996.

    Why Enterprises wanted reuse and integration across many systems instead of rebuilding the same logic in each application.

  2. 2000
    SOAP and web services

    A standard for programs to call each other over HTTP using XML. SOAP 1.1 was published as a W3C Note in May 2000.

    Why Cross-vendor, cross-platform systems needed a portable, agreed format for remote calls.

  3. 2000
    REST

    Roy Fielding's PhD dissertation at UC Irvine named and defined the architectural style behind the web.

    Why The principles that made the web scale needed to be written down so they could guide the design of future network-based systems.

  4. 2000
    Continuous Integration

    Martin Fowler codified the practice of merging and automatically testing code frequently, drawn from Kent Beck's Extreme Programming.

    Why Big-bang merges caused painful, days-long "integration hell". Integrating continuously removed it, a habit later eras depended on.

  5. 2003
    Domain-Driven Design

    Eric Evans's book aligned the code model tightly with the business domain and a shared, "ubiquitous" language.

    Why Large systems collapsed under complexity when the code and the business understanding drifted apart.

  6. 2005
    Hexagonal Architecture

    Alistair Cockburn's Ports and Adapters pattern isolated core business logic from UIs, databases, and external systems. (commonly dated around 2005)

    Why Business logic needed to be testable and runnable in isolation, free of any specific UI or piece of infrastructure.

The cloud era 2006 to 2012

The driver: renting elastic, pay-as-you-go infrastructure removed the need to buy and run servers. That economic shift changed how systems were designed, deployed, and scaled.

  1. 2006
    Amazon S3 and EC2

    AWS launched internet-scale object storage (S3, March 2006) and resizable compute rented by the hour (EC2 beta, August 2006).

    Why Developers could rent web-scale storage and compute on demand instead of buying hardware up front, turning a capital cost into a usage cost.

  2. 2011
    The Twelve-Factor App

    A methodology from Heroku's developers for building portable, scalable cloud applications. (widely dated to 2011)

    Why Thousands of cloud apps showed the same config, dependency, and scaling mistakes, which the method set out to prevent.

  3. 2012
    Clean Architecture

    Robert C. Martin unified Hexagonal and similar patterns under the Dependency Rule: source dependencies point only inward, toward the business rules.

    Why Business rules needed to outlive the frameworks, UIs, and databases around them, which change far more often.

The cloud-native and microservices era 2011 to 2017

The driver: web-scale traffic and large teams needed services that could be built, deployed, and scaled independently. Containers made that practical, and cloud economics made it affordable.

  1. 2011
    Microservices (the term)

    A workshop of software architects near Venice in May 2011 named the style of small, independently deployable services.

    Why A large monolith slowed big teams, because every change waited on one shared release. Small services let teams deploy on their own schedule.

  2. 2013
    Docker

    Solomon Hykes demoed Docker at PyCon in March 2013, packaging an app with its dependencies in a lightweight container.

    Why "It works on my machine" failures needed consistent, portable packaging that ran the same in development and production.

  3. 2014
    The Microservices article

    James Lewis and Martin Fowler published a definition of the style and its tradeoffs in March 2014.

    Why A fast-spreading practice needed a clear, shared description so teams meant the same thing by "microservices".

  4. 2014
    Kubernetes

    Google open-sourced its container orchestrator in 2014. Version 1.0 followed in 2015 and seeded the new Cloud Native Computing Foundation.

    Why Running many containers across many machines needed automated scheduling, scaling, and self-healing that humans could not do by hand.

  5. 2014
    AWS Lambda (serverless)

    Announced in November 2014, Lambda ran event-driven functions with no server to manage, billed per execution.

    Why Teams wanted to run code in response to events without provisioning, patching, or operating any servers at all.

  6. 2017
    Service mesh (Istio)

    Google, IBM, and Lyft launched Istio in May 2017 to connect, secure, and observe traffic between microservices.

    Why Microservices created cross-cutting traffic, security, and telemetry concerns best handled outside the application code.

The AI-native era 2022 to now

The driver: AI that can generate code and act as a software component is changing both how systems are built and what counts as a "component".

  1. 2022
    ChatGPT and the LLM wave

    A conversational AI product put large language models in front of a mass audience in late 2022.

    Why Language models became good enough to generate working code and to power product features directly, not only to assist.

  2. 2023+
    AI agents and RAG as components

    Retrieval-augmented generation and tool-using agents became architectural building blocks inside ordinary applications.

    Why Teams now design systems where an AI model is a first-class component that retrieves data, makes decisions, and takes actions.

The forces behind every shift

Strip away the product names and a small set of forces explains the whole timeline. When you understand the forces, you can predict the next move instead of memorising the last one.

  • The cost and shape of hardware. Expensive central machines gave us mainframes. Cheap PCs gave us client-server. Rentable cloud gave us elastic, on-demand design.
  • The network. The local network distributed work. The web connected everyone. Standards like CORBA, SOAP, and REST then let systems call each other across it.
  • Scale. More users and more data broke designs that assumed one machine and one team, pushing systems toward services that scale independently.
  • Deployment friction. Slow, risky releases drove Continuous Integration, containers, and microservices, each one shrinking the unit you can ship safely.
  • Team structure. Conway’s Law, named after Melvin Conway’s 1968 observation, holds that systems tend to mirror the communication structure of the teams that build them. Many small autonomous teams tend to produce many small autonomous services.
  • The cost model. Buying servers (a capital cost) became renting cloud (an operating cost) and then paying per function call (serverless). Each step let architecture follow the money more closely.
  • And now AI. A model that can generate code and act on its own shifts effort from writing every line to describing intent and verifying the result.

The eras at a glance

YearsDominant shapeThe force that drove it
Mainframe1960s to 1980sOne central machine, many terminalsComputers were rare and expensive
Client-server and web1980s to 1990sDistributed PCs, the webCheap networked machines
Services and enterprisemid-1990s to 2000sSOA, REST, clean boundariesReuse and integration at scale
Cloud2006 to 2012Rented, elastic infrastructurePay-as-you-go economics
Cloud-native and microservices2011 to 2017Small services, containers, serverlessTeam autonomy and web-scale traffic
AI-native2022 to nowAI as a component, AI-written codeCapable, general-purpose models

Further reading