Previous column

Next article

From The Business Motivation Model (BMM) To Service Oriented Architecture (SOA)

Birol Berkem, GooBiz (Paris / France)



PDF Icon
PDF Version

Please note that an updated and extended version of this column is available at:


The purpose of this article is to provide a brief insight about how to link your business vision, goals, strategies, tactics as well as business rules according to BMM, then bridging the resulting business specifications toward components of a Service Oriented Architecture (SOA) in order to align IT according to your goals and directives.

The Business Motivation Model [BMM] - Business Governance in a Volatile World was first voted by the OMG in 2005.


Since the last few years, most of the emerging SOA approaches try to determine SOA services on the basis of business processes being totally disconnected from business goals and rules.

In these approaches, interactions between services and internal behaviors of services are not described according to strategies, tactics and rules fixed at the business layer. As a consequence, the resulting system suffer from agility issues in aligning service descriptions to changing decisions of the management.

In order to react swiftly and coherently to changes, the agile SOA architecture must integrate the core elements of the BMM as suggested in the OMG's SoaML [SoaML] by providing a capability to capture how services realise business motivations (vision, goals, objectives, missions, strategies,tactics, policies, regulations, etc...).

Thus, to ensure a good level of business governance for the IT, the SOA development process should support at least the following traceabilities:

  • -IT services to achieve business processes,
  • -Requirements that compose these services to the business rules,
  • -Governance of these services to tactics that implement business strategies,
  • -Use Cases to responsibilities assigned to participants of the business processes.

Such a synchronisation of the SOA system by the business motivations requires the following abstraction layers :

  • The WHY : to reconfigure business processes and responsibilities of their participants according to changes captured at the business layer (changes on the means (tactics) or directives (rules) that support desired results),
  • The WHAT : to determine changes on the IT level system components (services that are derived from processes, use cases and entity objects) as well as on system requirements that implement business rules,
  • The HOW : to describe realisation of these specifications in the architecture (from the presentation layer to the entity layer),
  • The WHERE : to describe location of these components starting by their high-level descriptions like agencies, headquarters, front and back offices, etc...until physical nodes of the architecture where they should be deployed.

Below, we only focus on the bridge from BMM to IT level specifications from the point of view of the business experts, analysts and designers. This corresponds to the CIM (Computation Independent Model) level specifications in the OMG's MDA (Model Driven Architecture).

The Business Motivation Model (BMM) referenced in the figure 1 below shows a brief insight on relationships between elements of the business layer.

Its core elements that are considered as primary for bridging BMM to SOA are indicated using dashed circles. As shown in the figure, business goals as part of the ends drive courses of actions (strategy and tactic), directives (rules and policies) till business processes.

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

The Business Motivation Model addresses especially the business Owner's perspective (i.e., row two) of the sixth aspect (i.e., the Motivation or 'Why' column) of the Enterprise Framework of Zachman [BMM 2007].


In order to bridge business decisions toward IT system behaviors, the SOA framework focus especially on the Business Motivation (the "Why"),and the Service Definition (the "What") layers as well as on the Service Realisation (the "How") layer as indicated in the figure 2 below.

Inside the Business Motivation Layer, the main focused elements are the Goal (END), Strategy, Tactic (MEANS), Business Rule (DIRECTIVE), Business Processes and Resources.

The Service Definition Layer focuses on discoverying services of the system and use cases that are candidate to invoke them as well as resources that are to be handled by services at this abstraction level.

Finally the Service Description and Realisation Layer focuses first on detailed specifications of services and use cases. Then it focuses on actions that realise behaviors of these components from the User Interface toward Entity Objects.

Along this refinement process, requirements that are discovered on the basis of the Business Motivation Layer are used and enriched by the Service Definition and Realisation layers.

The schema below shows an overview on the main elements of these abstraction levels. Details about top down traceability relationships between these levels are presented next.

Figure 2: Overview on the main elements of the abstraction levels to bridge BMM to SOA

In the next paragraph, we explain traceability relationships between elements of these abstraction layers. To better help to understand the meaning of each element, we show them each of examples in post-its attached to by giving elements.


Inside this layer, we focus on the main elements of the core BMM that permit to describe business processes guided by goals, rules and tactics.

On the basis of a business vision that is "To be a profitable customer focused websale company", the main goal of the business is given as "To build a Beneficial WebSite System". A strategy that channel efforts toward that goal is set to " Turning visitors into Buyers ".

Two first tactics are discovered in order to implement this strategy. These are indicated by G3- Motivate internet visitors to Register using a Bonus System" and G2 - Encourage Sales Employees to turn Visitors into Buyers".

At the bottom part of the model, business rules are identified as rules that support achievement of the business goal. A business rule is a statement that defines or constrains some aspects of the business [Business Rules]. In the context of the Business Motivation Layer, business rules provide the tactical detail about how a strategy will translate to actions then guide business processes shown at the right.

In order to trace accurately business rules toward the Service layer, we distinguish two kind of rules: composite and leaf business rules.

A composite business rule is composed of elements, each of them can be a composite or a leaf business rule. In the example below, the composite rule "Marketing Staff to keep Visitors on the WebSite..." aggregates two essential leaf level rules BR1 and BR2 that respectively ask to Incite Visitors to Register during their product consultation on the website (BR1) and motivate them to complete their registration process (BR2).

Finally, in order to realise tactics being guided by the business rules, business processes are appropriately designed. During its achievement, a process (the source) needs to communicate with other processes (targets) and may assign responsibilities to some of its participants (internal or external actors). For instance, along the registration process, if the abandon rate is over than 30%, the marketing staff should be "assigned the responsibility" to review the questionnaire according to the business rule BR2.a.

Figure 3: Elements of the Business Motivation Layer and their relationships to govern the bridge toward the SOA service definition layer

The figure below shows a high-level description of the business processes that realise tactics G1, G3 and G4, being guided by the business rules BR1, BR1.a, BR2, BR2.a referenced above. Business rules that guide business processes are expressed using UML notes and attached to these processes. Some useful states in the description of the processes are indicated on them using rectangular icons (the UML 2 object nodes).

Figure 4: Main Processes of the WebSale System partitioned by tactics and being guided by business rules to govern the bridge toward the service definition layer


Tactics and business rules determined in the Business Motivation Layer are respectively traced toward the Service Layer to drive services (see figure below) and to d e rive Requirements that compose them.

Inside the service layer, a tactic acts as a facade to "drive" a set of goal-driven services and is composed of requirements derived from a related business rule. For instance, in order to support the tactic G3 - Motivate visitors to Register, goal-driven services G3.1 and G3.2 have respectively to Incite visitors to register during product consultation (G3.1) and to Motivate to complete his registration once started (G3.2).

A goal-driven service is defined for each business process of the business motivation layer and is composed of a cohesive set of requirements that implement business rules that guide this process.

For instance, the service G3.2 - Register Visitor supports achievement of the business process Register Visitor (illustrated in figure 4). It is composed of a set of requirements R3.2.1, R3.2.2, R3.2.3 that implement the business rules BR2 and BR2.a about Motivating Visitors to complete their registration process.

Notice that grouping requirements first on the basis of tactics then by services help to design stable and loosely coupled services in order to increase their adaptation to changes and better control their evolution on the basis of changing tactics.

Goal-Driven Services also permit to identify use cases using a one-to-one traceability relationship as well as entity objects they have to handle on the basis of requirements that compose them. For example the service G3.2- Register Visitor permits to identify the use case Register Visitor and help us to discover entity objects Visitor, Marketing, Sales,... on the basis of requirements that are part of this service.

Figure 5: Links between the Business Motivation Layer (the WHY) and the Service Definition / Usage Layer (the WHAT)

The below diagram shows examples of tactics G1, G3, G4 that are modeled using boundaries. Inside each tactic, services are invoked by use cases. Requirements that compose services are indicated at the right in the Project Browser.

An hierarchical view of services grouped by tactics and use cases defined to invoke them


The main role of the service description and realisation layer is to give a description of appropriate goal-driven services and use cases identified at the previous layer then explain what means to use to realise them.

Tactics, Services and Use Cases that are determined at the Service Definition Layer (The What) are traced and described at the Service Description Layer (the how) respectively by Tactic, Service and Use Case Descriptions.

A goal-driven service description is a process that can be materialised by an activity (a composite structure) or an action. An activity contains underlying activities or actions. For example, the service Register Visitor discovered at the previous layer may be described at this layer using actions Enter Visitor, Fill Questionnaire and Notify Visitor...

Same things apply for a use case description...

Figure 6: Links from Service Definition / Usage Layer (the WHAT) to Service Description and Realisation Layer(the HOW)


The purpose of the realisation sub-layer is to describe how to achieve service actions and use case actions of the Service Description Layer using components of a logical IT architecture (Presentation, Application, Business Service and Domain Object Layers)

Actions of the service description layer are described there using collaborations between these components that orchestrate their underlying actions.

For instance, the service action Enter Visitor may be realised by a collaboration between actions of couples of use case and service components as shown below.

Figure 7: Relationships inside the Service Description and Realisation Layer (the HOW)

An example to collaborations between components of the Service Realisation Layer is given by the activity diagram below.

The example is about the implementation of the action “Enter Visitor” that is described at the Service Description Layer.

From left to right, screens and actions of the Actor Interface Component (GUI Presentation) interact with actions of the Use Case (UC) and Service components (GdS) to "Enter Visitor".

Use Case actions operate on graphical user interfaces (GUI) whereas Service actions operate on entity objects, most of the time by changing their states.

Figure 8: Interactions defined at the Service Realisation Layer between GUI, Use Case and Service components to Enter Visitor


Components that are described in the previous layer are affected to organisational locations. For instance, components related to the presentation and use case layers may be assigned to agencies in front and back-offices whereas service components and entities may be hosted in the headquarter area.

Logical and Physical nodes of the architecture where components should be deployed are respectively determined at the PIM and PSM levels of the OMG's MDA.


In order to increase their competitivity, organisations need to synchronise their IT systems with evolutions of their business goals and directives.

This requires from Service Oriented Architectures to be structured according to business motivations (vision, goals, objectives, strategies,tactics, rules and processes).

In this perspective, the layered architecture of the "Goal-Driven SOA" Process permits to identify traceability relationships that permits to connect such high level business goals and directives toward elements of the software level specifications.


[BMM 2007]: The Business Motivation Model - September 2007

[Business Rule ]:

[RunningBusinessOnGoals]: h ttp://


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


About the author

Birol Berkem (PhD) is a consultant and trainer in the areas of business and application system analysis and design. He has more than twenty years practical experience in the system analysis and design. Birol can be reached at

Birol Berkem: "From The Business Motivation Model (BMM) To Service Oriented Architecture (SOA)" Journal of Object Technology, vol. 7, no. 8, November-December, pp. 57-70

Previous column

Next article