With numerous publications describing SOA implementation design and very few concentrating on the interface (contract) design, one might assume that implementation’s design is significantly more important and deserves more attention. A common justification for that is the fact that contracts change over time and spending too much time on their definition upfront contradicts the Agile development approach.
In his recent post Steve Jones disagrees with this common misconception by saying:
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. It’s 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.
Steve notes that there are several reasons why contracts are the most important part of SOA implementation:
- 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
- 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
- The design can change but still stay within the contract
The notion of importance of contracts is not new. According to Dimuthu Leelarathne:
If you do not design the contracts between services first, there will be complex integration problems between your services.
In reality, creation of good services contracts is not simple and requires good understanding of the enterprise’s core business. Although there are some well established approaches to service interface design it is still more art than science. As a result, both developers and software vendors are typically focusing on what they are trained to do (and sell) - designing and coding a service implementation. In Steve’s opinion:
... IT concentrates.. 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.. Contracts matter, designs are temporary.
As we continue to promote usage of SOA for business/IT alignment, the role of service contracts aligned with business requirements continues to grow.