What makes architecture “better”?

I’ve got some news! Jenny and I are going to be doing our Beautiful Teams talk at the upcoming IT Architect Regional Conference. We spoke at last year’s ITARC, and I was really impressed with the quality of their speakers. There were some really good insights into software architecture. It’s a great group, and I definitely recommend it to anyone looking to do a serious deep dive into software architecture.


And that got me thinking about one of the important areas of architecture, one that I think a lot of people tend to overlook. Actually, what really got me started thinking about it was a Slashdot post, “News Content As a Resource, Not a Final Product,” which refers to this essay on publishing by Paul Graham. At the very top of the article, Graham (unintentionally) brings up a point that I think is interesting:

Publishers of all types, from news to music, are unhappy that consumers won’t pay for content anymore. At least, that’s how they see it.

In fact consumers never really were paying for content, and publishers weren’t really selling it either. If the content was what they were selling, why has the price of books or music or movies always depended mostly on the format? Why didn’t better content cost more?

A copy of Time costs $5 for 58 pages, or 8.6 cents a page. The Economist costs $7 for 86 pages, or 8.1 cents a page. Better journalism is actually slightly cheaper.

— Paul Graham, “Post-Medium Publishing”

I think that begs a basic question: what does “better” really mean when it comes to content? Is the Economist really better than Time? Our second book, Head First PMP, outsells our first book, Applied Software Project Management. Is one better than the other?

Like most questions of “better,” you have to understand how something’s going to be used before you can judge how good it is at its job. If you’re preparing for the PMP certification exam, Head First PMP is better for that job. If you’re trying to improve the way your team runs software projects, you’ll get a lot more mileage out of Applied Software Project Management. That’s a basic idea behind quality. You can’t judge the quality of a product without understanding the requirements, and how it’s going to be used to do a job. (I’ve been making that point on this blog for quite a while now!) And when it comes to testing software, that has real-life, practical implications. For example, it means that you can make sure your testing is effective by concentrating your tests on how the software is going to be used.

But it also has an important impact on architecture. A lot of us run into a serious problem when we’re designing a complex system: how do you actually “test” your architecture? It’s not like you can write, say, JUnit or NUnit tests for it. And architecture poses some pretty daunting review challenges. While it’s certainly a good idea to do architecture reviews, a lot of the time yo’re more likely to end up doing UI design reviews, prototype walkthroughs, and deployment reviews. Or you’ll end up starting out trying to review your object model, but you’ll end up buried in implementation detail.

My goal, when I’m designing a new system, is to come up with the best architecture I can. What makes one object model or database design “better” than another? The best design is the design that does the job best. That’s why user stories are so useful, and why I try to have them done before I start in on the architecture: because they help make sure my design is grounded in the way the system’s actually going to be used.

Try this the next time you’re at that point where you’ve got an initial software architecture laid out, but you haven’t started in on the coding and you’re looking for feedback. Instead of diving straight into the review, try starting out by giving an overview of the people who are going to use the system and the job they’ll be doing. I’ve found that simply grounding people in the actual goals and purpose of the system really focuses the feedback I get.

IASA Speaker 2009

Andrew and Jennifer will be giving their Beautiful Teams talk at the IT Architect Regional Conference on October 12.

2 thoughts on “What makes architecture “better”?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.