Task: Identify Candidate Services from Business Use Cases
This task is performed to identify candidate services, using business use case realizations as input.
Purpose
The purpose of this task is to identify candidate services from business use case realizations.
Relationships
RolesPrimary: Additional: Assisting:
InputsMandatory: Optional: External:
  • None
Outputs
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.
Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
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
Task: Identify Candidate Services from Business Processes is an alternative, in cases where business behavior is described using conventional business process notations, rather than using business use case realizations.
More Information