Agile Release Pattern: Support multiple versions
No computer system is an island. At least not these days. This creates a challenge when you want to change APIs: Do you want to upgrade all affected systems at once, or do you want to support multiple versions?
Both approaches have downsides. Coordinating several upgrades increase the risk that one of the upgrades fail, in which case, you may want to roll everything back. In some situations, rollback may not even be possible. So for everything except the simplest cases, a distributed system must expect to support multiple versions of APIs.
For high-risk upgrades within a system, it may still be useful to support multiple version. A common example is database changes. Many database changes are impossible to rollback once they are done. If these changes are made at the same time as a new version is put into production, the result may be disastrous: Imagine that the new version contains some serious defect that makes it unusable. If the accompanying database change cannot be rolled back, the consequence of this defect will be severe indeed.
A special case of multiple versions of an interface is that of a backwards compatible interface. In SQL, adding a new table or adding non-required columns to an existing table is backwards compatible. With web services, adding a new element may be backwards compatible, depending on the XSD that defines the web service. In Java, adding a method to an existing class is backwards compatible.
Backwards compatible changes require very little coordination, especially if clients can stay with the old changes if they don’t care about the new features.
When your changes are not backwards compatible, having to support clients on multiple versions will add to the maintenance cost of the system. You will want to support as few versions as possible and give clients incentives to upgrade to a new version. Incentives can be anything from asking nicely, to providing a cut-off date (if you can live without your clients) or hike up the service fee (if you have one).
The long and short of it is that you want to avoid interfaces where you have to manage the upgrade and versioning. This is why SOA projects that split up the systems in too fine grained services suddenly discover the need for a bureaucratic service governance effort. Once you’ve published an interface, you’re stuck with it forever.