Notice : This article has been recently updated according to relationships described between BMM and SOA standards (Ref.Article "From BMM to SOA")

 

 

by Birol Berkem - Goobiz (Paris / France)

 

Abstract 

In the previous articles that we wrote in the last years, we presented the 'Goal-Driven Development Process' and its patterns that aim at increasing the business reactivity of the companies in face of changes. In this article, you will find steps of this methodology in their industrialised aspect that are conducted this time till the software implementation level and according to BMM (1).

As you know, use case driven and object-oriented development processes are widely used by organizations for building their IT systems. This practice allows stakeholders  to concentrate their requirement management efforts as well as analysis and design efforts on the usage choices of the systems.

However, IT systems developed only with use-case driven and object-oriented development methods do not provide their organizations with good levels of reactivity in face of changes. This is because these systems are structured depending on the intentions of their end-users in using the system (use cases) and on the basis of its domain objects rather than being structured according to business goals (2) and underlying rule (3) based requirements that support achievement of these goals.

As a result, such systems are unable to capture changes on the business needs (such as tactics and business rules) and propagate them coherently toward IT applications in order to allow their organization to capitalize on its business knowledge as well as helping end-users to invoke changing business behaviours according to their changing responsibilities.

In order to illustrate how to develop IT applications on the basis of business goals then aligning these applications to changing business requirements on a Goal-Driven Service Oriented Architecture (GD-SOA) (4), we present below steps of the Goal-Driven Development Process on a case study using the Enterprise Architect (EA), a UML 2 compliant case tool that also allows traceability with the requirements that are entered using the same tool.

 

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

 

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

 

(3) Rules : A business rule is a statement that defines or constrains some aspects of the business [BMM]. In [Business Rules vs. Business Requirements], a rule 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) GD-SOA : A Service Oriented Architecture where services of the IT system correspond to a business process or to a function that can be mutualised between business processes. A goal-driven service is composed of cohesive set of requirements and requires participation of resources (actors, use cases, workers, entities, ...) in order to be realised.

 

 

 

1         Introduction : wHY USE CASES ARE UNABLE TO ALIGN IT TO CHANGES ?

 

For the last few years, organizations have tried to develop their software systems with use case driven and object-oriented development processes. This practice does not allow them to react to changes swiftly and coherently for three main reasons.

 

In use case driven development :

 

• business owners are unable to evolve their business processes independently of user interactions as business rules are mixed within 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 cannot be handled directly due to the 1 to N traceability issue between functional specifications and their business entity based object oriented representations.

 

 

Such a lack of direct visibility of the rules and lack of traceability till their software implementations are an important obstacle 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 organizations to increase their business agility, a Goal-Driven Development Process becomes necessary. Such a case tool-assisted approach must help stakeholders to model business goals of their organization, their underlying courses of action as well as rules that have to support these goals until discoverying and implementing SOA services as well as use cases of the end-users according to changes.

.

The Business Motivation Model Diagram [BMM] referenced in the figure 1 below shows such relationships. Its basic elements that are considered as primary by the Goal-Driven Development Process [Goobiz] are indicated using dashed circles. As shown in the figure, business goals as part of the ends drive courses of actions, directives (rules and policies) till business processes.

 

Examples from Goals toward Business Rules for a WebSale System are given at the right of the figure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

 

According to these elements of the Business Motivation Model and their relationships (indicated using dashed circles from right to left), the Goal-Driven Service Oriented Development Process aims at allowing stakeholders to :

       

•      establish a bridge between the business and IT components that have to carry out implementations of strategies and tactics as well as rules and policies that guide realisation of their business processes,

•       trace impacts of the changes captured on requirements till their software implementation level in order to improve agility of their organizations to react to changes.   

 

In this perspective, the next section shows steps of the Goal-Driven Development Process from requirements captured on the basis of business goals through their software implementation. These steps are explained using a case study where one of the business goal and strategy of the organization is fixed respectively to be "a beneficial websale system" by "turning its internet visitors into buyers".

 

 

2         Steps of the "GOAL-DRIVEN SOA DEVELOPMENT" process

The Goal-Driven SOA Development Process using UML is constituted of six main steps. An insight of these generic steps is presented below.

 

 

Figure 2 :   Steps of the  Goal-Driven SOA Development Process on the basis of  BMM and MDA style transformations

 

 

 

The roles of these steps are as follow :

 

• Step 1 focuses on the description of 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 owners 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.

 

The examples given below show an application of these steps using the Enterprise Architect (EA) UML tool.

 

 

Step 1   Describing tactics and business processes on the basis of business goals

 

In this first step, we write business goals and strategies as well as underlying tactics that support these goals.

 

The figure 3.1 below illustrates these hierarchies as well as business processes and underlying requirements assigned to these processes.

 

 

 

Figure 3.1 :   List of Business Goals, Strategies and underlying Tactics until Business Processes and Requirements

 

 

 

 

The figure 3.2 below illustrates dependencies between these items from the business goal "Beneficial WebSale System " until strategies and underlying tactics (G1,G3, G4) that control processes.

 

Items that are labeled G1, G3 and G4 correspond to tactics that implement the strategy "Turn Visitors into buyers" .

 

At the right of the figure, the project browser shows underlying requirements for these items.

 

 

 

 

 

Figure 3.2 :  Dependencies between Business Goals, Strategies and underlying Tactics until Business Processes controled by tactics

 

On the basis of these specifications, we model at the next step business processes within described tactics then assign responsibilities to their potential participants in order to describe their realisation.

 

 

 

Step 2  Model business processes then discover responsibilities of their participants

 

This step allows us to formalize business processes and business rules to support tactics then discover responsibilities to assign to their participants in order to ensure their realisation.

 

The figure 4 below illustrates a formalized description of a basic business process and extensions assigned to this process in order to support tactical evolutions.

 

In order to better represent causality between process activities, participants of these activities are modeled there in different states where entering in a new state assigns to the participant the responsibility to trigger the appropriate target process .

 

For example, according to a strategic evolution, new behaviours are assigned to Register Visitor activity of the process to motivate visitor to complete its registration. A bonus is systematically assigned at the end of the activity fill questionnaire. Also if the abandon rate is important during this activity, the responsibility of reviewing questionnaire is assigned to the Marketing_Mgr to incite her to trigger the activity Review Questionnaire.

 

Other activities of the web sale process should be extended as well by tactical changes due to strategic evolution.

 

At run time, the process engine starts an instance of the process and goes through its activities, selecting the appropriate tactical behaviours depending on the current configuration of the business process.

 

 

  

Figure 4 : Modeling business processes, rules and responsibilities assigned to actors according to tactical change "Motivate to Complete Registration"

 

 

Step 3   Discover Goal-Driven Services and Use Cases

 

In order to confer coherent evolution and swift adaptation to changing tactics and business rules of the organizations till their IT implementation, business rules captured on the basis of tactics must be rendered visible.

Such a visibility requires a separate identification of the goal-driven services from the usage scenarios of actors (use cases).

 

A goal-driven service is a function at the IT system level that corresponds to a business process or to a functionality 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 specification (figure 4), business processes G3.1 - Consult Products, G3.2 - Register Visitor and G4.1 - Inform Visitors about Promotions... help us to determine three candidate goal-driven services.

Services constitute the essence of use cases as they make sense to actor / system interactions that are necessary to realise related functions. 

 

On the basis of these specifications, use case components are determined in order to allow actors to realise services by invoking their behaviours. In such a separation of the business behaviours from usage choices of the actors, use cases only represent corresponding goals of the actors in using these business services.

 

The figure 5 shows tactics (represented by boundaries) with underlying services based on the previous requirements. Specification of such boundaries as composite structures helps us to easily determine their underlying parts (business services with their supporting business rules that are included inside them) in order to evolve them coherently in respect to potential changes.

 

 

Figure 5 : Representation of Goal-Driven Services and Use Cases partitioned by Tactics that they have to support

 

 

 

 

Step 4   Draft the backbone of the Goal-Driven Service Oriented Architecture

 

This step allows us to elaborate a first draft of the architectural backbone of service and use case components at the PIM level of the MDA. A draft of the Goal-Driven SOA backbone on the basis of the specifications of business owners is given in the figure below according to the UML 2 component diagram notations.

.

In order to keep traceability with business level goal-structures of the system described in the previous figures, service components in the figure below are described within the same "Tactic boundaries" namely G1, G3, G4.

 

 

 

Figure 6:    A draft of the backbone of the Goal-Driven SOA transformed at the PIM on the basis of CIM level specifications of the business owners

 

 

Step 5   Model underlying behaviours of use case and service components for realising actions determined in the previous scenarios

 

In this step, we describe underlying automated actions of the processes that require actor / system interactions for their realisations.

The below activity diagram illustrates a realisation scenario for the action Enter Visitor of the process Register Visitor described in figure 4.

 

 

 

Figure 7 :   Behavioral description of the use case and service components that realise the action Enter Visitor of the business process Register Visitor

 

 

 

 

Step 6  Plug-in the use case and service behaviours into the backbone of the GD-SOA and test

 

This step focuses on the insertion of the appropriate software behaviours into the components of the architecture.

 

In this perspective, behaviours of the other architectural layer components such as the presentation and data storage layers have to be implemented on the basis of the previous specifications.

 

Inside this architecture, the application and business logic are respectively implemented by the use case and service components.

 

Both are implemented by a goal-oriented object (GOO) where the controler operation triggers its contextual operations depending on the state of the object (expressed by its attribute values) and the pre-condition of the contextual operation [Align-IT].

 

The below class diagram shows description of the use case (UC) and goal-driven service (GDS) classes on the basis of the previous specifications that are integrated between the user interface (UI) and entity objects (Data Model) in order to test the action Enter Visitor of the business process Register Visitor.

 

 

 

Figure 8 :   Internal structure of Use Case and Service components to be plugged into the architectural backbone of the system 

 

 

 

Finally, the previous architectural components (GUI, use case, service, entity objects) are plugged into appropriate structures of the architectural backbone of the system for their integration with other components of the architecture.

 

The figure below illustrates the plug-in of the previous UC and GDS components into the system architecture.

 

Figure 9 : Use cases and service components are plugged into their respective parent components within the goal-driven architectural backbone of the system

 

The underlying behaviours of these actions (user interface and entity object handling, etc) that are expressed using specifications (such as conditions, final states for objects) are also transformed into O.O specifications. Such an early transformation permits to prototype specifications of the business owners and to guide designers to complete them by other technical aspects for their unit and integration tests. 

 

The print screen of the figure 10 below shows correspondence between actions specified for the service component Visitor_Entry and their corresponding method bodies in Java code on the right. This is just an initial 'mono user' version of the code that is elaborated for early testing these actions. For a final multi-user version, method declarations have to be setting up as non-static and GOO classes of use case and service of the figure 9 have to be instantiated.

 

Final states such as [created], [validated], [linked to visitor], [sent], etc..  that have to be reached by entity objects are illustrated in order to guide developers about states that must be respected in the related actions. These states are indicated as comment lines in the generated source code for helping developers in implementing corresponding methods.

 

 

Figure 10 : Actions and conditions for the service component Enter_Visitor are transformed to provide comment lines in Java

 

 

Animated : Click to visualize how to deal with changes on the Goal-Driven Service Oriented Architecture, ...

 

 

3         Conclusion

 

The steps of the Goal-Driven SOA Development Process illustrated in this presentation allowed us to explain how to align IT applications on the basis of business goals, their underlying means and processes according to BMM and MDA concepts.

 

By bridging these concepts throughout identification of SOA services and application use cases then ensuring their separate traceability toward software implementation, the purpose of the Goal-Driven SOA process is to allow stakeholders to adapt IT applications to the changes swiftly and coherently using goal structures, thus to capitalize on their business knowledge using a goal-driven service oriented architecture [GDDP4MDA].

 

Goal-Driven Development Patterns [Patterns] that support the infrastructure of this SOA process aim at helping organizations to enhance continuously their process performance in order to increase their business agility without worrying about alignment of IT applications.  This way, business owners focus on the enhancement of their business behaviours by describing more precisely services of their SOA-based systems, whilst end-users of the system can finaly concentrate their efforts on the specification of their interactions with the system as they should do.

 

 

  Detailed information about relationships between BMM toward SOA Services, is provided on "From BMM to SOA".

 

 

References

[BMM] : "Business  Motivation Model - Business governance in a volatile world" of the Business Rules Group voted by the OMG in September 2005 http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf ,

[Visibility of the Rules] :  Stan Hendryx - Business Rules - BPTrends / BPT http://www.businessprocesstrends.com/publicationfiles/10-04%20COL%20OMG%20Montreal%20-%20Hendryx.pdf  , October 2004

[Business Rules vs. Business Requirements] : Gladys S.W. Lam - Business Rules Journal, Vol. 7, No 5, May 2006), URL:  http://www.BRCommunity.com/a2006/b290

[Service Architecture - SOA : Why Sale isn't process driven] : Steve Jones - http://service-architecture.blogspot.com/2007/01/why-sales-isnt-process-driven.html

[Becoming Strategy Driven] : Ronald G. Ross, "Becoming Strategy-Driven:  Moving Beyond the Tired Notion of 'Business Alignment'," Business Rules Journal , Vol. 9, No. 12 (Dec. 2008), URL:   http://www.BRCommunity.com/a2008/b452.html

[GDDP4MDA] Birol Berkem, Goal Driven Development for MDA - OMG's Technical Meeting in Athens http://www.omg.org/cgi-bin/doc?omg/2005-04-05 , April 2005

[Align-IT-with-BMM] Birol Berkem, How to align IT with the Changes using UML and according to BMM ? - Journal of Object Technology, vol. 5, no. 2, March-April 2006 , http://www.jot.fm/issues/issue_2006_03/column9

[Align-IT] Birol Berkem, Aligning IT with the Changes using the Goal-Driven Development for UML and MDA- Journal of Object Technology, vol. 4, no. 5, July-August 2005 http://www.jot.fm/issues/issue_2005_07/column5

[Patterns] How to increase your business agility with UML and MDA? (White paper on the Goal-Driven Development Patterns and Processes) http://www.goobiz.com

 

 

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

Birol Berkem (Ph.D), GooBiz