I tend to look at “architecture” as one of those impressive-sounding words, used primarily to indicate that we’re talking something that’s important.
And (emphasis added):
There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change. … In the end architecture boils down to the important stuff—whatever that is.
“Whatever that is.”
Let’s break down what Fowler actually says there, because it’s probably the best definition we’re going to get.
- The highest level breakdown of a system into it’s parts. This seems obvious. From the very beginning of, say, going through a RoR tutorial or some other framework setup, you are assembling these parts together: in a web application for example, you’ll probably need a database. You definitely need a web server. If you’ve chosen RoR or a similar framework, it is assumed that you are going to have models, controllers, and views, and you are encouraged to organize things in a certain way. But there are other choices and components as well. Will there be background jobs? Are there external components, services, or APIs which you must query or update periodically? Is user authentication part of your system, or is it dependent on some external service, like Twitter or Facebook Oauth, an LDAP server, or something else entirely? Will this change later? I think if we’re just plowing ahead without asking these question, we aren’t thinking about software architecture. If you are stopping to ask the questions, you are thinking about architecture.
Decisions that are hard to change. Some decisions are (hopefully), easy to change. Ideally, in an MVC framework, it is very easy to change your views without changing any other part of your application (if you don’t think this is true, you might not be doing MVC as intended, as this is one of the explicit goals of an MVC architecture). Again, if you need to change your datasource, hopefully this is an easy thing to change. This is dependent on a few things, but let’s at least say that theoretically, if you’re changing from one relational database to another, that shouldn’t be a crazy impossible task: it should be moderately simple to switch from, say, MySQL to Postgresql.
Other decisions are not so easy. If you commit to a framework or language, making a change probably means a complete rewrite. If you choose Rails, or whatever, and then later on, when your app is more or less complete and functional, you think that maybe you’d like to use Ember or Meteor or a Clojure framework: congratulations. You’re likely going to be rewriting the whole application.
Knowing which decisions will be hard to change is a mixture of common sense and experience. Some things might be immediately obvious even to a new programmer, while other times it maybe be obvious only to a senior developer that there are dragons in those waters.
So that’s sort of it. Architecture, in and of itself, is not really arcane or esoteric.
Highest level breakdown.
Things that are hard to change.
There’s a certain amount of experience needed in order to identify these things, of course, but I honestly feel like that experience can be accelerated by exploring these ideas earlier in your software career. If you do that, you can hopefully see these things in your own code and in the applications you’re working on and contributing to sooner than you might otherwise see them.