Notice : The framework presented below focuses on the missing governance links of the TOGAF Content Framework using contributions from the OMG's Business Architecture Views and those presented in the Business Motivation Model (BMM) then it illustrates how to go down toward IT systems implementation layers with traceability to allow SOA based IT system components to evolve coherently according to strategic and tactical changes.

 

 

 

by Birol Berkem (Ph. D) - GooBiz - Paris / France

 

Abstract 

 

The SOA Urbanization Framework aims at providing organisations with a framework that helps to increase their competitiveness by synchronizing IT systems with evolutions of their goals and underlying business capabilities.

 

In this perspective, this presentation gives a brief insight on how to link your business vision, goals, strategies, tactics as well as business rules according to BMM (1), then bridges these business specifications toward components of the Service Oriented Architecture (SOA) in order to align IT system components to changing goals and capabilities (2).

 

(1) The Business Motivation Model [BMM] - Business Governance in a Volatile World voted by the OMG in 2007.

(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].

 

 

1         Introduction : wHY SOA COMPONENTS NEED TO BE BASED ON THE BMM usIng busIness capabIlItIes ?

 

Since the last few years, most of the emerging SOA development methodologies try to determine SOA services on the basis of business processes being totally disconnected from business goals and capabilities. As a consequence, the resulting IT system suffers from agility issues in aligning service descriptions to changing business decisions. 

 

Indeed, as 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 that are the business capabilities of the organization - 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 the organization and its customers.

 

The concept of business capability is also referenced within the TOGAF Enterprise Architecture Content MetaModel [TOGAF 9.1] but without any formal link toward business functions, processes, services or IT layer components.

As illustrated in the metamodel below, in such a disconnected situation, it is impossible to measure impacts of strategical changes (driver, goal, objective) on the business capabilities to align business and IT system components according to these changes !

 

 

In the TOGAF Content MetaModel [TOGAF 9.1], there are missing links between the group of Strategies (Driver, Goal, Objecvtive), Business Capabilities and Functions to align business and IT system components according to strategic changes

 

 

 

The OMG's Business Architecture Working Group defines its business architecture views being supervized by the business strategy view that captures tactical and strategic goals of the organization (cf. below).

 

Figure 1 : An Inherent Goal-Driven Alignment from the Business Strategy View toward the Organizational View of the OMG's Business Architecture Working Group

 

In order to capitalize on these business capabilities to align IT system components to changes, we model these capabilities using business objects and their states where instructions necessary to the development and functioning of the organization are encapsulated to impact the corresponding IT system components.

 

The example shown below illustrates some of the business capabilities of a WebSale Company using its business objects and states to support the previous business strategy view summarized there by its enterprise vision.

Enterprise Business Objects and their relationships are part of the business knowledge view.

The Process View that realizes some of these business capabilities will be shown next within their own organizational units (organizational view).

 

Figure 2 : An example on the OMG's Business Architecture capability and knowledge views expressed respectively using business entities, their states and relationships

 

 

STRUCTURING BUSINESS CAPABILITIES TO ALIGN CORRESPONDING SOA COMPONENTS

 

In order to align IT system structures with changes captured on the business requirements till their software implementation, service levels expected from business capabilities and how they need to be orchestrated to deliver the business value to customers must be determined at the business capability view layer.

 

To do this, we define 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) according to appropriate service level expectations.

 

Behaviours of these service points are controled by their orchestrator Visitor [Registration] -the GDBS .

 

The figure below shows a GDBS that orchestrates behaviors expected from its service points (SRV-Ps) to realize the Visitor [Registration] capability.

 

 

Figure 3 : A Goal-Driven Business Service (GDBS) orchestrates behaviors 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.

 

At the system layer, we will also introduce the concept of Goal-Driven Service (GdS) as a specialization of the GDBS in order to complete its behaviors by considering the usage constraints of its users at the functional (system) layer.

 

 

Goal-Driven Process Modeling to Capitalize on the Business Capabilities

 

In order to capitalize on the business capabilities when dealing with changes on strategies, we expressed business capabilities, their GDBS and service points using goal-oriented objects (business objects expressed within states to execute some behaviors to realize a requested goal).

 

Such a representation allows us to bring extensions to behaviours already assigned to capabilities just by adding new constraints to their states (see figure 4 below).

 

This way, business process that realize services exposed by capabilities are to be reconfigured according to these changes.

 

The figure below shows potential impacts of tactical changes requested from a business capability on the actions that support its realization.

 

Thanks to its goal-driven object representation, the GDBS Visitor [Registration] allows us to reuse existing behaviors of its basic process and apply on its activities changes in respect to constraints expressed using the UML's curved brackets.

 

Figure 4 : A description of the Process that realizes the Visitor [Registration] Capability with constraints applied to its activities

 

 

Such a "goal-driven tracking" of the business processes helps us to :

• realize a goal-based traceability and impact analysis in face of changes on the business capabilities,

• reconfigure appropriate activities of business processes according to these changes by reusing all other activities of the process.

 

 

Business Capability Components within the Business and IT Layers of the SOA

 

As we have stated above (cf. figure 3), business capabilities are piloted by their own GDBS that orchestrates activities that are part of their service points.

 

Behaviors of a GDBS defined at the business layer can be extended by a Goal-Driven Service (GdS) at the functional layer by considering application choices of their users.

 

This means that additional usage scenarios about the invocation of a GDBS component may be required at the functional layer as IT users may request to use these components by making some changes to them while respecting related business constraints - cf. : Pattern for using Business Behaviours from the Application Layer.

 

The diagram below shows service and use case components as well as their realization scenarios into the Business and IT Architecture layers.

 

Actions of GD-Service Points (SRV-P in the figure) can be executed themselves when they are called by their Goal-Driven Service (GdS) and may interact with use case components in situations where an actor interaction is necessary.

 

For example, in order to realize the function Enter Visitor , the service-point Visitor[Entry] needs to interact with the use case component Enter Visitor.

 

GDBS and GdS (their IT layer extension) also help us to discover entity objects they have to handle via their service point operations. For instance, the GdS Visitor [Registration] may help us to discover entity objects such as Visitor, Marketing, Sales etc,...on the basis of requirements that are supported by its operations.

 

 

 

 

Figure 5 : An hierarchical view from goal-driven services and service points toward process activities, use cases and entities

 

 

 

Integration of the Business Motivation Model within the SOA Framework

 

Finally, in order to better react to changes at the business level decisions, the Goal-Driven SOA framework integrates the core elements of the BMM and provides traceability support from business motivation elements (vision, goals, strategies, tactics, policies, etc...) toward IT system components on the basis of the business capabilities.

 

 

In the figure below, dashed circles indicate the core elements of the BMM that are considered as primary for bridging BMM to SOA. As shown in the figure, business goals as part of the ends drive strategy and tactic, rules and policies till business processes.

 

 

                                                                                                                                                                    

Figure 6 :   The Business Motivation Model  for the Business Governance in a Volatile World [BMM] of the Business Rules Group  first 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 Zachman's Enterprise Architecture Framework [BMM 2007].

 

As the IT architecture needs to closely reflect the business goals and be based on the business capacities to capitalize on the business knowledge of the organization, the Goal-Driven SOA Framework becomes necessary to structure IT systems on the basis of this goal-driven and capability based alignment.

 

This way, the following abstraction layers of this framework aims at establishing a bridge from the business architecture views toward IT architecture components to carry out business needs and trace impacts of changes till the software level :

:

• The Business Motivation Layer (the "Why") : to reconfigure business processes and responsibilities of their participants according to changes captured at the business layer (strategic, tactical or rule based changes to support desired results),

• The Functional Service Definition Layer (the "What") : to determine impacts of the previous changes on the IT level system components (services that are derived from processes and capabilities, use cases and entity objects) as well as on system requirements that implement business rules,

• The Application Layer (the "Technical How") : to describe realization of functional specifications from the application presentation layer (user interfaces) to the persistance layer (database entities) within the architecture,

• The Deployment Layer (the "Where"): to describe location of the technical 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.

 

 

In this perspective, the section below explains elements of the Goal-Driven Development Framework as well as their relationships from the business goals through the software implementation level.

 

 

 

2         LINKS FROM THE BUSINESS MOTIVATION MODEL to soa

 

In order to bridge business decisions toward IT system behaviors, the SOA framework illustrated below focuses on the IT alignment of the Functional and Application layers according to the Business Motivation (the "Why") layer decisions rather than using traditional IT urbanization concepts such as zones, districts and blocks.

 

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

 

The Functional Service Definition Layer (the "What") focuses on identifying 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.

 

The Functional Service Description and Realization level (the "Functional How") is about detailed specifications of services and use cases. Then it focuses on actions that realize behaviors of these components from the User Interface toward Entity Objects.

 

The Application Layer (the "Technical How") focuses on the technical specifications of services and use cases to implement the Goal-Driven SOA backbone. In this context, it focuses on the plug-in of technical components to realize behaviors of functional elements from the User Interface toward Database entities.

 

Finally, the Deployment Layer ("the Where") describes the physical deployment of the technical components.

 

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

 

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

 

Notice : According to the Business Capabilities view of the OMG's BAWG that describes the primary business activities of the organization, service components defined below at the service definition layer are first identified as part of the Business Capabilitiy component of the Business Motivation Layer to support realization of these capabilities (cf.. figure 3 above).

 

Figure 7: Overview on the MAIN elements of the business and functional abstraction levels to bridge BMM to SOA. The internal structure of the Business Capability Component (the GDBS and Service Points) are shown on the figure 3

 

In the next paragraph, we introduce traceability relationships between elements of these abstraction layers. To better help to understand the meaning of each element, we show them by giving examples of the case study attached to these elements.

 

 

      2.1 relationships INSIDE the BUSINESS MOTIVATION LAYER - (The "why")

 

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

 

On the basis of the business vision of our case study 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".

 

Tactics impose constraints to the business capabilities that can be breakdown for organizational reasons.

 

For instance, the tactic "Motivate Visitors to Register" may apply contraints to the business capabilities such as Product Presentation and Visitor Registration, thus to let them reconfigure their corresponding processes.

 

At the bottom part of the model, directives (policies or business rules) support achievement of business goals.

 

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 exactly a strategy will translate to actions then guide business processes.

 

A policy is composed of directive elements, each of them can be an underlying policy or a business rule. In the example below, the policy "Marketing Staff to keep Visitors on the WebSite ..." aggregates two essential business rules that respectively are about the Abandon rate of Visitors within the Product Consultation (BR1.a) and Registration Processes (BR2.a).

 

Finally, in order to realize business capabilities that are constrained by tactical changes, business processes are appropriately designed. During its achievement, a process (with the source role in the figure below) may need to communicate with other processes (targets) and 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 8 : Elements of the Business Motivation Layer and their relationships to govern the bridge toward the SOA service definition layer. Business functions that deliver business capabilities (cf. TOGAF Content MetaModel above) are considered as part of these capability components. Business processes that realize these capabilities manage activities and actions that compose them. An action may be a human task or an automated action.

 

 

 

2.2 LINKS TOWARD THE FUNCTIONAL LAYER (FROM "WHY" to "whAT") TO DEFINE IT SERVICES, USE CASES, UI, ENTITIES, etc...

 

 

As stated above, behaviors of a GDBS defined at the business layer are traced by a Goal-Driven Service (GdS) at the functional system layer to consider application choices of users.

 

In this perspective, we have illustrated (cf figure 5) how use cases, service points and related user interface components as well as entities should interact to support realization of a GdS. These links are shown at the figure below.

 

Use Case Identification

 

Use Cases components are identified according to responsibilities assigned to the participants of a business process. Then, they are described to support actor / system interactions necessary to realize a GdS or behaviors requested from a service point (SRV-P).

 

In the figure below, use case components are illustrated via "Use Case Service Points" that are exposed by Use Cases.

 

 

 

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

 

 

 

Goal-driven services carry out strategic and tactical constraints they receive from business capabilities and transmit them to their service/request points « SRV-P » and corresponding use case components. In this context, they handle processing of related exceptions, SLA (Service Level Agreement) constraints and can easily provide inputs for process feed-back mechanisms supported by the BAM (Business Activity Monitoring) tools.

 

 

 

2.3 LINKs TOward the SERVICE description AND REALIZATION LAYER - (FROM THE "WHAT" TO "HOW")

 

The main role of the service description and realization layer is to give a description of appropriate goal-driven services and use cases identified at the business motivation layer then explain how to realize them.

 

Goal-Driven Services that are identified previously according to Business Capabilities and their tactic based evolutions as well as Use Cases that are determined at the Service Definition Layer (The What) are traced and detailed at the Service Description Layer (the how) respectively by the corresponding descriptions.

 

UC and Service Operations are described there by the corresponding scenarios.

For instance, operations like Enter Visitor, Fill Questionnaire and Notify Visitor... that may be potentially exposed by the service point Visitor [Entry] are to be described at this layer by the corresponding scenarios.

Same things apply for the description of use case operations..

 

Service Contracts and Exchanged Data between service operations (see figure above) are also described there.

The paragraph below shows.relationships inside the service description layer.

 

Figure 10 : Links from Service Definition / Usage Layer (the WHAT) toward Service Description Layer (the HOW)

 

 

 

 

2.4 relationships INSIDE THE SERVICE DESCRIPTION AND REALIZATION LAYER (HOW TO HOW)

 

The purpose of the Service Realization sub-layer is to describe how to achieve service and use case scenarios 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 logical components.

Each logical component orchestrate their own underlying actions described in the service realization layer.

 

For instance, connections illustrated in figure 11 below can allow us to realize the Enter Visitor scenario using actions of the presentation, use case and service logical components as shown below.

 

These actions may be identified using an activity diagram that illustrate collaborations between actions of each logical layer (see figure 12).

 

Figure 11 : Relationships inside the Service Description and Realization Layer (the Functional HOW)

 

 

An illustration of interactions between GUI, Use Case and Service Components to materialize the “Enter Visitor” scenario according to these relatioships is described below (figure 12).

 

From left to right, screens and UI actions of the GUI Presentation interact with actions of the Use Case Components (UC-Comp) and finally with actions of the Service Point (SRV-Comp) 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.

 

Components that are illustrated at the bottom part of the figure illustrate UC and Service Components with their operations generated on the basis of the corresponding actions.

 

These components will be plugged into the SOA backbone to describe implementation of the corresponding UC and Service Points (see figure 13 next).

 

 

Figure 12 :  Interactions defined at the Functional Service Realization Layer between GUI, Use Case and Service components to Enter Visitor

 

 

2.5 AN OVERVIEW : FROM THE functional TO THE APPLICATION LAYER

 

Application layer components that realize functional specifications described in the service description layer constitute the bottom part of the Goal-Driven Service Oriented Architecture backbone.

 

Once completed, use case and service components that are described in the last step (cf. figure 12) are plugged into their respective parent components within this architecture backbone as illustrated in the figure 13 below.

 

NOTICE : Components of business capabilities are illustrated in the figure below just to remind hierarchy of constraints applied through Business Capabilities until Goal-Driven Services and Service Points.

 

 

Figure 13 : At the application layer (the Technical How), use case and service components are plugged into their respective parent components within the goal-driven architectural backbone of the system

 

 

2.6 FROM APPLICATION REALIZATION TO DEPLOYMENT (FROM THE TECHNICAL "HOW" TO "WHERE")

 

Components that are described in the previous layer are affected to organizational 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 in respect to the PIM and PSM viewpoints of the OMG's MDA.

 

 

 

3 CONCLUSION

 

The Goal-Driven SOA Urbanization Framework illustrated here is intended to increase business competitiveness of organizations by synchronizing their IT systems with evolutions of their business goals and capabilities.

 

In this perspective, the layered architecture of the "Goal-Driven SOA" Framework permits to understand how to model business motivations (vision, goals, objectives, strategies, tactics, rules and processes) by capitalizing on the business capabilities and identify traceability relationships that permit to connect business goals and directives toward elements of the software level specifications.

 

Patterns about technical level transformations of business motivations and capabilities toward software implementations are considered on http://www.goobiz.com

 

   

4 REFERENCES

 

[Business Capabilities] : http://msdn.microsoft.com/en-us/library/aa479368.aspx#servorient_topic3

[Business Capabilities View] : The OMG's Business Architecture Working Group http://bawg.omg.org/business_architecture_overview.htm

[Business-Oriented Foundation] : Ulrich Homann - MSDN - http://msdn.microsoft.com/en-us/library/aa479368.aspx#servorient_topic3

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

[Business Rule ] : Defining Business Rules

[Running Business on your Goals and Directives] http://www.goobiz.com/RunningBusinessOnTheGoals.htm

[SoaML] : http://www.omg.org/docs/ad/08-08-04.pdf

[TOGAF 9.1] : http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html#tag_34_02_01

 

 

 

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