Ben Northrop


Decisions and software development


What is 'Good' Software Architecture?


(7 comments)
April 30th 2009


I often hear this kind of thing in design sessions...

"Sure, the architecture would be better if we made it more extensible (or reliable, maintainable, etc.), but we just don't have the time."

Beyond the standard BDUF vs. YAGNI debate, the tacit assumption here is that architectures that contribute to better extensibility, scalability, reliability, etc. are inherently "good", and those that don't, aren't. Sometimes, extensibility, for example, may need to be sacrificed to meet business goals, but in these cases the business consciously chooses the inferior architecture to survive.

I disagree.

In my opinion, the "goodness" of an architecture is only discernable within the context of the entity it's serving (e.g. business, organization, author, etc.). I submit (humbly!) this simple definition:

A good architecture is one which meets the needs of the entity that funds its existence.

In the example I first gave, the "good" architectural choice would actually be to not make the system extensible, since to make it extensible would be to exceed the schedule and budget. Sure, a more rigid system might incur more cost later in terms of refactoring, etc., but if the business isn't around later because of budget over-runs, how "good" is the architecture really?

The implications of this definition, I admit, feel kind of dirty at first. For example, it'd have to be claimed that a JSP page with the kitchen sink embedded in it (HTML, JDBC, business logic, the works) could actually be "good" architecture under certain business conditions - for instance if it's a non-business-critical stand-alone app, never to be touched again, and needed to be written by a coding newbie, etc.. In most cases, however, this single-layered JSP page would be what we expect - bad - since typically systems will need to be maintained, deadlines aren't COB tomorrow, etc., and so this architecture would cost the business more than it earns.

I guess my point is that the "goodness" of an architecture isn't some intrinsic property of the system, irrespective of the purpose it serves. I often see technologists join a new project, look at the source code, UML diagrams, etc. and immediately deride the architecture as a the worst slop they've ever seen. It's as though "good" architecture was some Platonic ideal, and whether the system helped the company make oogles of money (and give them a job to boot!) was just some periphery side-effect.

Instead, as technologists, I think we need to better appreciate how business conditions drive architectural decisions, taking into consideration not only functional and non-functional requirements, but business conditions like operating costs, cash-flow, time-to-market goals, and others. It is these things that "good" architecture is a function of, not just the architectural concepts (e.g. coupling, cohesion, separation of concerns, etc.) we usually think in terms of.

For example, if I'm working for a start-up that has only 2 months of funding left, then the architecture that facilitates the quickest release is in fact the best one, regardless of whether it just consists of PHP pages and a MySQL database, and not some elegant ORM persistence layer or flexible rules engine. If the architecture allows the company to land that first client or next round of funding, then by the very virtue of it supporting their success, it is "good".

I need to make clear that I'm not advocating cutting the corners of maintainability, extensibility, performance, etc. for the sake of laziness itself. These things typically do help businesses and should be designed for. However, when they actually hinder the business's end goals, they should just as readily be jettisoned, and without an ounce of guilt. Letting go of extensibility so that your business can survive is not promoting bad architecture. In fact, just the opposite!

I'd love to hear what you think. Do you buy this? Does "good" architecture depend on the business context, or could you look at the system artifacts alone and tell whether the architecture is "good"?

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?


Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (7)

JL
May 01, 2009
Good architecture is not related to extensibility.
But reliability is a condition sine qua non for good architecture.

The mark of a good architecture is revealed when the system (software, web site, ...) resists well to stress or unexpected conditions.
To achieve this you need to apply
-- the Occam's razor: the system performs what it has to do, no more and no less;
-- efficiency and speed (don't believe people saying optimization is a waste of time)
-- planning the consumable resources (like disk space)
-- test like crazy
-- submit the system to all the possible conditions: crash, backups, power failure, hacker attacks. There is no such thing as overdesigned system.

An other path to good architecture is to analyse well designed objects and draw conclusions:
Firefox the browser
Prius, the car
an eagle in flight
a dish washer
May 05, 2009
Thanks for the comment JL. I guess I'd ask if a system that didn't have 99.9% reliability could still be considered to be good architecture, if it fulfilled the end goals of its creators?

I was hoping to ask whether architecture could be judged only from the perspective of the person/company/organization who is responsible for its creation - not necessarily from the perspective of the person using it...or even building it. If a company builds some unmaintainable, unreliable, unextensible, etc. system that solves a great problem and makes tons of money, it might be the right architecture given the context.

Just a thought! Thanks again.
JS
May 20, 2009
-- "A good architecture is one which meets the needs of the entity that funds its existence."

This seems to take us down a dangerous path, as you illuminated with your model 1 example. I would rather substitute "system" or "application" for the word "architecture" in your definition.

A system's goodness should be judged by how well it serves its stakeholders. However, an architecture should be judged by the quality and elegance of the design. The desirable qualities of all systems are fairly standard; performance, extensible, configurable, simple, secure etc...

Where discussion concerning software architecture become complex is deciding which qualities are the most important and the best ways to achieve those qualities through design and process.

However, your model 1 jsp application, although a good system, is certainly not a good architecture. It possesses almost none of the agreed upon qualities. In contrast, your startup company may have a poor system (functional holes, unusable UI, ...) but have a great architecture.

A good architect or development team will recognize the necessary tradeoffs demanded by the "iron triangle", but include "outs" for future development. There is no way to architect software without a thorough understanding of the drivers and constraints.

Thanks for making me think.
July 21, 2009
I think that an architecture would be consider a good architecture if if supported current needs of an organization and can be modified for future use without undue pain or large investment of money.

In the end, if the use of a system pays the bills, then you can consider that grade a very important report card. However, if you need to introduce changes to that system, still send invoices and find you can modify that system, then the architecture of that system has failed the organization.

The effort expended in analysis so important to determine what type of architecture that is best for long term goals. You're right - the technologists don't figure on having to pay the bills, they are more comfortable squabbling about minutia. I have a post that discusses some of those pitfalls if you are interested: http://activeengine.wordpress.com/2009/07/21/revenge-of-the-fallen/
Mike Carpenter
July 26, 2009
Great post.

I like JS's idea of separating architecture from application. However, I think defining this line is difficult in practice - e.g. is that strategy pattern you are using part of the architecuture (extensibility) or part of the application design?

Generally, I agree with most of what you are saying. I think one important thing that must be kept in mind is as the company/system grows the architecture must evolve. Both the techies and the biz folks must accept and embrace this or the system is doomed to fail. This reminds me of the "design debt" metaphor - the team must keep track of this debt and fix it, and the business has to accept that this is as necessary as adding new functionality. Easier said than done, I know, but that is the price of good software.
August 12, 2011
Although I am not an architect (just a common Brazilian and a client of architects). Browsing the Internet I came upon your explanation which to me seems absolutely excellent. I plan to to use it as an motivational example for some of my presentations in developing countries on the need to be pragmatic and invest mainly in drug prevention in order to try to solve (even partially) the problems of drug use You are certainly a very bright professional! I wish you a career of much success and achievements.
Ben
August 26, 2011
Thanks Mina! I'm flattered that you would consider using my definition.