Enterprise software developers who want to approach service orientation properly need to understand that service orientation is not simply about writing software. Service orientation is about discovering, creating and supporting the services that define an organization. All BEST, REST, WCF and implementation discussions aside, services are the critical value-add set of policies and practices that support an organization's mission-critical operations.
There is no doubt that many services provided by an organization can be streamlined, simplified and made cost effective by providing them as a software based service. But at the same time, any service that can be provided through software may need to be supported without computers being involved at all.
Thinking about service orientation differently
Designing in support for critical business services, even when computers are unavailable, is not a trivial task. The continuation of services any government provides is a great example. If the whole Internet came crashing down tomorrow, one can rest assured that the Internal Revenue Service (IRS) would manage to survive. The host of paper-based forms harvested every April by the IRS is a keen demonstration of how services that are critical can be supported by both automated, as well as non-automated, means. Regardless of whether paper forms get scanned using optical character recognition (OCR) or sent for manual data-entry, when the lights go out, the services at the IRS continue.
There are several lessons to be learned from the IRS. First, not all services need to be supported when a crisis happens. During critical times, only mission-critical services need to survive. Moreover, when viewed in terms of how a business service may have been implemented in the past, considering how a service may be supported outside of the software realm can provide insightful lessons for software developers.
Like the IRS, many businesses love paper. Paper forms are tangible. With paper, core pieces of information can be restructured, new elements added, and old elements pruned away at the mere stroke of a pencil. With paper based systems, changing fields is as easy as changing an original, then printing up the necessary number of replacement copies. Enhancing, as well as version-managing our computerized services as succinctly as those classical paper-based systems may be an obvious point, but it's one that the software industry is still hard pressed to learn.
Consider the advent of Microsoft's venerable Windows Communication Foundation (WCF). The key value add of WCF is the ability to codify several data formats, as well as several service endpoints, via a single service-definition. The key benefit of this approach is that a single, automated WCF business service is capable of anticipating and supporting different service levels. Subject matter experts have always known that a business service has a propensity to change over time, but it is a reality to which software standards and software professionals have willfully remained ignorant. As software standards catch up to this reality, many of the books on SOAP and REST will need to be rewritten.
The philosophy of service orientation
To conclude, we only need note that service orientation is a philosophy, not a technology. By thinking about the systems we are developing in terms that venture beyond the constraints of networks, Java code, endpoints and data-formats, our supporting automation activities will be far more flexible, ever more useful, and certainly more cost-effective. In short, enterprise architects and software developers will be providing a level of service assurance, if not outright gap analysis that truly meets the business-needs of our end users.
Let us know about your best practices and philosophies for best approaching the development of service oriented systems.