Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
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.
Roles and Responsibilities
The provider and consumer parties may reside in the same organization, different organizations, or even different companies. Each party will have the traditional roles in an IT organization: managers, architects, modelers, business analysts, developers, and quality assurance among others. All of these roles play a part in providing and consuming business services.
Business Service Provider Roles and Responsibilities
Let’s take a look at typical roles within a service provider organization and discuss its responsibilities.
An architect provides the service-oriented architecture platform to build, deploy and manage business services. The architect works with the business analyst to determine the non-functional requirements such as reliability, availability, scalability, performance, and security. The architect will also capture and analyze service metrics and initiate improvements to the service and service infrastructure.
A modeler will identify potential services and their fit within the logical service model. The modeler ensures that the service registry contains a coherent catalog of business services and not a junk drawer of services.
A business analyst writes the functional specifications for the business service and works with the architect to determine the non-functional requirements. The business analyst will also initiate changes to the service and applications that utilize the service.
Quality assurance performs functional and non-functional testing of a service. The functional testing determines whether the service meets the functional requirements as defined by the business analyst. The non-functional testing determines whether the service meets its reliability, availability, scalability, performance, and security requirements. An important part of the quality assurance role is running regression tests against a service to be sure it continues to support existing features when new features are added.
A developer uses the service-oriented development platform to build, deploy, and maintain services. Services may be published in internal and external registries to provide clients the service endpoints and interfaces. The developer may provide an implementation or user guide for clients of the service, and may even build and distribute a client proxy component as a convenience to service clients. The developer will use the service-oriented architecture platform to analyze and bring to resolution any problems with a service.
A service manager orchestrates the development, maintenance, and operational support processes. The service manager should know who all the service consumers are and keep a client registry containing contact information. The client registry is distinct from the service registry of published services and service requests. Service metrics will be used to bill clients directly or indirectly.
Business Service Consumer Roles and Responsibilities
Let’s take a look at each role within a service consumer organization and discuss its responsibilities.
An architect is responsible for determining the service consumer platform. This may include utilizing a proxy component provided by the service provider. The architect will determine whether the quality attributes of the service meet the needs of the consuming organization and will outline risk mitigation alternatives. For example, it’s possible to call a synchronous service asynchronously to provide immediate response requirements.
A modeler identifies candidate services in the logical service model and service registries to be used to meet project needs.
A business analyst determines whether the functional specification for the business service meets the project needs. There may be collaboration with the business analyst in the provider organization to extend the business service capabilities.
Quality assurance does not test the service per se, but the application using the service. Depending upon the trust level of the service provider, there may be some duplicate functional testing. Quality assurance also ensures that the business service meets its promised non-functional requirements or quality attributes.
A developer assembles an application from the business services identified by the modeler and business analyst. The service-oriented consumer platform is used to look up business services in a registry and execute service requests or methods.
The application manager runs projects to implement new business functionality, some of which is contained in business services. The manager will initiate and coordinate work with partnering areas such as the service provider. One of the primary goals of the manager in the consuming application is to reduce timeframes and risk by reusing existing business services where possible and practical. Service usage audits provided by the consumer platform will be used to validate any invoices from the service provider.
Summary
While service oriented architecture is maturing, parties may be jumping in without understanding the nature of the relationship between service providers and consumers. Service providers and consumers enter into a contractual relationship with one another, promising certain benefits and entailing certain risks. Before becoming a service provider or consumer, the benefits must be weighed versus the commitment required and risks to be managed. We discussed these stakes as well as the roles and responsibilities in the service provider and consumer organizations. Service orientation is about more than architecture. Understand the organizing principles of producing and consuming business services in order to fully achieve the promised benefits. The rest is up to you!
About the Author
 |
Jeff Ryan is an architect for Hartford Financial Services. He has twenty years experience designing, developing and delivering automated solutions to business problems. His current focus is on Java, XML and Service Oriented Architecture. He may be reached at jryan@thehartford.com. |
