Software Architecture Guide
Software Architecture Guide
When people in the software industry talk about “architecture”, they refer to a<br>hazily defined notion of the most important aspects of the internal design of a<br>software system. A good architecture is important, otherwise it becomes slower and<br>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<br>it often suggests a separation from programming and an unhealthy dose of pomposity.<br>But I resolve my concern by emphasizing that good architecture is something that<br>supports its own evolution, and is deeply intertwined with programming. Most of my<br>career has revolved about the questions of what good architecture looks like, how<br>teams can create it, and how best to cultivate architectural thinking in our<br>development organizations. This page outlines my view of software<br>architecture and points you to more material about architecture on this site.
A guide to material on martinfowler.com about<br>software architecture.
Martin Fowler
1 Aug 2019
What is architecture?
People in the software world have long argued about a definition of<br>architecture. For some it's something like the fundamental organization of<br>a system, or the way the highest level components are wired together. My<br>thinking on this was shaped by an email exchange<br>with Ralph Johnson, who questioned this phrasing, arguing that<br>there was no objective way to define what was fundamental, or high level<br>and that a better view of architecture was the shared understanding that<br>the expert developers have of the system design.
Ralph Johnson, speaking at QCon
A second common style of definition for architecture is that it's “the design<br>decisions that need to be made early in a project”, but Ralph complained about this<br>too, saying that it was more like the decisions you wish you could get right early<br>in a project .
His conclusion was that “Architecture is about the important stuff. Whatever that<br>is” . On first blush, that sounds trite, but I find it carries a lot of richness. It<br>means that the heart of thinking architecturally about software is to decide what is<br>important, (i.e. what is architectural), and then expend energy on keeping those<br>architectural elements in good condition. For a developer to become an architect,<br>they need to be able to recognize what elements are important, recognizing what<br>elements are likely to result in serious problems should they not be controlled.
Ralph's email formed the core of my column for<br>IEEE software, which discussed the meaning of software<br>architecture and the role of an architect.
Why does architecture matter?
Architecture is a tricky subject for the customers and users of<br>software products - as it isn't something they immediately perceive. But a<br>poor architecture is a major contributor to the growth of cruft - elements<br>of the software that impede the ability of developers to understand the<br>software. Software that contains a lot of cruft is much harder to modify, leading to features<br>that arrive more slowly and with more defects.
This situation is counter to our usual experience. We are used to<br>something that is “high quality” as something that costs more. For some<br>aspects of software, such as the user-experience, this can be true. But<br>when it comes to the architecture, and other aspects of internal quality,<br>this relationship is reversed. High internal quality leads to faster<br>delivery of new features , because there is less cruft to get in the<br>way.
While it is true that we can sacrifice quality for faster delivery in<br>the short term, before the build up of cruft has an impact, people<br>underestimate how quickly the cruft leads to an overall slower delivery.<br>While this isn't something that can be objectively measured, experienced<br>developers reckon that attention to internal quality pays off in weeks not<br>months.
Read more…
At OSCON in 2015 I gave a brief talk (14<br>min) on what architecture is and why it matters.
Application Architecture
The important decisions in software development vary with the scale of<br>the context that we're thinking about. A common scale is that of an<br>application, hence “application architecture”.
The first problem with defining application architecture is that<br>there's no clear definition of what an application is. My view is that<br>applications are a social<br>construction:
A body of code that's seen by developers as a single unit
A group of functionality that business customers see as a<br>single unit
An initiative that those with the money see as a single<br>budget
Such a loose definition leads to many potential sizes of an<br>application, varying from a few to a few hundred people on the development<br>team. (You'll notice I look at size as the amount of people involved,<br>which I feel is the most useful way of measuring such things.) The key<br>difference between this and enterprise architecture is that there is a<br>significant degree of unified purpose around the...