HOW TO ALIGN IT WITH BUSINESS on a "Goal-Driven Service Oriented Architecture" ?
STEPS OF THE "GOAL-DRIVEN SOA" DEVELOPMENT PROCESS FROM REQUIREMENTS TOWARDS THE SOFTWARE IMPLEMENTATION LEVEL USING THE OMG's SoaML, BMM and MDA STANDARDS with the ENTERPRISE ARCHITECT (EA) from Sparxsystems
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 companies for building their IT systems. This practice allows stakeholders to focus their requirement management as well as their analysis and design efforts on the usage choices of the systems.
However, IT systems developed only with use-case driven and object-oriented methodologies 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) rather than being structured according to business goals (2) and underlying rule (3) based requirements that support achievement of goals.
As a result, such systems are unable to capture changes on the business needs and propagate them coherently toward IT applications in order to allow organization to capitalize on its business knowledge nor to help 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 them to changing business requirements on a Goal-Driven Service Oriented Architecture (GD-SOA) (4), we present below the 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
(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" support the business goal "Beneficial Websale System".
(3) Business Rule : A statement that defines or constrains some aspects of the business [BMM]. A rule is 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 implementation of and compliance with a business rule" [Business Rules vs. Business Requirements].
(4) GD-SOA : A Service Oriented Architecture that is essentially centered on the alignment of the IT system components to changing business decisions.
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 goals and rules also their lack of traceability till the software implementations become 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 do not help companies to resolve these 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 is constituted of six main steps. A snapshot of these generic steps is illustrated 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 basis of business goals to describe changes on strategies, tactics, business rules and processes
- Step 2 models business processes and identifies responsibilities that should be assigned to their participants in order to realize tactical changes at the business level.
- Step 3 looks for goal-driven services of the IT system that are candidates to support tactics and processes then identifies use cases that have to invoke these services.
- Step 4 elaborates a first draft of the Goal-Driven SOA backbone, 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 business processes.
- Step 6 integrates behaviours of these software components into the Goal-Driven SOA backbone using a plug-in and play mechanism.
The examples given below show an application of these steps using the Enterprise Architect (EA) UML tool.
Step 1 : Describe 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 from goals toward business processes and underlying requirements assigned to these processes.
Items that are labeled G1, G3 and G4 correspond to tactics that implement the strategy "Turn Visitors into buyers".
Figure 3.1 : List of Business Goals, Strategies and underlying Tactics until Business Processes and Requirements
The figure 3.2 below illustrates graphically dependencies from the business goal "Beneficial WebSale System" until strategies and underlying tactics (G1,G3, G4) that control business processes.
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
As these stategic items (goals, strategies, tactics) evolve frequently in time, it is difficult to capitalize on the business capabilities - what the organization does to determine business processes that explain how to execute these business capabilities.
CAPITALIZING ON THE BUSINESS OBJECTS AND CAPABILITIES
To capitalize on the business knowledge, we look for business invariants like business objects and capabilities based on the company vision, then track impacts of changing strategies and tactics on these more stable elements in face of changes.
The figure below shows a business vision for a "WebSale company" that is supported by business capabilities, which in turn, are supported by enterprise business objects.
Figure 3.3 : From the Company Vision to Business Capabilities and Business Objects
On the basis of these specifications, we model, in the next step, business processes within described tactics then assign responsibilities to potential participants in order to describe their realization according to KPIs.
Step 2 : Model business processes then discover responsibilities of their participants
This step allows us to formalize business processes to support tactical changes on business capabilities then discover responsibilities to assign to participants of these process in order to ensure their realization.
To better capitalize and react to changes, process descriptions are encapsulated using business capabilities.
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.
Indeed, according to a tactical evolution about "Motivating Visitor to Complete its Registration", new behaviours such a systematic bonus attribution, notification and conditional questionnaire review activities are assigned to the Register Visitor activity of the process.
At the run time, the process execution 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 process evolutions 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).
We identify a goal-driven service (GdS) as a mutualized function based on a business capability formalized using a business object state.
A GdS supports realization of all business process actions related to this object state through its service/request points « SRV-P ».
To do this, a goal-driven service defines one service / request point « SRV-P » for each automated process action and achieves the end-to-end traceability from this action to its IT realization.
For instance, on the basis of the business capabilities such as Product Consultation, Visitor Registration and Turn Visitor into Buyer that are respectively realized by the corresponding business processes, we can identify candidate goal-driven services shown at the figure 5.
A Goal-Driven Service requires through its service / requests points « SRV-P » participation of resources (use cases, actors, entities, …) to realize process actions.
Thus Goal-Driven Services give sense to use cases as they require actor / system interactions that are necessary to realize related functions.
On the basis of these specifications, use case components are identified to allow actors to realize 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 goal-driven services based on the previous requirements. Each goal-driven service defines a service / request point « SRV-P » for each process action and achieves an end-to-end traceability from this process action to its IT realization.
Figure 5 : Representation of Goal-Driven Services and Use Cases on the basis of business capabilities and their process actions
The figure 5' below shows detailed description of goal-driven service points and use cases components. After transformation into Goal-Oriented Objects (GOO) components, these descriptions will be plugged into the architecture backbone of the 'Goal-Driven SOA" framework (cf. figures 7 and 8 next).
Figure 5' : Representation of detailed interaction between a Goal-Driven Service Point Visitor [Entry] and its related Use Case Component Enter Visitor
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 capabilities and tactical constraints imposed to these capabilities, service components in the figure below are described within these "Capability boundaries" namely C1, C3, C4.
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
In this step, we describe underlying automated actions of the processes that require actor / system interactions for their realizations.
The below activity diagram illustrates a realization scenario for the action Enter Visitor of the process Register Visitor described in figure 4.
The UC and GdS component behaviours shown at the bottom side may be automatically generated on the basis of actions specified within each of them.
Figure 7 : Behavioral description and generation of the use case (UC_Cmp) and service (GdS_Cmp) components that realize 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.
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 8 : Use Case and Service components are plugged into their respective parent components within the goal-driven architectural backbone of the system
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 to help organizations to increase their business agility without worrying about alignment issues of IT applications.
This way, business owners focus on the enhancement of their daily business process behaviours, describing precisely underlying behaviours of supporting services and UC components, whilst end-users of the system can finaly concentrate their efforts on their interactions with the system as they should naturally 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
[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 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