Notice : This article is being updated according to relationships described in the "Goal-Driven SOA" Process

 

 

 

by Birol Berkem  - GooBiz (Paris / France)

 

Abstract 

 

The BMM - SOA bridge is intended to offer to business and IT managers a framework to increase their competitiveness by synchronizing their IT systems with evolutions of their organizational goals and directives.

 

In this perspective, this presentation provides a brief insight on how to link your business vision, goals, strategies, tactics as well as business rules according to BMM (1), then bridging the resulting business specifications toward components of the Service Oriented Architecture (SOA) in order to align IT according to your goals and directives.

 

(1) The Business Motivation Model [BMM] - Business Governance in a Volatile World first voted by the OMG in September 2005.

 

 

1         Introduction : wHY SOA SERVICES NEED TO BE BASED ON THE bmm ?

 

Since the last few years, most of the emerging SOA approaches try to determine SOA services on the basis of business processes being totally disconnected from business goals and rules.

 

In these approaches, interactions between service components and internal behaviors of these components are not described according to strategies, tactics and rules fixed at the business layer of the organizations. As a consequence, the resulting system suffers from agility issues in aligning service descriptions to changing decisions. 

In order to react swiftly and coherently to changes, the agile SOA architecture must integrate the core elements of the BMM as also suggested in the OMG's SoaML [SoaML] standard by providing a capability to capture how services must realize business motivations (vision, goals, objectives, missions, strategies, tactics, policies, regulations, etc...).

 

Thus, to ensure a good level of IT governance on the basis of changing business decisions, the SOA development process should support at least the following traceability relationships :

 

• IT services to achieve business processes,
• Requirements that compose these services to the business rules,
• Governance of these services to tactics that implement business strategies,
• Use cases to responsibilities assigned to the participants of the business processes.

 

Such a synchronization of the SOA system by the business motivations requires the following abstraction layers :

• The WHY : to reconfigure business processes and responsibilities of their participants according to changes captured at the business layer (changes on the means (tactics) or directives (rules) that support desired results),

• The FUNCTIONAL WHAT and HOW : to determine impacts of the business decisions on the IT level system components (services that are derived from processes, use cases and entity objects) as well as on system requirements that implement business rules,

• The TECHNICAL HOW : to describe realization of these specifications at the application level in the architecture (from the presentation layer to the entity layer),

• The WHERE : to describe location of these components starting by their high-level descriptions like agencies, headquarters, front and back offices, etc.. .until physical nodes of the architecture where they should be deployed.

 

 

We only focus below on the bridge from BMM to IT level specifications from the point of view of the business owners, analysts and designers. This corresponds to the CIM (Computation Independent Model) level specifications in the OMG's MDA (Model Driven Architecture).

 

The Business Motivation Model (BMM) referenced in the figure 1 below shows a brief insight on relationships between elements of the business layer.

 

Its core elements that are considered as primary for bridging BMM to SOA are indicated using dashed circles. As shown in the figure, business goals as part of the ends drive courses of actions (strategy and tactic), directives (rules and policies) till business processes.

 

 

                                                                                                                                                                    

Figure 1 :   The Business Motivation Model  for the Business Governance in a Volatile World [BMM] of the Business Rules Group  voted by the OMG in September 2005

 

The Business Motivation Model addresses especially the business Owner's perspective (i.e., row two) of the sixth aspect (i.e., the Motivation or 'Why' column) of the Enterprise Framework of Zachman [BMM 2007].

 

 

2         LINKS FROM THE BUSINESS MOTIVATION MODEL to soa

 

In order to bridge business decisions toward IT system behaviors, the SOA framework illustrated below focuses on the IT alignment of the Functional and Application layers according to the Business Motivation (the "Why") Layer concepts and their relationships rather than using traditional IT urbanization concepts such as zones, districts and blocks.

 

Inside the Business Motivation Layer (the "Why"), the main focused elements are the Goal (END), Strategy, Tactic (MEANS), Business Rule ( DIRECTIVE), Business Processes and Resources.

 

The Functional Service Definition Layer (the "What") focuses on discoverying services of the system and use cases that are candidate to invoke them as well as resources that are to be handled by services at this abstraction level.

 

The Functional Service Description and Realization level (the "Functional How") is about detailed specifications of services and use cases. Then it focuses on actions that realize behaviors of these components from the User Interface toward Entity Objects.

 

The Application Layer (the "Technical How") focuses on the technical specifications of services and use cases to describe the Goal-Driven SOA backbone. Then it focuses on the plug-in of the technical components that realize behaviors of functional components from the User Interface toward Entities.

 

Finally, the Deployment Layer ("the Where") describes locations to deploy technical components.

 

Along this refinement process, requirements that are discovered on the basis of the Business Motivation Layer are used and enriched by the Functional (Service Definition) and Application (Realization) layers.

 

The schema below shows an overview on the main elements of these abstraction levels. Details about top down traceability relationships between these levels are presented next.

 

Figure 2 : Overview on the main elements of the abstraction levels to bridge BMM to SOA

 

In the next paragraph, we introduce traceability relationships between elements of these abstraction layers. To better help to understand the meaning of each element, we show them by giving examples in post-its attached to each of these elements.

 

 

      2.1 relationships INSIDE the BUSINESS MOTIVATION LAYER - (The "why")

 

Inside this layer, we focus on the main elements of the core BMM that permit to describe business processes guided by goals, rules and tactics.

 

On the basis of a business vision that is "To be a profitable customer focused websale company", the main goal of the business is given as "To build a Beneficial WebSite System". A strategy that channel efforts toward that goal is set to "Turning visitors into Buyers".

 

Two first tactics are discovered in order to implement this strategy. These are indicated by G3- Motivate internet visitors to Register using a Bonus System" and G2 - Encourage Sales Employees to turn Visitors into Buyers".

 

At the bottom part of the model, directives (policies or business rules) support achievement of business goals.

 

A business rule is a statement that defines or constrains some aspects of the business [Business Rules]. In the context of the Business Motivation Layer, business rules provide the tactical detail about how exactly a strategy will translate to actions then guide business processes shown at the right.

 

A policy is composed of directive elements, each of them can be an underlying policy or a business rule. In the example below, the policy "Marketing Staff to keep Visitors on the WebSite ..." aggregates two essential business rules BR1 and BR2 that respectively ask to Incite Visitors to Register during their product consultation on the website (BR1) and motivate them to complete their registration process (BR2).

 

Finally, in order to realize tactics being guided by the business rules, business processes are appropriately designed. During its achievement, a process (the source) needs to communicate with other processes (targets) and may assign responsibilities to some of its participants (internal or external actors). For instance, along the registration process, if the abandon rate is over than 30%, the marketing staff should be "assigned the responsibility" to review the questionnaire according to the business rule BR2.a.

 

 

Figure 3 : Elements of the Business Motivation Layer and their relationships to govern the bridge toward the SOA service definition layer

 

 

Goal-Driven Process Modeling to Capitalize on the Business Knowledge

 

In order to capitalize on the business knowledge using enterprise business objects, activities and responsibilities assigned to participants of business processes need to be expressed using goals applied to objects.

 

Such a goal-driven and object oriented modeling help us to :

 

• realize a goal-based impact analysis in face of changes,

• coherently align underlying activities of business processes according to tactical changes,

• easily replace process activities by new ones like building blocks.

 

The figure below shows a high-level description of the Web Sale Process where goals and responsibilities assigned respectively to enterprise business objects and participants are encapsulated using objects-in-states.

 

Thanks to this goal-driven object oriented representation -like Product [Consultation], Visitor [Registration] in the figure, activities of existing business processes can be easily extended by new ones with respect to their preconditions and postconditions.

 

For instance, as illustrated at the bottom side of the diagram, the Register Visitor activity of the process is extended by a new activity where "Motivate Visitor to Complete his Registration" constraint is applied.

 

Figure 4 : A high-level description of the Web Sale Process with responsibilities assigned to its participants. Partitioning process activities using states of the Enterprise Business Objects allows us to capitalize on the business knowledge and align underlying activities according to new tactical constraints applied to these objects

 

 

 

 

 

2.2 LINKS TO THE FUNCTIONAL LAYER (FROM "WHY" to "whAT") TO DEFINE SERVICES -

 

In order to orchestrate elements of the functional system layer -such as services, use cases and entities, core business elements identified at the Business Motivation Layer are respectively traced to drive goal-driven services (see figure below) and identify functional requirements that compose them according to business rules.

 

A goal-driven service (GdS) is a mutualized function based on a business capability - activity of the organization that is executed by a business process and is formalized using a business object state like Product [Management], Visitor [Registration], etc. Each GdS supports realization of business process actions related to its object state.

 

For instance, Visitor [Registration] supports achievement of the business process actions about Register Visitor (illustrated in figure 4). It is composed of a set of requirements R3.2.1, R3.2.2, R3.2.3 that implement the business rules BR2 and BR2.a about Motivating Visitors to complete their registration process.

 

Use Cases are identified there according to responsibilities assigned to the participants of business processes. For instance, in figure 4, on the basis of the [registration] responsibility assigned to the Visitor, we can identify the use case Register Visitor that realizes this responsibility in collaboration with the related actor.

 

 

 

Figure 5 : Links between the Business Motivation Layer (the WHY) and the Service Definition / Usage Layer (the WHAT)

 

 

In addition, Goal-Driven Services may need contribution of use cases in order to be realized and permit to guide main steps in the description of use cases (cf. figure 8 below). They also help to discover entity objects they have to handle on the basis of requirements that compose them.

 

For example in order to be realized, the service G3.2- Register Visitor needs to be invoked by the use case Register Visitor and help us to discover entity objects Visitor, Marketing, Sales,... on the basis of requirements that are part of this service.

 

The diagram below shows traceability between actions of a business process and goal-driven services that achieve each of these actions using their service / request point « SRV-P » defined by the OMG's SoaML. .

 

 

Figure 5' : An hierarchical view from process activities toward goal-driven services, use cases and entities

 

 

 

2.3 LINKs TO the SERVICE description AND REALIZATION LAYER - (FROM THE "WHAT" TO "HOW")

 

The main role of the service description and realization layer is to give a description of appropriate goal-driven services and use cases identified at the previous layer then explain what means to use to realize them.

 

Tactic-Driven Business Capabilities, Services and Use Cases that are determined at the Service Definition Layer (The What) are traced and described at the Service Description Layer (the how) respectively by corresponding descriptions.

 

A goal-driven service description is a process that can be materialised by an activity (a composite structure) or an action. An activity contains underlying activities or actions. For example, the service Register Visitor discovered at the previous layer may be described at this layer using actions Enter Visitor, Fill Questionnaire and Notify Visitor...

Same things apply for a use case description...

 

Figure 6 : Links from Service Definition / Usage Layer (the WHAT) to Service Description and Realization Layer (the HOW)

 

 

 

 

2.4 relationships INSIDE THE SERVICE DESCRIPTION AND REALIZATION LAYER (HOW TO HOW)

 

The purpose of the realization sub-layer is to describe how to achieve service actions and use case actions of the Service Description Layer using components of a logical IT architecture ( Presentation, Application, Business Service and Domain Object Layers).

 

Actions of the service description layer are described there using collaborations between these components that orchestrate their underlying actions.

 

For instance, the service action Enter Visitor may be realized by a collaboration between actions of couples of use case and service components as shown below.

 

 

Figure 7 : Relationships inside the Service Description and Realization Layer (the Functional HOW)

 

 

An example to collaborations between components of the Service Realization Layer is given by the activity diagram below.

 

The example is about the implementation of the action “Enter Visitor” that is described at the Service Description Layer.

 

From left to right, screens and actions of the Actor Interface Component (GUI Presentation) interact with actions of the Use Case Components (UC-Comp) and Goal-Driven Service Component (SRV-Comp) actions to "Enter Visitor".

 

Use Case actions operate on graphical user interfaces (GUI) whereas Service actions operate on entity objects, most of the time by changing their states.

 

Figure 8 :  Interactions defined at the Functional Service Realization Layer between GUI, Use Case and Service components to Enter Visitor

 

 

2.5 FROM THE functional TO THE APPLICATION LAYER (FROM THE "FUNCTIONAL HOW" TO "TECHNICAL HOW" )

 

Application layer components that realize functional specifications described in the service description layer constitute the Goal-Driven Service Oriented Architecture of the system.

 

Once completed, use case and service components that are described in the last step (cf. figure 8) are plugged into their respective parent components within this architecture backbone as indicated in the figure 9 below.

 

 

Figure 9 : At the application layer (the Technical How), use case and service components are plugged into their respective parent components within the goal-driven architectural backbone of the system

 

 

2.6 FROM APPLICATION REALIZATION TO DEPLOYMENT (FROM THE TECHNICAL "HOW" TO "WHERE")

 

Components that are described in the previous layer are affected to organisational locations. For instance, components related to the presentation and use case layers may be assigned to agencies in front and back-offices whereas service components and entities may be hosted in the headquarter area.

 

Logical and Physical nodes of the architecture where components should be deployed are respectively determined in respect to the PIM and PSM viewpoints of the OMG's MDA.

 

 

 

3 CONCLUSION

 

The BMM - SOA bridge is intended to offer to business and IT managers a framework to increase their business competitiveness by synchronizing their IT systems with evolutions of their business goals and directives.

 

This requires from Service Oriented Architectures to be structured according to business motivations (vision, goals, objectives, strategies, tactics, rules and processes).

 

In this perspective, the layered architecture of the "Goal-Driven SOA" Process permits to identify traceability relationships that permit to connect such high level business goals and directives toward elements of the software level specifications.

 

Patterns for technical level transformations of these business motivations toward software implementations are available on http://www.goobiz.com

 

   

4 REFERENCES

 

[BMM 2007] : The Business Motivation Model - September 2007

[Business Rule ] : Defining Business Rules

[Running Business on your Goals and Directives] http://www.goobiz.com/RunningBusinessOnTheGoals.htm

[SoaML] : http://www.omg.org/docs/ad/08-08-04.pdf

 

 

 

 

This work by Birol Berkem (GooBiz.com) is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Permissions beyond the scope of this license may be available by mail to info@goobiz.com

Birol Berkem (Ph.D), GooBiz