Service-Oriented Analysis (Service Modeling)

Service-Oriented Analysis represents one of the early stages in an SOA initiative and the first phase in the service delivery cycle. It is a process that begins with preparatory information gathering steps that are completed in support of a service modeling a sub-process that results in the creation of conceptual service candidates, service capability candidates, and service composition candidates (Figures 1 and 2).

The Service-Oriented Analysis process is commonly carried out iteratively, once for each business process. Typically, the delivery of a service inventory determines a scope that represents a meaningful domain of the enterprise, or the enterprise as a whole. All iterations of a Service-Oriented Analysis then pertain to that scope, with each iteration contributing to the service inventory blueprint.

A key success factor of the Service-Oriented Analysis process is the hands-on collaboration of both Business Analysts and Technology Architects. The former group is especially involved in the definition of service candidates within a business-centric functional context because they understand the business processes used as input for the analysis and because service-orientation aims to align business and IT more closely.

Process Overview

A separate analysis is dedicated to each business process definition associated with a
given service inventory. For the full definition of a service inventory blueprint, a complete
top-down delivery process is
carried out, comprised of numerous
iterations through service-oriented
analysis process steps.

The figure shows how service-oriented
analysis actually represents a parent
process consisting of two
information gathering steps and
then a third step represented by
the service modeling sub-process.

Information Gathering Steps

Define Analysis Scope

During this step business analysts are asked to clearly establish the
boundary of the analysis. Most commonly, there is a ratio of one
analysis process to one business process definition. However, business
processes can be complex or multi-layered (containing nested
processes) and may or may not already be representing portions
of business logic already analyzed during a previous iteration of the
service inventory analysis cycle. Therefore, this step may also
require identifying portions of a given business process for which
service modeling is not required.

Identify Affected Systems

It is helpful to have an understanding of what existing parts of the enterprise will be
affected by the scope of the planned business process analysis. Especially relevant are
legacy systems that may later raise service encapsulation and autonomy challenges.
These types of constraints can directly impact the partitioning of logic into services and
the ultimate granularity at which service candidates are defined.

Service Modeling Process

Service modeling is the process of conceptualizing services and capabilities prior to their
actual physical definition and development. Because nothing concrete is defined during
this stage, we qualify the results of carrying out this process with the term “candidate.”
Service modeling essentially identifies service capability candidates that are grouped
into service candidates that are subsequently assembled into service composition candidates.

The iterative nature of the aforementioned inventory analysis allows for service
candidates to be repeatedly revised and refined prior to the creation of corresponding
services.

The service modeling steps displayed in the previous figure are explained in detail in “Service-Oriented Architecture: Concepts, Technology, and Design.”
In a nutshell, a business process definition is decomposed
(Step 1) into its most detailed representation, resulting in a series of granular actions.
Those suitable for service encapsulation become potential service capability candidates
(Step 2).

The service logic of each capability candidate is assessed in terms of whether it is specific
or agnostic to the current business process. Agnostic capability candidates are
grouped into agnostic service candidates usually based on entity and utility service
models (Step 3), whereas non-agnostic capability candidates are placed into a task service
candidate with a functional scope usually equivalent to the business process (Step 4).

During subsequent iterations of this process, the chances of identifying already defined
capability candidates increase. Therefore, a separate discovery step (not shown) is
added to ensure that no redundant capability or service candidates are introduced into
the blueprint. Also select service-orientation principles are applied to shape modeled
service candidates in preparation for their eventual designs (Step 5).

The following three service-orientation principles are typically applied during the service
modeling process:

• Service Reusability
• Service Autonomy
• Service Discoverability

After the initial set of service candidates is established, a candidate composition is
assembled and subjected to possible runtime scenarios (Step 6). Subsequently, each of
the identified service capability candidates is further studied to explore any additional
processing requirements that may be needed to carry out its functionality. This kicks off
the second half of the service modeling process (Steps 7-12) during which additional
utility service capability candidates are generally defined. The process ends with an
extended composition candidate modeling step and a final revision of all capability and
service candidate definitions created so far.