Thursday, February 04, 2010

Why contracts are more important than designs

Following on from my last post on why IT evolution is a bad thing I'll go a stage further and say that far too much time is spent on designing the internals of elements of services and far too little on their externals. Some approaches indeed claim that working on those sorts of contracts is exactly what you shouldn't do as its much better for the contract to just be "what you do now" rather than having something fixed.

To my mind that view point is just like the fake-Agile people who don't document because they can't be arsed rather than because they've developed hugely high quality elements that are self-documenting. Its basically saying that everyone has to wait until the system is operable before you can say what it does. This is the equivalent of changing the requirements to fit the implementation.

Now I'm not saying that requirements don't change, and I'm not advocating waterfall, what I'm saying is that as a proportion of time allocated in an SOA programme the majority of the specification and design time should be focused on the contracts and interactions between services and the minority of time focused around the design of how those services meet those contracts. There are several reasons for this
  1. Others rely on the contracts, not the design. The cost of getting these wrong is exponential based on the number of providers. With the contracts in place and correct then people can develop independently which significantly speeds up delivery times and decreases risk
  2. Testing is based around the contracts not the design. The contract is the formal specification, its what the design has to meet and its this that should be used for all forms of testing
  3. The design can change but still stay within the contract - this was the point of the last post
The reality however is that IT concentrates far too much on the design and coding of internals and far too little on ensuring the external interfaces are at least correct for a given period of time. Contracts can evolve, and I use the term deliberately, but most often older contracts will still be supported as people migrate to newer versions. This means that the contracts can have a significantly longer lifespan than the designs.

As people rush into design and deliberately choose approaches that require them to do as little as possible to formally separate areas and enable concurrent development and contractual guarentees they are just creating problems for themselves that professionals should avoid.

Contracts matter, designs are temporary.

Technorati Tags: ,


Rob Eamon said...

I emphatically agree. Indeed, one could say that this is *the* key aspect of SOA. The interfaces and contract are expected to live longer and be relatively stable compared to the specific implementation.

Anonymous said...

You've got one more follower here. I recently spent 8 months on a massive mainframe application decoupling. One of the best decisions we made, in my opinion, was to start with the service contracts.

One of the worst decisions we made was to start changing the (wsdl) contracts because our mainframe developers told us they couldn't work with certain restrictions.

The contract sometimes has to change, but make sure it changes for the right reasons.

Neil Ward-Dutton said...

Design by contract! Yay!
With you 100% here Steve.

Anonymous said...

And another follower here. Actually, you could go even one step further (back) and state: start with the information that's being passed around and validate that on consistency and the necessary 'leanness' (especially for migration projects). Only after that, go about the actual contract and attributes.

BTW more on SOA on my blog:

Thanks for your blogs. They help me!

Bart van Riel
The Netherlands.