Task: Identify Candidate Services from Business Use Cases |
|
 |
This task is performed to identify candidate services, using business use case realizations as input. |
Disciplines: Service |
|
Purpose
The purpose of this task is to identify candidate services from business use case realizations. |
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Process Usage |
|
Main Description
This task uses business use-case realizations as input and identifies a set of candidate services
that are included in the project candidate service portfolio. These candidate services might yet require additional
refinement, however the steps included here provide an effective manner in which to produce an initial set of service
candidates.
A business use case realization describes interactions between actors and business-relevant elements, to deliver
something of measurable value to one or more of the actors. As is true with business processes, business use
cases -- and their associated realizations -- can be defined at various levels of detail within the business (see Guideline: Decomposing Business Processes). At the highest level, the business
elements involved in the realization might be business domains. The next level of detail might involve
interacting functional areas. Going yet another level down, the interacting elements might be business subsystems
or business workers within a functional area (see Concept: Functional Area Analysis).
Analysis performed at each of these levels of detail can be valuable, because they will result in operations
that represent different levels of entry into the overall business behavior. For example:
-
Operations discovered at the level of interacting business domains might represent initiation of large-scale
business processes
-
Operations discovered at the level of interacting functional areas might represent initiation of significant
sub-processes that are wholly owned by a functional area
-
Operations discovered at the level of interacting business subsystems might represent entry points into leaf-level
sub-processes, which are the gateways to IT system use cases
In this task, the work product slot of [Business Design] is filled by Business Model, which includes business use case
descriptions.
Tool Mentor: Build a SoaML Service Model Using the SoaML Template is the entry
point into a family of tool mentors that collectively describe how to build a SoaML-based service model using IBM® Rational® Software Architect. This tool mentor provides an overview description of a process for using the tool to create
the model. It includes callouts to several other tool mentors that accelerate Service Identification efforts.
|
Steps
Decompose the business use-case realizations (optional)
For maximum benefit, this task needs to be performed using a business use case realization model [Business
Design] that is decomposed such that the operations involved in the lowest level of realizations can themselves be
mapped, either singularly or collectively, to system use cases. If this degree of decomposition has not been
achieved, then perform business use case realization modeling techniques to achieve it. Such techniques are
beyond the scope of this practice. They are addressed, for example, in the IBM Practice Library's Use-Case-Driven
Business Modeling practice.
|
Identify relevant business use-case realizations.
All of the business use-case realizations in a corporate business use case model might not be relevant
to a current project. |
Eliminate fine-grained operations that interact with a user interface
If such operations are discovered in a business use case realization model, the model has been overly decomposed.
Make the business analyst team aware of this issue. |
Eliminate highly-abstract business use-case realizations
This is the opposite case from the previous task -- the realization has not been decomposed. If this realization
is relevant to the current project, the business analyst team needs to re-visit the realization and
decompose it. |
Identify candidate services from business use-case realizations.
In general, create a candidate service for each operation defined on each business element that is involved in the
realization. There exists a distinct parallel here to the Task: Identify Candidate Services from Business Processes where individual
tasks in a process model are identified as candidate services.
Figure 1. Candidate service identified in a business use-case realization
This fairly direct connection between the business model and the service model allows for not only services that can be
seen to support the business needs, but by having less transformations between the expression of business needs and the
solution, you can more effectively respond to change in the Business Use Case or Business Models. Another important
aspect is that because the Business Use Case model also includes the Business Goals that are driving the business, it is now
much easier to actually identify the alignment between Services and Goals. For example, it is now possible to list, for
any Capability, all the Business Goals to which it contributes. For any Business Goal we can list the Services actually
deployed in our IT organization that contribute to the goal, by following the connection from Capability to
ServiceInterface.
|
Refine candidate service specifications
In some cases the set of operations defined in the business use case realization might more correctly reflect a
conversation between parties related to a single service than it does to a set of distinct services. In such a
case, the operations might be aggregated onto a single service specification (as shown in Figure 2). The drawback to this
approach is that it requires more detailed analysis and understanding of the use case realization, and the role of
the business elements within it, to identify this as a requirement.
Figure 2. Aggregate the operations onto a single service
Conversation means that often the actual completion of a service requires multiple interactions between
parties. For example, if you examine the Place Order service, you might actually find that this is a complex
set of interactions including acknowledgments, shipping notices, negations (for example if items are unavailable), and so on. |
Update candidate service portfolio and service hierarchy
Add the new candidate services to the candidate service portfolio. Position them within the candidate service
hierarchy, in alignment with your chose taxonomic approach. |
|
Key Considerations
Identifying candidate services from business use case realizations is one of several schemes that complement each
other during candidate services identification. Omitting any of the methods increases the risk that some candidate
services will not be discovered.
|
Alternatives
More Information
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.
|
|