When people in the software industry talk about “architecture”, they refer to a
hazily defined notion of the most important aspects of the internal design of a
software system. A good architecture is important, otherwise it becomes slower and
more expensive to add new capabilities in the future.
Like many in the software world, I’ve long been wary of the term “architecture” as
it often suggests a separation from programming and an unhealthy dose of pomposity.
But I resolve my concern by emphasizing that good architecture is something that
supports its own evolution, and is deeply intertwined with programming. Most of my
career has revolved about the questions of what good architecture looks like, how
teams can create it, and how best to cultivate architectural thinking in our
development organizations. This page outlines my view of software
architecture and points you to more material about architecture on this site.
A guide to material on martinfowler.com about
What is architecture?
People in the software world have long argued about a definition of
architecture. For some it’s something like the fundamental organization of
a system, or the way the highest level components are wired together. My
thinking on this was shaped by an email exchange
with Ralph Johnson, who questioned this phrasing, arguing that
there was no objective way to define what was fundamental, or high level
and that a better view of architecture was the shared understanding that
the expert developers have of the system design.
Ralph Johnson, speaking at QCon
A second common style of definition for architecture is that it it’s “the design
decisions that need to be made early in a project”, but Ralph complained about this
too, saying that it was more like the decisions you wish you could get right early
in a project.
His conclusion was that “Architecture is about the important stuff. Whatever that
is”. On first blush, that sounds trite, but I find it carries a lot of richness. It
means that the heart of thinking architecturally about software is to decide what is
important, (i.e. what is architectural), and then expend energy on keeping those
architectural elements in good condition. For a developer to become an architect,
they need to be able to recognize what elements are important, recognizing what
elements are likely to result in serious problems should they not be controlled.
Ralph’s email formed the core of my column for
IEEE software, which discussed the meaning of software
architecture and the role of an architect.
Why does architecture matter?
Architecture is a tricky subject for the customers and users of
software products – as it isn’t something they immediately perceive. But a
poor architecture is a major contributor to the growth of cruft – elements
of the software that impede the ability of developers to understand the
software. Software that contains a lot of cruft is much harder to modify, leading to features
that arrive more slowly and with more defects.
This situation is counter to our usual experience. We are used to
something that is “high quality” as something that costs more. For some
aspects of software, such as the user-experience, this can be true. But
when it comes to the architecture, and other aspects of internal quality,
this relationship is reversed. High internal quality leads to faster
delivery of new features, because there is less cruft to get in the
While it is true that we can sacrifice quality for faster delivery in
the short term, before the build up of cruft has an impact, people
underestimate how quickly the cruft leads to an overall slower delivery.
While this isn’t something that can be objectively measures, experienced
developers reckon that attention to internal quality pays off in weeks not
At OSCON in 2015 I gave a brief talk (14
min) on what architecture is and why it matters.
The important decisions in software development vary with the scale of
the context that we’re thinking about. A common scale is that of an
application, hence “application architecture”.
The first problem with defining application architecture is that
there’s no clear definition of what an application is. My view is that
applications are a social
- A body of code that’s seen by developers as a single unit
- A group of functionality that business customers see as a
- An initiative that those with the money see as a single
Such a loose definition leads to many potential sizes of an
application, varying from a few to a few hundred people on the development
team. (You’ll notice I look at size as the amount of people involved,
which I feel is the most useful way of measuring such things.) The key
difference between this and enterprise architecture is that there is a
significant degree of unified purpose around the social
One of the undecided problems of software development is deciding
what the boundaries of a piece of software is. (Is a browser part of
an operating system or not?) Many proponents of Service Oriented
Architecture believe that applications are going away – thus future
enterprise software development will be about assembling services
I don’t think applications are going away for the same reasons
why application boundaries are so hard to draw. Essentially
applications are social constructions:
The microservice architectural pattern is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP resource
API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery. There is a bare minimum of
centralized management of these services, which may be written in different
programming languages and use different data storage technologies. While their
advantages have made them very fashionable in the last few years, they come
with the costs of increasing distribution, weakened consistency and require
maturity in operational management.
Serverless architectures are application designs that incorporate third-party “Backend as a
Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers
on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like
single-page applications, such architectures remove much of the need for a traditional always-on
server component. Serverless architectures may benefit from significantly reduced operational
cost, complexity, and engineering lead time, at a cost of increased reliance on vendor
dependencies and comparatively immature supporting services.
Good frontend development is hard. Scaling frontend development so that many
teams can work simultaneously on a large and complex product is even harder.
In this article we’ll describe a recent trend of breaking up frontend
monoliths into many smaller, more manageable pieces, and how this
architecture can increase the effectiveness and efficiency of teams working
on frontend code. As well as talking about the various benefits and costs,
we’ll cover some of the implementation options that are available, and we’ll
dive deep into a full example application that demonstrates the technique.
In the mid 2000s I was pursuing a couple writing projects that
could have turned into books, but haven’t yet made it. One was on the
architecture of user interfaces. As part of this work, I drafted a
description of how GUI architectures evolved, comparing the
default approach of Forms and Controls with the the
Model-View-Controller (MVC) pattern. MVC is one of the most
ill-understood patterns in the software world, understandably so since it was
not well documented. So my writing here tries to give a better picture of
what MVC really means and how it evolved through Model-View-Presenter and
One of the most common ways to modularize an information-rich
program is to separate it into three broad layers: presentation (UI), domain logic
(aka business logic), and data access. So you often see web
applications divided into a web layer that knows about handling HTTP
requests and rendering HTML, a business logic layer that contains
validations and calculations, and a data access layer that
sorts out how to manage persistent data in a database or remote
While application architecture concentrates on the architecture within
some form of notional application boundary, enterprise architecture looks
architecture across a large enterprise. Such an organization is usually too
large to group all its software in any kind of cohesive grouping, thus
requiring coordination across teams with many codebases, that have developed
in isolation from each other, with funding and users that operate
independently of each other.
Much of enterprise architecture is about understanding what is worth the
costs of central coordination, and what form that coordination should take.
At one extreme is a central architecture group that must approve all
architectural decision for every software system in the enterprise. Such
groups slow down decision making and cannot truly understand the issues
across such a wide portfolio of systems, leading to poor decision-making. But
the other extreme is no coordination at all, leading to teams duplicating
effort, inability for different system to inter-operate, and a lack of
skills development and cross-learning between teams.
Like most people with an agile mindset, I prefer to err on the side of
decentralization, so will head closer to the rocks of chaos rather than
suffocating control. But being on that side of the channel still means we
have to avoid the rocks, and a way to maximize local decision making in a
way that minimizes the real costs involved.
Enterprise Architecture groups often get separated from day to day
development. This can lead to their knowledge of development work getting
out of date and development teams not taking a broad company-wide
perspective. Having seen this happen frequently my colleague (ThoughtWorks
CTO) Rebecca argues that enterprise architects can be much more effective by
joining development teams.
When an organization takes on an agile mindset, enterprise architecture
doesn’t go away, but the role of enterprise architects changes. Enterprise
Architects no longer make choices, but help others make the right choice and
then radiate that information. Enterprise Architects still need to form a
vision, but then need to build bridges between teams to build communities of
learning. These will allow teams to explore new approaches and learn from
each other, with Enterprise Architects as partners in that growth.
Software projects are a popular way of funding and organizing software
development. They organize work into temporary, build-only teams and are funded with specific
benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working
on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end
cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining
the architectural integrity of their software to preserve their long-term effectiveness.
Many large organizations see their IT engine separated by many floors from the
executive penthouse, which also separates business and digital strategy from the vital work
of carrying it out. The primary role of an architect is to ride the elevators between
the penthouse and engine room, stopping wherever is needed to support these digital
efforts: automating software manufacturing, minimizing up-front decision making, and
influencing the organization alongside technology evolution.
Most internal REST APIs are one-off APIs purpose built for a single integration point.
In this article, I’ll discuss the constraints and flexibility that you have with nonpublic APIs,
and lessons learned from doing large scale RESTful integration across multiple teams.