This report is a PSG Classic - Originally Published January 2005.

NETTING IT OUT

In this report, we demonstrate our four-step Service Discovery Methodology to help you build a strong, business-driven services catalog.

Unlike other service definition methods that focus on application decomposition, ours starts with understanding the needs of your business—using our Customer Scenario® Mapping methodology—and then launches into service-discovery-specific tasks. In Service Discovery, we help you find and refine your services with their collaborators, analyze your services catalog, and surface requirements for your SOA environment.

We support our Service Discovery Methodology with tools and techniques that include a service classification scheme, a service/work/collaborator template for service refinement, service naming conventions, service definition and granularity rules of thumb, our “Be the Service” technique, and services catalog analysis starter questions.

DISCOVERING THE RIGHT SERVICES FOR YOUR BUSINESS

In our previous service-oriented architecture (SOA) report, “The Evolution of Service-Oriented Architecture,” ¹ we discussed the SOA evolution, starting with the use of services for simple integration, and finishing with our belief that services are the springboard for business scenario development. ² In that report, we asserted that the keys to successful service-oriented architecture adoption are a strong services catalog and an extensible SOA environment.

The measure of a strong services catalog is not in sheer number of services, but in the coverage and business opportunity the services provide. The collection of services in your catalog must match the functional depth and breadth of your business and technical infrastructure. In addition, it must be easy to assemble your services into larger-grained services and business solutions.

To build a strong services catalog, you need to adopt service definition practices that adhere to best practices of service naming, bounds, and granularity. Of course, well-formed services alone are not enough. Your services need to reflect your business, allowing you to deliver solutions that meet the ever-changing needs of your customers, partners, and internal constituents.

With this dual focus in mind—best practices in services definition and business-driven solutions—we developed our Service Discovery Methodology as an extension of Customer Scenario® Mapping. Using service discovery, you can find and define the right services to fulfill your customer- and partner-adaptive business scenarios.

IN THIS REPORT

We share our Service Discovery Methodology and related practices by example, using a customer-adaptive business scenario from a fictional merchant, Trucker Joe’s Gourmet Candy. Before getting into the details of service discovery, let’s begin with our definition of service.

SERVICE BASICS

What Is a Service?

Simply stated, a service is a thing that fulfills a purpose. A service is, in essence, a “worker,” employed to achieve a specific end goal for a requester. The end goal may be small in scope, such as retrieving information, or large in scope, such as executing a business process. Most services are in the middle, completing a function. The scope of a service is referred to as its grain, or level of granularity.

WHAT KIND OF THING IS A SERVICE? A service is an abstract resource that has a name, a job, job tasks, contact information, and policies regarding security and service levels. The job tasks of the service correspond to physical code assets (objects, components, legacy code, application package APIs), but only the service knows these specifics. From the requester’s point of view, a service is a (small) black box. To use (request) a service, you send a message—in accordance with the contact information and policies—and then (if appropriate) receive a reply message. The details of the service execution are unimportant to you. You are only concerned that the service does its job and returns understandable results.

A SERVICE’S JOB. The job of a service is limited to a single distinct business concept, function, or process. This characteristic is referred to as the bounds of a service. Finding the correct bounds is a key factor in service definition. A service may call upon other services if it needs assistance to complete its job. This service-to-service relationship is called collaboration.

OUR SERVICE DISCOVERY METHODOLOGY

Four Steps, Starting with Customer Scenarios

In our Service Discovery Methodology, we are concerned with finding and defining the services that make sense for your business. The services we are discovering are, as mentioned above, the abstract things that provide utility for a requester.

While many people look for services as part of a functional decomposition exercise—looking at an existing application or problem domain and breaking it down into parts—our methodology revolves around your business and the work required to fulfill the needs of your customers, partners, and internal constituents. We achieve this business focus by starting with our Customer Scenario Mapping methodology. As scenario mapping completes, service discovery begins, with a process, tools, and techniques to define your services and their collaborators, analyze your services catalog, and surface requirements for your SOA environment.

The service discovery process has the following four steps ...

**Endnotes**
1) “ The Evolution of Service-Oriented Architecture: From Integration to Business Scenario Development ,” January 6, 2005.

2) In business scenario development, IT business solutions will be compositions of services, business events, and business processes mirroring the interactions (or flow) of your business.

3) For more information on CSM, see “ Saving Customers’ Time: Master Customer Scenario Design ,” by Patricia B. Seybold, June 7, 2001.
**Endnotes**