Archive for January, 2010

Architecting for Behavior

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!”

return Posts[0];

I suppose the first post should be all introspective and shit, but I’m honestly not feeling it.  All I have to say is that this blog will always strive to choose Win over Fail and to engage in random acts of Awesome.  As its proprietor I make no other promises.

Let’s get hacking.

Return top

Magic Blue Smoke

House Rules:

1.) Carry out your own dead.
2.) No opium smoking in the elevators.
3.) In Competitions, during gunfire or while bombs are falling, players may take cover without penalty for ceasing play.
4.) A player whose stroke is affected by the simultaneous explosion of a bomb may play another ball from the same place.
4a.) Penalty one stroke.
5.) Pilsner should be in Roman type, and begin with a capital.
6.) Keep Calm and Kill It with Fire.
7.) Spammers will be fed to the Crabipede.