Why contracts help migration

Now there are some people who think that validation is a bad idea, but recently I've seen a few cases where contracts have really come to the fore again. One of these is around migration. The scenario is pretty simple, you want to start moving to a new solution area but you don't want to do it in one go, you want to clearly split the area into two pieces, the consumer bit and the producer bit. Most likely its the producer that is going to be replaced but you don't want to like the two parts tightly together so they have to upgrade at the same time and the same pace.

So what do you do? Well first off you define a formal contract between the two areas, one that can be fulfilled by the current implementation and which can also be supported by the new service when it arrives. Effectively you've now split up the two worlds and placed an agreed boundary between them which can be enforced, tested against and measured against. You are now in the situation where the new implementation has to meet the contract and where the consumer can now rely on that contract independently of the implementation.

When looking at splitting up areas, or migrating applications and software the enforcement of clear contracts is a very simple way to start introducing business centric contracts and to provide a controlled way in which upgrades can be handled for both producers and consumers. Not using contracts means there isn't something to test and validate against and thus the new implementation is aiming more at an abstract goal than a concrete reality and the consumers have nothing to rely on as they plan their own future improvements.

Contracts therefore increase the flexibility of complex systems explicitly because they enforce the boundaries.

Technorati Tags: SOA, Service Architecture