GooBiz

Identity : Identifiable Service Specifications

Intent : Helps to identify required service structures and expected service levels to support target capability components of an architecture on the basis of changing goals (vision, strategies, tactics) and ensures a one-to-one traceability with their functional specifications in order to adapt them rapidly in face of changes.

 

 

 

According to TOGAF MetaModel and definitions, business functions are designed to "deliver" business capabilities and each business function is bounded by a business service that provides a governed interface to access that business function.

In other terms, in order to be realized, capability components need to be supported by a set of underlying services that have to collaborate to deliver the business value required from a capability and in respect to service levels expected from their functions.

 

 

Solution for Service Identification and Specification : The following steps are necessary to identify and describe service structures to support target capabilities of an architecture and capitalize on them in face of changing goals :

 

 

Step 1 - Make identifiable service structures to deliver values expected from capabilities.

 

Step 2 - Specify behaviours of these service structures using processes in order to understand : how to deliver effectively for each capability the expected business value

 

Step 3 - Transform the process into the corresponding Service Structure

 

 

Detailed Explanation

 

 

STEP 1 - MAKE IDENTIFIABLE SERVICE STRUCTURES TO DELIVER VALUES EXPECTED FROM CAPABILITIES

 

In order to capitalize on capability components by reusing corresponding services that support them, we name these services using objects and their relevant states indicated in brackets. The object state constitutes a functional boundary to capture related requirements also to host operations of the related business process that describes realization of the capability component.

 

For instance, in the previous figure, the CRM System Capability which is assigned by new strategies such as Turn Visitor into Buyer will be enriched by appropriate sub-capability components like Manage Visitor Registration, Targeted Mailing System, etc...

 

As part of the Manage Visitor Registration Capability, a composite service Visitor [Registration] will emerge to capture and manage requirements that are assigned to this capability using its functional boundary represented here by the Registration state.

 

It also plays a role of manager to receive new constraints from high-level goals that may be impacting its functional boundaries concretized by its object state and to realize impacts of these changes. For this reason we call such a composite service a "Goal-Driven Business Service (GDBS)".

 

The figure below shows requirements that can be captured by the functional boundaries of the "Goal-Driven Business Service (GDBS)".

 

 

Figure 1 : A Goal-Driven Business Service (GDBS) emerges as part of a business capability to capture and manage requirements that are assigned to this capability by filtering them via its functional boundaries symbolized by its state

 

 

STEP 2 - SPECIFY BEHAVIOURS OF THESE SERVICE STRUCTURES USING PROCESSES

 

Requirements that are captured using the Goal-Driven Service of a capability component may be realized by a process that decomposes and orchestrates a possible realization of this capability.

 

The figure below shows the GDBS Visitor [Registration] with constraints imposed on it and also illustrates an outlined description of the corresponding business process.

 

 

 

Figure 2 : A Business Process describes actions that realize a business capability

 

Despite such an identifiable service structure description, as we can see on the above value-stream or process description, it is not easy to accurately assess impacts of potential evolution of high-level business goals (vision, strategies, tactics, ...) on the actions of the business process in order to capitalize on them. For instance, if the tactical constraint imposes to such a capability component a shift from 50 registrants to 100 or 200 registrants per week due to an evolution of the upper goals, it is not easy to determine parts of the Visitor [Registration] service component that might be aligned to achieve this goal and reuse them.

 

As a consequence, in order to align capability components to evolutions in an organization, we may also need to make their sub-capability components identifiable.

 

In such a context, the pattern PESS (Evolvable Service Specifications) permits to focus on necessary functions to deliver them according to their expected service levels. It assigns a "goal-driven service" that acts as a controler to orchestrate the underlying functions of the capability component to deliver its value.

 

 

 

STEP 3 - TRANSFORM THE PROCESS INTO THE CORRESPONDING SERVICE STRUCTURE

 

In order to prepare delivery test of the expected values of a capability and adapt them to changes, we transform functional description of processes that realize requirements assigned to its orchestrator into service-oriented representations using a one-to-one traceability relationship.

 

The figure below shows both functional and service-oriented representations of a capability component respectively at the CIM (Computation Independent Model) and PIM (Platform Independent Model) levels of the OMG's Model Driven Architecture (MDA).

 

At the PIM level, every service of the capability component can be described using an Object-in-State and appropriate properties (attributes, operations, constraints, etc...).

Transformation principles required to bridge CIM to PIM level specifications of business services are provided by the Pattern for Executable Service Specification (cf. PEXS)

 

 

 

Figure 3 : Description of a goal-driven service respectively at the MDA's CIM and PIM levels (using UML's Class-in-state notation). Such a service representation of a business function may be easily adapted to changes for example using an inheritance relationship. - cf. figure 2 in Pattern for Using Business Services from the Application Layer (PUBS-BAL).

 

 

 

Strenghts of the pattern PISS : This pattern aims at finding out service structures of a system according to its goals and capabilities to deliver expected values. It also confers to services identified this way a 1-to-1 traceability with their functional specifications in order to adapt them swiftly in face of changes.

 

Relationships : PISS is a basic pattern to design target capabilities of an architecture using service structures in face of changing goals. Its solutions are used by the patterns PESS (Pattern for Evolvable Service Specification) and PEXS (Pattern for Executable Service Specification) that aim respectively at making services evolve & adapting them to interfaces offered by other services / legacy system components and early testing services independently of solutions (means) and technologic platforms.

 

The figure below shows other foundational patterns that are linked to PISS to support realization of target capabilities in face of changes. This set of patterns aims at building up a a proactive business architecture on the basis of a Goal and Capability Driven SOA Development Framework.

 

Figure 4 : Relationships between the pattern PISS and other foundational patterns as part of the Goal-Driven Development Framework. Individual pattern descriptions are accessibles by clicking on the referenced pattern icon.