Richard Cowin describes an often overlooked concept "Disposable Software" in a recent blog entry. In my opinion, this seemingly basic concept that software is not forever is integral to making good architecture and product development decisions.
I believe that the idea "software is temporary" increasingly rings true in the world of Service-Oriented Architecture (SOA). Jini incorporated this into it‘s programming paradigm with the incorporation of the "lease" concept. A service or client leases an amount of time with it‘s software dependencies as an expected lifespan, duration to use a service, or renewal period. Services are likely to be available if a lease is active for that service. We can download the binding to that service based on a contract and decide what to do when the lease for that service is expiring. If the contract does not change then a new version of the service may be deployed and when the old version‘s lease expires all of the consumers of that service may get the new version‘s binding. This allows reasonably granular services to be upgraded easily upon lease expirations.
Even in the XML web services world there is this thought of decommissioning software. Multiple vendors have developed strategies for registering, instrumenting, monitoring, advertising, and removing services based on web services. I have listened to discussions on the use of COBOL transaction services deployed to mainframes which paralleled the SOA concepts of granular services with specific operational goals. I heard that there may still be print jobs generated from these deployed services. The developers and business owners of these services are no longer available to convey a strategy for removal. Those services which are running without any currently identifiable business value are operational debt for the businesses in which they are deployed. Many established SOA strategies have taken this into consideration. Services at the right granularity can be tracked with metering which could lead to eventual removal of a service based on Service Level Agreements (SLA).
When consulting customers on introducing SOA to the organization, service removal is a high priority topic to help drive a successful SOA initiative. Services in most good SOA strategies map to a business value. When the business value is no longer relevant we must be able to remove the service effectively in order to cease further operation debt. You may even deprecate a version of your service and later remove it when all of the consumers of that service no longer use it or employ more drastic strategies to remove services. Operational costs in maintaining software is usually the biggest cost of all for large organizations. We must do what we can to make sure these costs are controlled effectively.
