Task: Improve the Analysis Model
Review service candidates together
Disciplines: Service-Oriented Analysis
Purpose
Make certain all services have been identified and eliminate redundancies.
Relationships
Main Description

The scope of this step is dependent on the goals of the project in terms of achieving optimal service reusability, autonomy, and so on (in other words, the extent to which the project is striving to realize all of the potential benefits of service-oriented computing). The objective of this step, which actually represents a potentially iterative process in its own right, is to refine the analysis model to maximize reuse potential and other SOA benefits. In the extreme case, this step could be completely omitted, and the “unoptimized” analysis diagram created in the previous steps could be used as-is in the design stage.

Iterate on the following steps (or just those steps that are deemed to be relevant to the project) until the project's stakeholders are satisfied with the results and authorize moving into the design stage.

Steps
Analyze the underlying processing requirements of each process-specific service task candidate to determine if there is more processing logic that should be extracted and added to the utility application services layer as reusable process-agnostic operations.
  • This processing logic will be executed in support of the actions described in the service task candidates.
  • This relationship is based on the common factors between the processing functions represented by the service task candidates.
Review the service candidate model to determine if there are any missing processing steps or workflow logic, using the business process model and domain object model as authoritative sources, and add any additional service candidates and service operation candidates that are required.
Review and refine the modeled composition of services to achieve an optimal alignment with the business process model.
Revise the choreography models as necessary to reflect knowledge of new services gained during the current iteration.
Also incorporate anything else we have learned during the service-oriented analysis iterations in the choreography models.
Add supplemental textual information and metadata to candidate service definitions in support of enhanced discoverability.

Ultimately, each implemented service will be documented in a Service Profile (unless the organization chooses to omit this for any of various reasons). A Service Profile is a readable artifact, typically stored in an enterprise-level repository, that describes those aspects of implemented services that are needed to support discoverability and service maintenance. Service profiles are  a key element in what is known as “SOA Governance.”

At a minimum, a Service Profile contains each service's “technical service contract,” which is an artifact created during the design stage. Since the technical service contract is often fully specified in a modeling language (such as UML), in the extreme (minimal) case the service's model may be considered to be the Service Profile.

However, the technical service contract is not business analyst-friendly, and does not contain supplemental textual material that may be needed to completely understand the usefulness of a given service in new contexts, such as service level agreements and other QoS factors.

Therefore, an organization will typically associate textual information and metadata with technical service contracts, creating “documents” (service profiles) that are stored in a specialized repository.

While the finalization of a Service Profile is a deliverable of the project's development stage, useful textual information and metadata surfaces as early as the analysis stage, and the purpose of this (optional) step is to begin the structured capture of this textual information, in the form of a “skeletal” Service Profile.

More Information