I’m currently working my way through Rohit Khare’s dissertation on using using REST methods in Decentralized Systems.  The main work of the paper is interesting, but I wanted to comment briefly on the methodology.  Khare takes the interesting approach of articulating several known problems with decentralized systems and then designing an architure which enforces graceful solutions to those problems.

“The basic organizational pattern of this dissertation is the pairing of a desired property and the architectural constraints that induce it. We design several new styles using this pattern of alternating subsections: specification of the required properties, a definition of the new style, validation that the new style correctly implements the abstract specification, and implementation issues encountered in practice.”

This architectural approach to solving difficult problems is an interesting one.  Architecture’s often given lip service, but it’s rarely treated well.  It’s often treated (by both suits and hackers) as the annoying middle step between defining what a system does and building that system.  It’s the irritating goody-two-shoes at the party that says “wait, before we pound this third round of tequila shooters, we should really figure out how we’re getting home.”

…Okay, so that analogy went kind of a weird place, but my point is that architecture is often seen as a necessary evil.  Business folks see it as yet another task in the Gantt chart that pushes back the delivery date.  Programmers see it as the busy work necessary to divy up the project amongst themselves.

(Interestingly, programmers tend to approach architecting personal projects with the same glee one might expect of a kid designing the treehouse of their dreams.  Put a bunch of coders together on a business project, however, and that joy for architecting disappears.  I imagine this indicates that how a coder feels about architecture may serve as a litmus for how they feel about the project as a whole.  I can’t decide whether this qualifies as an interesting insight or as crashingly obvious.)

I think that Khare’s approach is an elegant demonstration of the way software professionals should approach architecture.  What Khare is doing in his dissertation is articulating the desired behaviors of the system, and then designing it so that the system cannot behave in any other way. In this way, architecture becomes an integral part of specification enforcement.  (In more applied contexts, it also simplifies programming and testing the system as well.  After all, if every possible behavior that can be taken care of at the architecture level has been, then those are behaviors that you don’t have to worry about in implementation or testing.)

If you approach architecture as a way to satisfy some parts of a specification, then it becomes more obvious way software professionals should care about it.  Suits should care about architecture because, since it enforces some parts of the spec before any code is even written, it will make subsequent tasks (implementation and QA) faster.  It will also create a better and more reliable end product.

Coders should care about architecture because it makes their jobs easier and more enjoyable.  It helps them deliver a stronger product, with less risk and effort on their part.  It also helps them do all that more quickly and more consistently.

Personally, I think that both should care about architecture because it’s really damned interesting and can lead to some amazingly elegant solutions.  But I guess I can’t really demand that other people be as interested in good design as I am.  To paraphrase the amazing Randall Munroe: “Architecture: It Works, Bitches!”