March 1, 2021
Hot Topics:

Producing and Consuming Business Services

  • By Jeff Ryan
  • Send Email »
  • More Articles »


In the last article, Understanding Business Services , we discussed how business services bring the potential for a level of reuse beyond what we have seen before. Business services reflect and model the business. Business services can be readily understood and utilized by heterogeneous clients within a company and even by external partners. Business services can radically reduce development, maintenance and operational costs and are a potential source of revenue.

This all sounds wonderful. But, before jumping in and becoming a service provider or service consumer, there is an organizational aspect to service orientation that should be considered. Service orientation is about more than architecture. Becoming a service provider or consumer is a serious commitment between two parties that promises certain benefits and entails certain risks. Each party assumes certain responsibilities when entering into this relationship.

This article will discuss organizing principles of producing and consuming business services that should be considered before publishing a service or utilizing a partner's service:

  • First, we'll discuss the basics of providing and consuming a service.
  • Next, we'll discuss the benefits, commitment, and risks involved in being a service provider and consumer.
  • Then, we'll discuss the roles and responsibilities within a service provider and service consumer IT organization.
  • Finally, we'll summarize what we've learned.

Providing and Consuming a Service

By definition, service orientation means that one party provides a service for another party that consumes or uses the service. It may be helpful to think of common service-oriented professions; for example, a doctor providing an office visit service to patients or an accountant providing a tax return service to individuals and businesses.

In service-oriented architecture, a service provider develops a business service and publishes it in a registry. The registry is a "yellow pages" of sorts that describes the service, its service requests or methods, and service levels. The registry may be exposed inside the company firewall, to trusted partners, or even to the general public. Once the service is published, the service provider is now "open for business" and ready to accept client requests.

Service consumers may find a service endpoint in the registry, bind to its contract, and execute service requests. But, prior to actually using the service, it is likely that the service provider and service consumer have sat down at the table together and discussed their relationship with one another. It's really a contractual relationship. The contract may include the following, among other things:

  • the published API of the service that the client will use to access the service at the code level;
  • the service level agreements which specify the reliability, availability, scalability, performance, and security commitments;
  • remuneration for using the service;
  • an agreement that the client application will be insulated from changes to the service.
Note: One day, service consumers may dynamically find a commodity business service in a registry from many potential providers. For now, it is more than likely that the service provider and consumer will sit down at the table together and hash out the details of their contractual arrangement rather than do this "on the fly."

Understanding the Stakes

A stakeholder is someone who has skin in the game: There is something to be gained and there is something to be given. When it comes to service orientation and business services, there is much to be gained for service providers and consumers alike. However, there is a degree of commitment required and significant risks that must be managed as well. Before a service provider and service consumer enter into a contractual agreement, the benefits, risk, and commitment should be well understood by each party.

Business Service Provider Stakes

What does the service provider have to gain?

An intra-company business service will enable a company to get to market quicker with its products by assembling applications from existing services rather than building them from scratch. Maintenance costs will decrease because functionality will not be duplicated. Operational costs can be reduced if services are deployed on common infrastructure. Existing assets can be exposed as a service and further leveraged instead of retired or duplicated.

An inter-company business service provides a new way of collaborating with partners. It can expose new distribution channels. The business service could even be a direct revenue source if external clients pay for the using the service.

What commitment is required and risks taken by the service provider?

In the case of an intra-company business service, the service provider is making some sacrifices for the benefit of itself and other organizations within the company. As the saying goes, "No pain, no gain." It's harder to build and maintain an interoperable service than to build an internal component used by a single application. Changes to the service must be implemented in a way that will not affect existing clients. This means that a service provider is committing to more design and testing.

In addition to the business function it provides an interface for, a business service must meet agreed-upon quality attributes or non-functional requirements such as reliability, availability, scalability, performance, and security. If it doesn't meet these requirements, it can mean anything from lost credibility to lost business. The service provider must give ongoing attention to the service-level agreement commitments made.

Business Service Consumer Stakes

What does the service consumer have to gain?

It may now be possible to assemble an application quickly from existing services. This means that applications can be constructed cheaper, faster, and be more reliable. By eliminating duplicate effort and insulating applications from change, future maintenance costs will be reduced. The client application itself will not have responsibility for ongoing support and maintenance of the functionality being leveraged from the service.

What commitment is required and risks taken by the service consumer?

The business service may not be able to handle the volume of requests from the client application. It may not meet the performance, availability, and security requirements. If the provider does not implement change carefully, the client application may unexpectedly break. Changes to the published API of a business service may not be discovered until run time, meaning that the service consumer may not have advance notice of a change and will have to react quickly.

It's entirely possible that a service will be discontinued or deprecated. The service provider may go out of business. The client application has created a dependency with the service and the service provider. Because the client application is dependent upon the interface, the implementation may change without affecting the application. But, a new provider will need to be found who can implement this interface and meet the client application's functional and non-functional requirements.

Page 1 of 2

This article was originally published on July 7, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date