Architectural Styles, Constraints, Desired Properties, etc.

REST gets all the attention, but I think the framework presented in the first half of the dissertation is equally, if not more, important.  There are many frameworks that attempt to understand software architecture but none that I've found that are reasonable.  REST itself is a derived by way of a worked example through that reasoning framework.  I'd like to start using that approach myself but doing so demands a common understanding which, as with REST itself, is rather elusive.  Trying to explain it, as Roy did, in technical terms is further burdened by preconceived notions of overloaded terminology.  So, I crafted a story that attempts to communicate the essence (constraints, desired properties, architectural styles, etc.) without being burdened by the baggage of assumptions.

The story goes like this...

Suppose a customer comes to your "information business" and says, "I have a need for all the information on organic gardening."  The customer travels a lot and needs the information available to him for reference when his customers ask gardening questions, but he's frequently in the fields and, so, isn't always technology enabled.

Your organization is quite large and information comes from a variety of departments.  To make matters worse, you're in the Solutions Architecture side of the business and so you have no real authority to dictate a precise solution - these are 'information engineers' after all, who need room to flex their creativity.  You are, however, allowed to define the solution architecture by way of  "constraints" on their solution.  These "constraints" take the form of:

1) All the information must be together.
2) There must be a Table of Content.
3) All information must have a reference back to the original source.

You have done this so often though, that you and these engineers have agreed that these constraints can be grouped together and referenced by a simple name, its architectural style name, instead of enumerating each one every time.  This is beneficial because you know that certain constraints, when grouped together, evoke certain properties that are commonly desired by your customer.  This allows you to quickly match up your customer's needs with some starting constraints.  Now, you've previously agreed that constraints 1+2+3 above will be referred to as the Compilation Architectural Style.

It turns out that the constraints of the Compilation Style are a good starting point but they don't evoke all the properties that your customer really wants. They want something that's lightweight because they travel, they want something that's easily readable, and they also want something that doesn't require electricity/technology.

So you begin with an instance of the Compilation Architectural Style and add some concrete constraints to get you from "style" to a real architecture and evoke some properties specifically desired by your customer.  Namely, you add the following:

A) Compilation Architectural Style
 - evokes all properties known by the style
B) Information must be on paper
 - evokes lack-of-technology property
C) Information must be printed in Times New Roman
 - evokes readability property
D) Must be in a thin plastic binder
 - evokes lightweight property

So, you pass along the customer order and your solution architecture to the engineers.  Because you've chosen to define your solution architecture in terms of "constraints that evoke properties," you're able to objectively reason about them.  So, when the engineers come back and say that they'd prefer Helvetica because, being sans-serif, it would save on toner cost, you can reason about how changing this constraint might effective your overall solution architecture.  In this case, that level of font-specificity was simply you trying to flex some control where you have none, so you acquiesce. Likewise, the engineers come back and ask that you change constraint D to heavy-weight paper since it'd be a bit lighter - you, again, agree that it still evokes your desired property.

You deliver your solution, which makes your customer happy.  But then you realize that you ought to capitalize on your latest back and forth with the information engineers.  So, you go to the engineers and agree to call constraints B+C+D the Paperback Architectural Style.  In future requests like the original, this allows you to simply refer to a hybrid (Compilation Architectural Style + Paperback Architectural
Style) solution architecture and know that the desired properties will be evoked.