GooBiz

Identity : Identifiable Service Specifications

Intent : This pattern aims at finding out goal-driven services and use cases of a system according to its business capabilities. It also confers to services identified this way a 1-to-1 traceability between their functional and object-oriented representations in order to adapt them swiftly to changes.

 

 

A goal-driven service is a mutualized system function based on a business capability-(i.e.what a business does to reach its objectives, instead of how it does it (its business processes).

 

Solution for Service Identification : Three steps are necessary to identify these services and describe their behaviours according to business capabilities :

 

Step 1 - Model business capabilities on the basis of the Company Vision

 

Step 2 - Identify goal-driven service and use case structures to deliver service levels expected from business capabilities

 

Step 3 - Discover responsibilities of these service structures

 

 

Detailed Explanation

 

STEP 1 - MODEL BUSINESS CAPABILITIES ON THE BASIS OF THE COMPANY VISION

 

In this first step, we are looking for business capabilities ( more stable concept than business processes) on the basis of the Company Vision.

 

Business Capabilities may be named using business objects and states - periods where corresponding business processes will be executed to support these capabilities.

 

The figure below gives an example for business capabilities that support the vision of a WebSale Company. In order to capitalize on the business objects, capabilities are written using Objects with their states in brackets. The state of each business object will be used to host operations of the corresponding business process (cf. step 3).

 

 

Figure 1 : Business Capabilities that support the Vision of a WebSale Company. At the bottom part of the figure, some of candidate business objects and relationships that support these capabilities are presented.

 

 

 

STEP 2 - IDENTIFY GOAL-DRIVEN SERVICE STRUCTURES AND USE CASES TO DELIVER EXPECTED SERVICE LEVELS

 

In this second step, let's look first at the business process descriptions needed to deliver business capabilities.

 

The figure below illustrates a draft business process that describe actions of the Visitor [Registration] business capability.

 

 

 

Figure 2 : A Business Process describes actions that realize a business capability but cannot be of help to make an impact analysis in face of changes imposed to this business capability

 

As we can see on the above process description, it is not easy to accurately understand impacts of potential evolution of high-level business goals (vision, strategies, tactics, ...) on the actions of the business process. For instance, if the tactical constraint shifts to 100 registrants / week due to such an evolution of the upper goals, one cannot determine easily parts of the Visitor [Registration] business capability that should be aligned to achieve this goal.

 

 

In order to deliver the value of a business capability, make it exchangeable with its expected service levels and align it easily to evolutions of high-level goals, a business capability need to be managed by a "goal-driven business service" that acts as a driver to orchestrate realization of requirements assigned to this capability with expected service levels.

 

 

Figure 3 : A Goal-Driven Business Service (GDBS) is constituted within a business capability to manage requirements that are assigned to this capability

 

 

 

CAPITALIZING ON THE BUSINESS KNOWLEDGE USING GOAL- DRIVEN BUSINESS SERVICES (GDBS)

 

A goal-driven business service (GDBS) is a technology independent function at the entreprise level to support evolutions requested from a business capability with its expected service levels.

 

In order to better react to changes by capitalizing on the business knowledge, business capabilities offer for each expected business service level a separately identifiable component that is called a service point (according to the OMG's standard SoaML). So each service point is assigned by the corresponding set of cohesive requirements and controled by the GDBS.

 

For instance, in the case of the WebSale system, requirements about enter visitor,  fill questionnaire, notify visitor , etc… are assigned to service points encapsulated by the visitor registration business capability. Behaviours of these service points are controled by their GDBS Visitor [Registration].

 

 

 

Figure 4 : A Goal-Driven Business Service (GDBS) orchestrates its service points to realize the corresponding business capability

 

 

Notice : Representing service structures encapsulated by business capabilities makes easier to understand how to reconfigure these structures to attain business results imposed by changings goals (vision, strategies, tactics).

 

 

 

DISCOVERYING USE CASES ON THE BASIS OF SERVICES THAT NEED INTERACTIONS WITH ACTORS

 

Services encapsulated by business capabilities may require participation of resources (actors, use cases, workers, entities, ...) in order to be realized.

 

As goal-driven services (GDBS) and their service points support actions necessary to deliver the value of a business capability, use cases focus only on actor / system interactions that are necessary to invoke such actions.

 

The figure below shows use cases that invoke services in order to ensure their realization.

 

 

Figure 5 : Use cases are discovered on the basis of Services that need interactions with actors

 

 

 

 

STEP 3 - DISCOVER RESPONSIBILITIES OF THE GOAL-DRIVEN SERVICES : A ONE -TO- ONE TRACEABILITY TOWARD THE SOFTWARE IN ORDER TO EASILY ADAPT SERVICES TO CHANGES

 

In order to easily adapt service specifications to changes, a one-to-one traceability relationship is required between their functional and object-oriented representations.

 

The figure below shows functional and object-oriented representations of a business service respectively at the CIM (Computation Independent Model) and the PIM (Platform Independent Model) level of the Model Driven Architecture (MDA).

 

At the PIM level, a business service is described using a Goal-Oriented Object (GOO) and its properties (attributes, operations, etc...).

Transformations required to bridge CIM to PIM level business services are given by the Pattern for Executable Service Specification (cf. PEXS)

 

 

 

Figure 6 : Description of a goal-driven service respectively at the MDA's CIM and PIM levels (using UML's Class-in-state notation)

 

 

 

Conclusion : This pattern aims at finding out services and use cases of a system according to the business goals. It also confers to goal-driven services identified this way a 1-to-1 traceability between their functional and object-oriented representations in order to adapt them swiftly to changes.

 

Relationships : The pattern PISS is a basic pattern for the Goal-Driven SOA. Its solutions are used by the patterns PESS (Pattern for Evolvable Service Specification) and PEXS (Pattern for Executable Service Specification) that aim respectively at adapting services to interfaces offered by other services / legacy system components and early testing services independently of solutions (means) and technologic platforms.

 

Figure 7 : Relationships between the pattern PISS and other basic patterns in the Goal-Driven SOA Framework. Pattern descriptions are accessible by clicking on the referenced pattern icon.