Birol Berkem  - GooBiz (Paris / France)

 

Abstract 

 

This introduction to the Goal-Driven SOA (1) Development Process gives you a brief insight on how to link your business vision, goals (2), strategies, tactics as well as business rules (3) and processes according to BMM (4), then bridging the resulting business model toward IT components in order to run your business according to your goals and directives.

 

(1) Goal-Driven SOA : A Service Oriented Architecture where services are made of cohesive set of rule based requirements and support realisation of business processes.

 

(2) Business Goal : "A statement about a state or condition of the enterprise to be brought about or sustained through appropriate means" [BMM]. For instance, in the case of a WebSite System, means like Motivate Visitors to Register and Turn visitors into buyers offer their support to the business goal Beneficial WebSite System.

 

(3) Business rule : A business rule is a statement that defines or constrains some aspects of the business [BMM]. In [Business Rules vs. Business Requirements], it is defined as a "Statement that tell you whether you may or may not do something" whilst a business requirement is "what you need to do to enable the implementation of and compliance with a business rule".

 

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

 

 

1         Introduction : wHY USE CASES ARE UNABLE TO BRIDGE IT TO BUSINESS NEEDS ?

 

Since the last few years, organisations try to develop their software systems with use case driven and object-oriented development processes. This practice does not allow them to synchronise their IT with their business goals and rules in order to react to changes swiftly and coherently.

 

Three main reasons are at the basis of the business and IT bridging failure.

 

In use case driven development :

• business experts cannot evolve their business processes independently of interactions of their end-users with the system as business rules are mixed with actor/system interactions inside use cases,

• end-users are unable to use the system according to their changing responsibilities when business goals or their supporting rules evolve, nor to focus accurately on their usage scenarios till detailed definition of their screens as they should do,

• the adaptation process of the software components to the changes on the business requirements is not facilitated due to the 1 to N traceability relationship between their functional and object oriented representations.

 

 

Such a lack of direct visibility of the rules and lack of traceability till their software implementations are important obstacles for aligning IT implementations with the changing company goals and related business rules. As a consequence, important maintenance effort is required in order to adapt IT applications to changes.

 

For the same reasons, emerging SOA approachs that try to determine services on the basis of use cases suffer from the same agility issues. 

 

In order to allow organisations to increase their business agility, first business rules must be captured separately from actor / system interactions that are necessary to realise them. Secondly, both business requirements and usage constraints of the end-users must be separately traced towards their software implementation respectively throughout software services and application use cases.

 

Using this BMM-SOA bridging process, stakeholders can model business goals of their organisation, their underlying means as well as rules that have to support these goals as indicated by the Business Motivation Model (BMM). After then, these business structures are directly bridged to SOA services, in order to adapt IT applications to the changes swiftly and coherently.

 

Thus, the Goal-Driven SOA Development Process (GD-SOA) aims at helping organisations to enhance continuously their business processes in order to increase their business agility without worrying about alignment of their IT applications.  This way, business experts focus on the enhancement of their business behaviours by describing more precisely business processes of their systems at their own business level, whilest end-users of the system can concentrate their efforts on the precise specification of their user interfaces while interacting with the resulting SOA services.

 

As part of the GD-SOA, the Business Motivation Model Diagram (BMM) referenced in the figure 1 below shows useful relationships in order to validate the business plan and running business on the basis of business goals and their underlying structures. Its basic elements that are considered as primary by the GD-SOA process 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

 

 

 

 

2         INSTANTIATING THE BUSINESS MOTIVATION MODEL on a CASE STUDY

 

 

According to the elements of the Business Motivation Model and their relationships (indicated using dashed circles from right to left), the following schema shows for a Profitable WebSale Company vision, a partial instantiation of the relationships from ENDS, throughout MEANS and DIRECTIVE until BUSINESS PROCESSES.

 

On the basis of the vision that is fixed to be "a profitable customer focused web sale company", the business goal and the objective that quantifies the goal are presented as part of the ENDS at the right.

 

MEANS that explain how to attain this goal with the objective are represented by the strategy and tactics. The strategy is fixed to "Turn Visitors into Buyers" while tactics are set to "Motivate Internet Visitors to Register" and "Encourage Sale Employees via a bonus program".Once sufficiently detailed, such a collection of tactics may also be used to form an action plan.

 

The bottom part of the model illustrates DIRECTIVES that govern Strategies and Tactics. For instance, the tactic "Motivate Internet Visitors to Register" is governed by an enforced business rule that obliges the Marketing Staff to "Keep visitors on the website of the company" in respect to the policy "Maximise elapsed time of the visitors on the website".

 

A detailed explanation is linked to the business rule in order to express lower-level rules that might help to keep visitors on the website. Visitors should be motivated to register while consulting promotions offered by the company. Secondly, as part of the registration process, if the abandon rate is over than 30 % while filling their questionnaire, the Marketing should receive an alert to review the questionnaire for enhancement purpose.

 

Finally, these rules are to be used by the business process Register Visitors that realises the tactic given above, that is to "Motivate internet visitors to Register" as part of implementing the strategy "Turn visitors into buyers".

 

The diagram below is elaborated using the BizModeler tool from Xactium.

 

 

Figure 2 :   A Partial Instantiation of the Business Motivation Model for a "Profitable WebSale Company" Vision using the BizModeler BMM Modeling tool from Xactium.

 

On the basis of these elements and their relationships, the figure 3 below shows an hierarchical view and detailed contents for the business goal, strategy and tactics that support this goal, till business rules that guide the business processes.

 

The icons G1, G3 and G4 correspond to tactics that implement the strategy "Turn Visitors into buyers". As a support to the tactic indicated by "G3- Motivate Visitors to Register", the business processes "G3.1 - Consult Products" and "G3.2 - Register visitors" support its realisation. In their turn, each business process contains a cohesive set of requirements like -R3.2.1, R3.2.2, ... until R3.2.a  for the process Register Visitor.

 

The screen copy below illustrates hierarchical traceability relationships that implement the Business Stategy "Turn Visitors into Buyers" toward Rules Based Requirements using the UML modeler Enterprise Architect (EA) from SparxSystems.

 

Figure 3 :  An hierarchical view of the business goal, strategy and tactics until goal-driven business processes that are guided by business rules and rule based requirements that compose these processes

 

By focusing on the business processes and rule based requirements that compose them, we attain the level of services of the goal-driven SOA as well as behaviours of underlying IT components.

A goal-driven service is a function that corresponds to a business process or to a function that can be mutualised between business processes. It is composed of cohesive set of requirements and requires participation of resources (actors, workers, entities, ...) in order to be realised.

For instance, on the basis of the previous figure 3, business processes G3.1 - Consult Products, G3.2 - Register Visitor and G4.1 - Inform Registered Visitors... help us to determine three candidate goal-driven services.

The next section gives a summary on the steps of the Goal-Driven SOA Development Process.

 

3         Steps for running business on the basis of bmm specifications

 

On the basis of the Business Motivation Model specifications and descriptions provided in the previous section, the figure 4 below shows steps of the Goal-Driven Development Process that aim at running business on the basis of goals and directives by instantiating such a chain of Goals, Means, Rules and Processes till their corresponding IT components and software implementation.

.

The Goal-Driven SOA Development Process is constituted of six steps that are summarised below using UML diagrams. .

 

 

 

Figure 4 :   Steps of the  Goal-Driven SOA Development Process on the basis of  BMM

 

 

The role of each step may be summarised as follows :

• Step 1 focuses on describing tactics, business rules and business processes on the basis of business goals.

• Step 2 is interested in modeling business processes and determining responsibilities of their participants in order to realise tactics at the business level.

• Step 3 looks for services of the system that are candidate to support tactics and processes then finding use cases that have to invoke these services.

• Step 4 elaborates a first draft of the Goal-Driven SOA backbone by transforming functional specifications of the business experts related to step 1 into corresponding service-oriented software components.

• Step 5 describes underlying behaviours of the software components toward their implementation code for automated actions of the previous activities.

• Step 6 integrates behaviours of these software components into the Goal-Driven SOA backbone using plug-in and play mechanisms.

 

Click for detailed explanation about the steps of the Goal-Driven Service Oriented Architecture and citation for references...

 

    

 

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License