Propagating changes toward IT applications and capitalising on the business knowledge...

 

 

Thanks to its goal-driven and component based architecture backbone that allows traceability of the requirements captured on the basis of goals, the Goal-Driven SOA Development Process aims at helping its users in capitalising on their business knowledge while propagating changes till the software implementation level.

 

Changes captured on the business rules and policies using the goal-driven development framework are propagated till their lower-level courses of actions that, in turn, are realised by underlying use case and service components.  

 

For instance, let's consider the following changes related to the business goal and the business objective for the version V2 of the system :

 

 

      Changes on the Business Goal : « Motivate visitors to register using a bonus and lotery systems » …

      New Business Objective : 100 registrants / week.

 

 

Courses of actions and rules that support these goals are given using the requirements below :

 

 

 

(V2) G3 - Motivate Visitors to Register via a Bonus System

	R3.2.3 - Assign bonus to the visitor for future sale transactions
	R3.2.3.a - if bonus_rate > 30 % then review bonus assignment
	R3.2.4 - Add the visitor to the lottery system
	R3.2.4.a - If visitor already exists in the lottery system : inform visitor that he is already registered in the lottery system
	R3.2.4.b - If lottery material in stocks < threshold then purchase lotery material

Screen 1 - Changes on requirements

 

 

 

How could behaviours of the system be adapted swiftly and coherently to these changes ?

 

Changes have to be specified using a top-down hierarchy using at least three essential levels :

 

• changes that should be captured on the business goals of the system and their underlying units,

• impacts of these changes on the courses of actions and business rules that have to support these goals till business processes that are able to realise these actions,

• finally, adaptation of the software architectural backbone of the system to these changes.

 

 

The Screens 2 and 3 illustrated below progressively show such impacts of changes on the business rules illustrated on the previous models starting by its high-level components (realisation of the business goals and their underlying services) toward its lower-level components (actions, responsibilities assigned to participants, use cases and service components, interfaces, entities, etc) …

 

 

 

Changes captured on the corresponding services are propagated toward courses of actions and rules that are appropriately reconfigured in screen 2 in order to support achievement of these changes. New sub-activities such as assign bonus and add to lottery emerge inside the activity register visitor. Also appropriate responsibilities are assigned to participants in order to support their realisation according to these changes.

 

Screen 2 : Impacts of the changes on the courses of actions and business rules  as well as on responsibilities assigned to participants

 

 

Finally the screen copy below shows the architectural backbone of the system that is updated by transforming the above functional representations into their corresponding object-oriented specifications. As illustrated, the architectural backbone of the previous version of the system remains the same ; the software architecture is simply updated with new behaviours such as new components and operations.

 

Screen 3 : Impacts of the changes on the goal-driven service oriented architectural backbone of the system

 

Notice that structures (goal-driven services, use cases, entities, responsibilities of the participants as well as their relationships) of the previous version of the GD-SOA above are all preserved.

 

Thanks to the top-down traceability mechanism supported by the goal-driven and service oriented architecture of the process, changes are first applied to these components that concentrate on their own appropriate business knowledge (goal-driven services), then to the application logic (use cases) rather than being scuttered on several entity objects of the system.

 

Such a scuttering of the business knowledge is systematic with use case driven and traditional object-oriented development methodologies that potentially cause maintenance and business performance issues in face of changes.

 

 

 

       

Copyright © 2005 - 2007 Goobiz.com - Birol Berkem 

 

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

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

[Semantic Web] : John Hall , How will the Semantic Web support business ? - W3C Workshop on Rule Languages for Interoperability http://www.w3.org/2004/12/rules-ws/paper/127 , April 2005

[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

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