What is Software Architecture?

My job title has "software architect" in it, so I do think I'm entitled to an opinion on what such terms mean. In an enterprise, an architect spends his time deciding what aspects of software and system design should be standardized across the organization and what things should be left to the judgment of individual implementations. Our goal, like that of anyone else in the business, is to deliver value to the company as efficiently as possible. When we decide to standardize, we have to spell out what is and isn't allowed, and we need to defend the value proposition associated with making rules over tolerating divergent solutions. I view an architecture as a set of principles, where a principle is a function that maps the space of designs into a binary space of "yes/encouraged/allowed/true/conformant/good" vs "no/discouraged/rejected/false/nonconformant/bad". When I use or hear discussion of architectural "constraints", I think in terms of such functions.

A business considers an architecture to be "good" if it leads to lower IT costs over time, balancing well between actually shipping working solution with a shorter-is-better look at development time. Since this is evaluated "over time" you have to include maintainability, adaptability, and so on. What makes an architecture "good" is dynamically changing: it depends on the habits and knowledge of the individuals in the organization, and it depends on the extent to which consensus has emerged. These things aren't perfectly knowable, and architectural leadership is as much about communicating and guiding as it is about deciding. I think my concepts here of software architecture align a lot with those of Martin Fowler, as described in his essay Who Needs an Architect?.

There is a classic debate between academics and applied practitioners as to the value of standalone theory. I'm an unapologetic applied practitioner. When we introduce nuances like the difference bewteen "architectural style" and "software architecture", I ask "who are you trying to communicate to?" When most people don't understand the distinction I wonder whose fault Dr. Fielding thinks that is and what we should do about it. At a minimum, I think it's fair to ask "why introduce a second level of abstraction?" Can't I reformulate a REST equivalent as a set of architectural principles in the sense I give above and take any proposed concrete design and say which, if any, of those principles it violates? Isn't the real problem here that we named the abstraction without having a few concrete architectures to justify it?

The use of language as a means to develop common understanding is an important step in the evolution of software architecture. Common understanding hopefully leads to communication about common experiences, and this in turn leads to consensus on what is or isn't a best practice worth standardizing upon. When I adopt language, I do so with this end in mind. I tried to sidestep the double abstraction by writing about ROA and not really about REST other than how it's used within ROA. I did this because over the past year or so, there has been an ongoing discussion influenced by Sam Ruby's book RESTful Web Services. Part of my job is to critically examine all sides of archictural trends. I, along with my fellow architects, need to guide my company on how and when to adopt architectural principles. In order to do that, I need a name for the set of practices we should consider adopting. All I can say is that continued confusion over terminology and concepts is not a good selling point for REST or ROA or whatever I should call the thing we could adopt is.

I note the Roy appears to lump me in as an "SOA advocate". I suppose it looks that way, but I'd like to make it clear that this is "for now" only. Again, what's "best" is a influenced heavily by human factors such as understanding, consensus, industry support, and so on. I'm no SOAP fanboy: there's a whole lot to dislike about SOAP and the lack of simpler solutions for SOA wastes endless sums of money across the IT industry. In my view the race is on to see if SOAP can simplify before some particular REST approach matures enough to displace it. I would not be surprised at all if specs like WADL or WSDL 2.0 help move a RESTful web services approach forward. But lots of REST advocates seem to have a philosophical opposition to these and my message to them is unambiguous: within the enterprise, REST won't matter without these. If nothing changes REST will continue be used to solve the problems of web communities. Solutions like Atom where a critical mass of people with a common problem collaborate on standards and tools will be the only arena where REST impacts. Inside the enterprise where programmers toil one or two at a time under deadlines to integrate the backends of systems in environments where politics exist, SOAP will be what people like me conclude we need to use. Again, I said "if nothing changes". I hope it will, and when it does you'll read about it here. Dr. Fielding reads this as "criticisms of [his] work". That's a glass half-empty view. A gap is an opportunity to improve, and closing this one would make it more useful in the space I happen to work in. That space is a big one, but it's not the only one. I wouldn't be discussing REST at all if it didn't solve some problem well. Please note that my Atom feed for this blog works great and is joyously RESTful.

Finally, I'd like to point out that Dr. Fielding essentially restated my main point when he says "REST constraints do not constrain Web architecture — they constrain RESTful architectures (including those found within the Web architecture) that voluntarily wish to be so constrained." It seems really odd to recognize the value of a set of voluntary constraints without immediately asking how to declare that you have volunteered, so that interacting parties can rely upon it. This of course, is exactly what a contract is. It would be nicer still, and downright useful, if there was an objective way to test that a site that declared itself to have some particular RESTful architecture actually did. In other words, its also useful to audit compliance to the contract.

Technorati Tags: architecture rest roa soa