Why contracts give flexibility....

As per the last post there has been the standard "flashback" from a bunch of people who crusade first and think later.

So lets explain in simple terms how strict contracts give flexibility, and to make it really easy I'm going to use four examples, firstly REST (which the "don't validate" crowd follow) and secondly LEGO(r) which the "I don't understand SOA but I'm going to use this as an analogy" crowd try to go for. The final examples are... well I won't spoil the surprise... So I should cover lots of bases here

So first off lets look at HTTP, it has a very strict contract with a limited number of possible actions, GET/POST/PUT/etc and an extremely limited way of getting to those actions. Now interestingly the entire concept of REST is that this limited and tightly specified set of actions when rigorously enforced provides an infinitely flexible architecture on which to built things. So HTTP is in fact an area which has a pretty tight set of up front validation (try sending random packets to Apache or Firefox to see where it gets you) and an extremely limited and well specified set of actions with which to interact with the server.

So simply put the REST people who are claiming that you shouldn't validate are exactly the same people who are claiming that you should rigidly adhere to a tight specification and reject anything that (for instance) stops GET being idempotent. So here is a great example of a tight specification being used as the implementation approach for complete flexibility.

Next up lets take Lego, you have a "brick" it has a bottom which has set dimensions and a top which has set dimensions, amazingly despite limiting the specification of the brick to having exactly the same form and function top and bottom the potential for Lego is practically infinite, you can do Star Wars, Air Force One and really odd stuff. This is all managed via a very strict contract as to how the different bricks connect.

My third example is the wonderful world of IKEA. IKEA uses pretty much the same screws in every thing they do, they use the same sort of connectors in everything they do, and lots of times they use the same size of wood, just combined in different ways. Having tight specifications like this that mean they only need certain sizes of doweling or screw gives them an immense (and profitable) flexibility in what they can create.

Tight specification can often be used as the basis of flexibility rather than rigidity, but having these tight specification means that you, as an engineer, need to understand the boundaries within which you operate.

The final example comes from the wonderful world of Pimp my Ride and more particularly the world of tyres and "rims". Having a set size for wheels and a tight specification doesn't decrease the flexibility it positively increases it. There are a massive amount of tyre and rim combinations available so one car could have three tyres from one manufacture alone and a set of 4 rims from the first hit on Google. For the mathematically minded that is 12 different combinations on a single crappy Ford Focus.

This is why specifications are engineering, if you could say "I wish that I could just do this because its cool" then you'd be a liberal arts major. Having specifications can increase flexibility when you know how to use them and use them in a smart way. This is the reason that screws, nails, hinges, doors, trains and lots of other things obey a specification. Specifications are the best way to get things to inter-operate. The REST crowd should know this better than most with their mantra of "standard HTTP", but unfortunately too often people are beguiled by an idea which makes them contradict the benefits of what they are saying is right.

Specifications give flexibility because they tell people what can and cannot be done, people are then very adept at modifying their behaviour and their world to cope with these limitations.

It would be completely wrong to say that this was Darwin in action, but its completely right to say its how adaptation works.

Technorati Tags: SOA, REST, Service Architecture