Notice : The process explained in this series of three articles presented below using a case study aims at driving SOA based IT system design according to strategic and tactical changes imposed to business capabilities of the organizations.

Elements that are involved in this alignment process allows organizations to establish an architecture bridge from their business model using the BMM toward an enterprise SOA operating model according to the Business toward SOA Operating Model Framework provided in "From BMM and TOGAF 9 toward SOA" presentation paper.


The process is composed of the following methodological steps :


Step 1 - Describe business strategies, tactics and capabilities on the basis of business goals

Step 2 - Model business processes that realize service points exposed by business capabilities

Step 3 - Discover IT level use cases that have to invoke these service points

Step 4 - Elaborate a draft backbone of the corresponding "Goal-Driven SOA" Architecture

Step 5 and 6 - Describe IT level use case and service behaviours that have to be plugged into this SOA backbone



Birol Berkem - Goobiz (Paris / France)





Since more than a decade, use case driven development processes are widely used by organizations for building IT systems. Such practices allow them to develop systems on the basis of the end-user scenarios that offer efficient techniques to capture requirements and to prepare test cases.

However, systems developed only with use-case (or user story) driven methods do not provide organizations with good levels of reactivity in face of changes. This is because such systems are directly structured depending on the usage scenarios of their actors (end-users) rather than being structured first according to business goals (1), capabilities (2) and business rules (3).

As a result, the resulting systems are unable to capture changes on the business needs and to propagate them coherently toward IT applications.


In order to illustrate how to develop IT applications on the basis of business goals then aligning them to changing business requirements, we present below steps of the Goal-Driven Service Oriented Architecture (GD-SOA) (4) Process on a case study using the Enterprise Architect (EA) modeling tool.



(1) 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".


(2) Business Capability : A particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. A business capability describes what the business does (outcomes and service levels) that creates value for customers - [Business-Oriented Foundation]


(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 business capabilities and changing business decisions.





The current practice of use case (or user story) driven system and software development presents efficient techniques to capture requirements on the basis of usage scenarios of the system and establishes good foundations for test cases.


But, this does not allow organizations to react to changes swiftly and coherently due to following essentials reasons :


  1. Business Use Cases are not aware of high-level business goals : vision, strategies, tactics, etc...; so changes on these high-level goals are not traceable to impact user requirements and IT level components,
  2. There is no capitalization on the business capabilities to reuse them systematically within the system alignment process,
  3. There is a lack of visibility on the business rules as they are mixed within actor/system interactions inside use cases.


Such a lack of visibility of the goals and rules as well as traceability issues toward software or system implementations become an important obstacle for aligning IT systems with changing goals and related business rules. As a consequence, important maintenance costs are required to align IT applications to changes.


For the same reasons, emerging SOA approachs that try to determine services on the basis of business processes and use cases do not help organizations to resolve these agility issues. 


In order to allow organizations to increase their goal-driven business agility, the successful process should consider high-level business goals, look for business capabilities and processes that have to support them, finally identify behaviours of appropriate SOA services and use cases to realize alignment of the IT system to changes.


The Business Motivation Model Diagram [BMM] referenced in the figure 1 below shows some of these "goal-driven relationships". Its basic elements that are considered as primary by the Goal-Driven Development Process [Goobiz] are indicated using dashed circles.


As shown in this figure, goals drive strategies and tactics, as well as rules and policies until business processes.


Some examples from goals toward business rules and processes are given at the right of the figure for our WebSale System case study.





Figure 1 :   The Business Motivation Model  for Business Governance [BMM]  voted by the OMG in September 2005





In the same way, the OMG's Business Architecture SIG defines its business architecture views being supervised by the business strategy view that captures tactical and strategic goals of the organization (cf. below).





As the IT architecture needs to closely reflect the business goals of the organization [TOGAF], a Goal-Driven SOA Framework becomes necessary to structure IT systems on the basis of this goal-driven alignment.


     The role of this framework is to establish a bridge from the business architecture views toward IT architecture components that has to carry out business needs and trace impacts of changes till the software level.


In this perspective, the next section explains the steps of the Goal-Driven Development Process from the 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 respectively fixed 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 :


    • Step 1 focuses on describing business strategies, tactics, capabilities and processes on the basis of business goals
    • Step 2 models business processes that realize business capabilities
    • Step 3 describes how use cases invoke business capabilities
    • Step 4 elaborates a first draft of the Goal-Driven SOA backbone, by transforming functional specifications of the business analysts related to step 1 to 3 into corresponding service-oriented software components.
    • Step 5 describes underlying behaviours of software components toward their implementation
    • Step 6 integrates behaviours of these software components into Goal-Driven SOA backbone as pluggable components



An application of these steps to our case study is given below.




Step 1  : Describe business strategies, tactics, and capabilities 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.


On the basis of these hierarchies from goals toward business processes and underlying requirements assigned to these processes, we look for dependencies between these elements.



The figure 1.1 below illustrates graphically such dependencies from the business goal "Beneficial WebSale System" until strategies and underlying tactics (G1,G2, G4) that control business processes.


At the right of the figure, the project browser shows descriptions of these elements.




Figure 1.1 :  Dependencies between Business Goals, Strategies and underlying Tactics until Business Processes



Important Notice : As these stategic items (goals, strategies, tactics) and business processes evolve frequently in time, it is difficult to capitalize on them to align IT applications with changing business decisions.

So we need to look for more stable elements. These emergent elements are business capabilities of the organization.







To build the business architecture around more stable business elements of the organization, we look first for business capabilities - capacities that a company should possess or exchange to support its vision. A business capability describes what the business does (outcomes and service levels) that creates value for customers- [Business-Oriented Foundation].


Secondly, in order to capitalize on these business capabilities to align IT system components to changes, we model them using business objects and their states (DNA of the organization that encapsulate in these states instructions used in its development and functioning) then track impacts of changing strategies and tactics on them.


The example shown below illustrates a very small number of capability components that support the business vision of a "WebSale Company". These components are initially obtained after decomposition of a first level capability cartography elements that may be constitued of business functions like Product Management, Visitor Management, Customer Management and Order Management.


These capability components are, in turn, supported by enterprise business objects.





Figure 1.2 :  From the Company Vision to Business Capabilities and Business Objects




The Business Capabilities View of the OMG's Business Architecture Working Group [Business Capabilities View] describes the primary business functions and pieces of the organization that perform these functions.


As we have stated above, the business capabilities and process views are both driven there by the business strategy view that captures tactical and strategic goals of the organization.


In order to coherently align system structures with strategic and tactical changes till their IT implementation, service levels expected from business capabilities and how they need to be orchestrated to deliver the business value to its customers must be rendered identifiable at the business layer.


This way, we identify goal-driven business services (GDBS) as mutualized functions that deliver the value of business capabilities according to high-level business goals.


In this context, each GDBS orchestrates realization of requirements assigned to a business capability in respect to business service levels expected from its service/request points « SRV-Ps».


For instance, in the case of a WebSale system, requirements assigned to the business capability Visitor [Registration] are distributed among its service components (the GDBS and service points) with appropriate service level expectations.


Behaviours of these service points are controled by their GDBS Visitor [Registration] - shortly named below a Goal-Driven Service (GDS) indifferently.





Figure 2.1 : A Goal-Driven Service (GDBS) orchestrates behavior expected from its service points (SRV-Ps) to realize a business capability



Notice : Encapsulating service components by appropriate business capabilities help us to understand how to reconfigure such capabilities in order to attain values imposed by changing strategies and tactics.



Naturally, service components of a business capability may need to invoke activities of other business capability service components for their own realization.


The figure below shows the business capability Visitor [Registration] that invokes another business capability service- Visitor [Turn into buyer] in order to turn registered visitors into buyers.




Figure 2.2 : Services of a business capability may invoke other business capabilities


Click to visualize : "How to capitalize on the business capabilities in face of changing goals (with illustrations upon the WebSale System - Case Study) "



On the basis of these specifications, we model in the second part of this case study, business processes that realize these capabilities and use cases that invoke their service components. Finally we build a draft of the Goal-Driven SOA backbone where service behaviours are plugged into corresponding service points.




Click to follow with the second part of this case study...






Creative Commons License
This work by Birol Berkem ( 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

Birol Berkem (Ph.D), GooBiz