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.
This report is a PSG Classic - Originally Published January 2005.
DISCOVERING THE RIGHT SERVICES FOR YOUR BUSINESS
In our previous service-oriented architecture (SOA) report, “The Evolution
of Service-Oriented Architecture,”1 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.2 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:
1. Customer Scenario Mapping
2. Find Your Services
3. Refine Your Services
4. Services Catalog Analysis
The participants in the first three steps are a combination of business personnel,
business analysts, IT architects, and IT designers. Augmenting the internal
team in step one are customers and partners. The fourth step, Services Catalog
Analysis, is an IT function, performed by IT architects and designers. Upon
completion of service discovery, you will be ready to prioritize your services
and then transition the high-priority services to your development staff
for service realization.
Our service discovery tools and techniques include a service classification
scheme, a 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.
STEP 1: CUSTOMER SCENARIO MAPPING
The service discovery process starts with the business—specifically with
business modeling, using Customer Scenario Mapping.
What Is Customer Scenario Mapping?
Customer Scenario Mapping (CSM) is the Patricia Seybold Group’s methodology
of business modeling from the outside in—looking at the world (and your
business) through the eyes of a customer.3 Central to CSM is the Customer Scenario.
A Customer Scenario is the ideal set of tasks that a customer wants—or
is willing—to do to achieve a desired outcome. The scenario starts with
the customer’s need, includes (but is not limited to) interactions with
your business, and ends when the customer has accomplished her objective. Customer
Scenarios are your customers’ ideal processes for accomplishing their
outcomes—not the way they do things today, but the way they would really
like to do them. You generate Customer Scenarios by co-designing them with
representative groups of customers, partners, and stakeholders in a facilitated
half-day Customer Co-Design session.
To demonstrate service discovery, we will work with a simple Customer Scenario
and map, using the basic components of CSM listed in Table A with their definitions.
Trucker Joe’s Gourmet Candy Customer Scenario
Customer Scenario Mapping begins by identifying a scenario, and then describing
the customer, the scenario context, the customer’s desired outcome
and his conditions of satisfaction. The scenario we will be using for service
discovery is from our fictional gourmet candy merchant, Trucker Joe.
Trucker Joe runs a chain of gourmet candy shops at truck stops located throughout
the United States. Truckers can order candy in advance (phone, Web) or make
retail purchases at a truck stop candy shop. The scenario write-up follows.
Illustration 1 shows the Trucker Joe Customer Scenario map.
SCENARIO DESCRIPTION. A truck driver on a west coast route wants some praline
candy ASAP, and he needs to send a gift to his friend, who is currently on
a different route along the east coast.
CUSTOMER DESCRIPTION. Stan is a 45-year-old truck driver who owns his rig.
He trucks fruits and vegetables along the west coast. Stan makes his living
hauling health food, but he prefers candy—the higher the sugar content,
the better. Stan is a frequent customer of Trucker Joe’s Gourmet Candy.
Stan likes supporting a fellow trucker, and he thinks Trucker Joe’s
candy store shops at truck stops are brilliant.
Bert, Stan’s friend, is a 49-year-old trucker who drives the east coast.
Bert has made an art of keeping his truck full at all times. In his quest for
optimizing capacity, Bert frequently changes his route, but always meets his
schedule.
CONTEXT. Stan is hauling artichokes and avocadoes and is having a sugar craving.
He wants to pick up some praline candy (his favorite) when he refuels his
rig. Stan also just remembered that Bert’s fiftieth birthday is Thursday,
and he’d like to surprise Bert with a gift at his refueling stop on
Thursday. There are two problems though: Stan doesn’t know what Bert’s
favorite candy is, and Bert could be in either Connecticut or Georgia on
Thursday, depending on how he chooses to keep the truck full.
DESIRED OUTCOME. Stan gets praline candy for himself ASAP. He feels happy and
satisfied. Bert gets his favorite candy on his birthday and is delighted
and surprised, but not inconvenienced.
Ideally, Stan wants to pre-order the candy and have a runner bring it to his
truck as he refuels. Stan also wants a gift ready for Bert on Thursday in
both Connecticut and Georgia. Stan will pay for whichever one Bert picks
up. Stan wants Trucker Joe to notify Bert Thursday morning that a gift is
waiting for him.