HOW TO ALIGN SOA based IT SYSTEMS WITH CHANGING BUSINESS STRATEGIES ? - (Part II)
STEPS OF THE "GOAL-DRIVEN SOA" DEVELOPMENT PROCESS FROM REQUIREMENTS TOWARDS THE SOFTWARE IMPLEMENTATION LEVEL USING THE OPEN GROUP's TOGAF Architecture Framework AND THE OMG's SoaML, BMM and MDA STANDARDS
Notice : In the previous section of this SOA alignment process illustrated on a case study, we have shown how to identify and structure 'Business Capabilities" of the Business Motivation Layer starting by high-level business goals.
This section deals with the functional service description layer of the "Business toward SOA Operating Model Framework". It focuses essentially on the following implementation steps :
This step allows us to describe business processes that realize the Goal-Driven Service (orchestrator) and service points of a business capability.
The figure 3 below illustrates a description of the business process that realizes the GDBS Visitor [Registration].
Note that each action of this business process makes a call (request / response) to the activity encapsulated by a service point - which may be implemented by a web service.
Figure 3 : A GDBS orchestrates execution of Service Point Activities that are part of a "Business Capability"
Service point activities whose behaviour are invoked by the orchestrator (the GDBS) of a business capability component need also to be described in this step.
To reduce the volume of graphical specifications on this page, we present description of these activities in the step 3 below.
Step 3 : Discover how Use Cases invoke Service Points provided by these capability components
A Goal-Driven Service (GDBS) may require through its service / requests points « SRV-Ps » participation of resources (use cases, actors, entities, …) to realize process actions.
In such a goal-driven vision, service components that are part of a business capability may require use case components if they need actor / system interactions to realize related functions.
Separate identification of service components from its usage scenarios also provide them the ability to be invoked as web services by numerous client use cases.
The figure 4 below illustrates a description of action choreography between Use Case and Service Components that realize the Enter Visitor activity of the Service Point Visitor [Entry].
Figure 4 : Description of UC and Service actions that realize the Enter Visitor activity of the Service Point Visitor [Entry]
The figure 5 below illustrates previous service and use case components as well as their realization scenarios into the Business and IT Architecture layers.
Figure 5 : Representation of detailed interaction between a Goal-Driven Service Point Visitor [Entry] and its related Use Case Component Enter Visitor
Goal-driven services carry out strategic and tactical constraints imposed to business capabilities they support.
To react to such changes, they orchestrate behaviours implemented by their service/request points « SRV-P ».
In a business analysis monitoring (BAM) context, they also handle processing of related exceptions, SLA constraints imposed to their service points and provide related feed-back for the business analysis monitoring.
In the next step, we show description of goal-driven service and use case components at the IT system level with their service/ request points according to the OMG's SoaML standard.
After transformation into object components, Use Case and Service descriptions will be plugged into the architecture backbone of the 'Goal-Driven SOA" framework (cf. figures 7 and 8 in part III of this series).
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 email@example.com
Birol Berkem (Ph.D), GooBiz