10 Rules for Services Design
Follow these practical guidelines to create compelling services for partners and customers
by John McDowall
Web services are enabling organizations to change the way they deliver services. Fortune 500 companies are building services-oriented architectures (SOA) and offering services to customers and partners in their value chain. E-Commerce companies such as Amazon and eBay are enabling thousands of developers to create innovative applications by opening up Web services APIs. Providers of services-based enterprise software applications such as Salesforce.com are providing Web services APIs to enable customers and partners to extend their solutions.
The key to capturing the value of these efforts is to create and deliver well-designed services that extend and build on those exposed APIs. Consider these 10 guidelines for designing successful software services.
1 Design services to be shared: The value of a service is magnified by the value of the relationships enabled. Being shared does not mean the code is shared; the service is shared. One of the important advantages of a services-based model is that the provider of a service is not concerned with the consumer's platform and the consumer does not have to install and maintain software. Services enable the acquisition of new functionality without having to deploy and maintain new applications.
2 Services have a clear purpose: The business value of services to consumers of those services must be clear and unambiguous. To maximize the value of services, it is necessary to understand the core competencies your organization provides to others. When this business value can be articulated clearly, it defines the requirements for services that are useful to others in your value chain.
3 Services are discoverable and support introspection: To share services, the producer of a service must be able to publish it in a form the consumer of the service can find and bind to dynamically. The consumer must be able to discern how to use the service without having to talk person to person to the producer of the service. The conversation on how to use the service is ideally machine to machine.
4 Services are designed to be loosely coupled: Services are intended live in a loosely coupled environment and should use other services to perform common clearly defined tasks (for example, authentication or reporting). The value of services is magnified by their reuse and further magnified by their ability to be combined with other services to create new services. As services are typically owned by multiple entities, they need to be loosely coupled to allow each one to change and evolve independently of the others.
5 Services plug into a framework: Once a service has been discovered, it needs a framework that provides other common services and loose coupling. While services may be created without an SOA, they need an SOA to operate in. SOAs by their nature are federated, as they need to interact in a loosely coupled manner.
6 A service has a well-defined use policy/contract: It is important to realize that in a services model both the consumer and the producer of a service need the ability to set use polices. The consumer and producer of a service define policies around security, availability, reliability, and error and exception handling.
7 Services accept well-defined input and deliver well-defined output: Business services should consider themselves as a part of a data-flow model that can be piped together. As the services are to be used by others, there must be an interface description of the inputs and outputs that is at a minimum accessible from the network to authorized users and at best machine readable.
8 Services do not have hidden side effects; they play well with others: This guideline is from Programming 101, but it is always worth mentioning. A service should not affect another service except through publicly defined interfaces. When services are used by other services that may change over time, the reliance on side effects is a very bad practice in services design.
9 Services are interfaces to or from processes: Services hide the implementation of a business process through encapsulation, but they expose the inputs and/or outputs to the process. Another way of looking at this scenario is that services must be able to be combined into a process to create other services.
10 Services deliver unintended consequences: The mark of success is when others use your services in unexpected and beneficial ways. The ability to empower and leverage the skills of partners and customers leads to the law of unintended consequences, as formulated by Tim O'Reilly: "Innovation will come from APIs that support 'unintended consequences.'"
These guidelines are not meant to be a formal design methodology but rather a checklist to consider when designing services. As the infrastructure and standards around services evolves, a formal design methodology will emerge.
Enabling software as services enables a degree of agility in responding to changing business demands that is not possible with other approaches. The measure of success is when your partners and customers become an extension of your organization, contributing and extending the ecology of services to improve the efficiency and effectiveness of the shared value chain.
About the Author
John McDowall is chief technology officer of Grand Central Communications, a provider of shared-services networks for business-to-business Web commerce. Contact John at .
Back to top
|