The Business of SOA

© Copyright 2009, Metastorm Inc. This white paper is provided courtesy of Metastorm, Inc.

The Business of SOA Evolving an Agile Enterprise with Metastorm Enterprise

2 | The Business of SOA www.metastorm.com

Executive Summary

The justification of technology as a key business driver is drawing

renewed attention as executives look to build Service-Oriented

Architectures (SOA) to meet the needs of their dynamic

enterprises.

While an SOA can go far in addressing the important security,

reliability, and re-usability of services, SOA is nonetheless a

technical approach. Thus, the challenge of SOA—and the key to

achieving business value—is elevating service enablement

beyond just technology functions. The reality is that a SOA has

limited value unless it encompasses disparate applications and

platforms, moving beyond technology to be orchestrated and

controlled in the context of business processes. SOA technology

and methods provide a foundation for service enablement in an

orderly fashion and allow an organization to avoid the pitfalls of

deploying an uncontrolled maze of services.

But from the outset, organizations face the challenge of where to

start. What services are going to add immediate value? And how

are they going to be used by the most important business

functions? Identifying the services that are consumed by the most

critical business processes in an organization can be a daunting

proposition.

That‟s why Enterprise Architecture (EA), Business Process

Analysis (BPA) and Business Process Management (BPM) are

integral to effective service-orientation. SOA relies on the work of

EA, BPA and BPM to define, analyze, and execute resources

where SOA has the best effect. The result is an agile enterprise in

which business models drive executable business processes

powered by a portfolio of services.

In fact, Forrester underscores the importance of tying SOA to a

bigger architecture vision. “No prior industry initiative for IT

architecture has had an impact as positive and broad-reaching

as service-oriented architecture (SOA). But SOA's impact is only

part of the story: You have many more technology initiatives

besides SOA. You need a bigger architectural vision that

encompasses SOA, business process management, event

processing, Web 2.0, and much more besides. Although SOA is

far from dead, it should be buried inside a larger vision,”

according to SOA is Not Dead – But it Should be Buried: Doing SOA Right Opens the Door to a Much Bigger Architecture Vision, Forrester Research, Inc., May 11, 2009.


To answer the demand for collaborative and business-driven

SOA, Metastorm Enterprise provides a unique set of interrelated,

state of the art offerings that enable visibility across the enterprise

– thus empowering organizations to build systems that accurately

reflect business processes, easily adapt as processes change,

and improve productivity and process consistency. It all begins

with comprehensive modeling and analysis to bridge the

communication gap between business and IT. The Metastorm

ProVision® enterprise modeling solution is designed to enable

business users to participate in SOA initiatives and also robustly

supports the vital role of business and system engineers by

effectively defining execution-ready activities that marry business

processes to the services that make them work.

The Metastorm BPM® platform plays many other roles in the

SOA. While it guides service enablement and is an active

consumer of services, Metastorm BPM also allows actions within

automated business processes to be exposed via the SOA. With

BPM orchestration, this exposure of key business events and

information to users at the appropriate times and in the

appropriate contexts adds tremendous business value that might

not otherwise be achieved with an SOA. And Metastorm

Integration Manager (MIM), the system-based process

management component of the Metastorm BPM suite, manages

the execution of those services in key business processes under

a single SOA – integrating legacy mainframe applications,

enabling real-time data transfer, and exposing legacy

applications as services.

By focusing on the processes, activities, events, information, and

services that are required to execute the business, SOA gives

business owners a more direct and active role in the design of IT

systems that enable enterprise agility. In this paper, Metastorm

takes a close look at the opportunities and challenges of SOA,

and reveals how the powerful combination of EA, BPA, BPM and

SOA provide an important platform for business/IT alignment.


EXECUTIVE SUMMARY............................................................................2

SOA: A PROFOUND OPPORTUNITY....................................................................5

DYNAMIC RETOOLING USING REUSABLE

ENTERPRISE FUNCTIONS ENABLES AGILITY............................................................5

SERVICES DEFINITION IS THE FINESSE POINT FOR SOA..........................................6

THE CHALLENGE TO FORMALLY DEFINE THE ENTERPRISE......................................7

EMPOWERED BY MIDDLEWARE.............................................................9

A BROAD SCOPE: SOA INVOLVES THE ENTIRE ENTERPRISE......11

MODELING MANAGES COMPLEXITY..................................................13

STRATEGIC MODELING.........................................................................................14

BUSINESS MODELING...........................................................................................15

TECHNICAL MODELING.........................................................................................19

THE POWER OF BPM IN AN SOA ENVIRONMENT............................21

ORGANIZING COMPLEX BUSINESS FUNCTION REQUIREMENTS..................22

CLOSING CRITICAL PROCESS GAPS................................................................24

IDEAL FRAMEWORK FOR SOA..........................................................................24

PROVISIONING A WIDE VARIETY OF PROCESS SERVICES.............................25

ADVANCED SERVICE INTEGRATION AND LEGACY CONTROL.......................26

CONCLUSION...........................................................................................27


SOA: A Profound Opportunity

SOA presents a profound opportunity to improve organizations at

an enterprise level.

Applying well-founded concepts that exploit the ability of modern

system resources to collaborate independent of location across

heterogeneous technologies, SOA uses the same standards-

based communication technologies that underlie the web to allow

system resources to communicate dynamically. It defines

architectural principles backed by technology to tap into system

resources that in the past were isolated but can now freely

participate in a larger community – then provides tools and

techniques to orchestrate the reuse of these newly available

resources into the processes that drive the enterprise.

While impressive, the technology behind SOA will succeed only

to the degree that the enterprise can leverage these two core

capabilities:

Reusable system functions (services)

Orchestration of services into enterprise processes

By effectively deploying SOA programs, today‟s agile enterprise

can deliver a comprehensive portfolio of pre-built, flexible, easily

used, reusable, business-oriented services to business

professionals who configure rules and processes to meet

changing demand.

Dynamic Retooling with Reusable

Enterprise Functions Enables Agility

The big picture view of SOA shows an enterprise leveraging

complex system functions to realize immediate change. Business

professionals armed with formal tools adjust the way the

enterprise operates. The main dimensions they consider are their

processes, data and the rules that govern the behavior of the

processes.


Change is effected in business terms using business concepts. A

change in policy may be realized by a change in the rules

governing calculations, approvals or the triggering of other

actions. A change in procedure may be realized by adding new

activities into a business process and rerouting deliverables. The

key is to make available executable business artifacts that can be

manipulated by business professionals without requiring

technical system development.

Services Definition is the Finesse Point

for SOA

The term Service-Oriented Architecture aptly describes an

architectural approach centered on the notion of a service.

A service is, in effect, a function. It is something that can be

requested to do useful work. But a service is not a technical

artifact; it is an abstraction of many possible technical artifacts

into a single business artifact. The abstraction provides enough

detail to understand what the service can do, what is expected

from its consumer (the entity requesting the service to act) and

what the service will produce in return.

Figure 1. The ideal SOA implementation exposes to the business professional executable business rules and business activities within business processes that

are bound to services implemented by technical components.


Figure 2. A service is an abstraction of real system functionality that (optionally) accepts a request from its consumer and promises to

provide a defined response in return.

To use a service, the consumer must be able to reference the

service by its identity (its formal name), provide the service with

the data it needs, and understand the data it produces in

response. But SOA demands more than producing abstractions

of functionality. A service is a special type of abstraction, one that

is defined carefully to deliver functionality that is coarse enough

to be managed (e.g., discovered, registered, located, activated),

yet cohesive enough to be of general purpose use in a particular

scope. The abstraction must hide all technical details and expose

the essence of function to the non-technical consumer. A well-

defined service is easily understood in terms of the function it

performs, the contract (the input and output) it supports with its

consumers, and the quality of service it delivers with factors such

as cost, timeliness and reliability.

Properly implemented, SOA delivers a portfolio of services that

can be leveraged by business processes to meet the needs of

the dynamic enterprise, yet can be managed so that desired

services can be located and reused with efficiency.

The Challenge to Formally Define the

Enterprise

Although its concepts and technology are based upon decades

of progress in IT, SOA requires additional work to free

functionality locked up in legacy systems and to promote the

culture of reuse required to make effective use of that freed

functionality.

SOA starts at the enterprise level of scope. At this level, an

enterprise needs to rationalize the goals, measures, etc. that

direct progress toward its mission. It needs to profile its core

capabilities and understand which capabilities are critical to

achieve its goals and what enterprise artifacts provide the


capabilities. This understanding is used to direct resources to

implement SOA where the enterprise needs it most.

Below the strategic view we have the definition of how the

enterprise functions. This is where we find business processes,

data and rules. At this level SOA must empower business artifacts

with system functionality. The objective is to express formally how

the enterprise works in its own terminology, and to enable the

business professional to change processes, rules and the use of

data. The professional essentially changes a model of the

business to effect change in operational systems.

This requires balancing simplicity against control and control

against IT resource integrity. The model of the enterprise needs

to be familiar to each community. It must also contain enough

details to express the changes the enterprise needs to realize.

Yet this model must enforce the real-world constraints of the

supporting IT components. Each component consumes time,

incurs cost, and has limitations on availability, frequency of use,

etc. Changes in one business process cannot be allowed to

impact other business processes inadvertently. Data integrity

cannot be compromised. Security measures, audits, logging, and

other facets of the IT infrastructure must all be preserved. In other

words, the challenge is to expose enough functionality to allow

the business to retool safely without losing control over the

underlying IT resources.

Exposing IT functionality under SOA involves publishing services

and providing the means to execute the underlying components

that realize each service. Defining services properly is no easy

task. The notion of function is general enough to apply to almost

anything. The enterprise needs to adopt formalisms for

recognizing service functions so that 1) there is sufficient

Figure 3. Legacy functions are exposed as services by building service-oriented adapters.


coverage to support business processes and 2) the service

portfolio grows in a controlled fashion and holds only those

services that are truly needed.

The other critical IT challenge is to unlock functionality already

implemented in legacy systems. Most legacy systems were

designed with specific user and system interfaces. They were not

designed in the context of an overall service architecture and

thus do not provide access to the functions they implement. For

example, an Order Entry system may provide stellar validation,

approval, scheduling and routing functionality, but other than the

defined user and system interfaces, there is no way to employ

these functions.

IT must change these legacy systems to provide a means to tap

into functions, such as order scheduling. Once the function is

delineated, IT can build an adapter that exposes the function as a

service. The purpose of the adapter is to provide an interface to

the outside world that conforms to the protocol all services follow.

The adapter looks like a service to the outside world but

delegates its implementation to the legacy function.

Empowered by Middleware

The primary new technology of SOA is known as the Enterprise

Service Bus (ESB). The ESB is middleware that accomplishes

much of the required magic. Its main job is to locate and execute

technical components to satisfy a request for service.

The ESB helps eliminate barriers that prevented SOA in the past.

The first barrier is connectivity. As simple as it sounds, the ability

to send a request to a service provider and receive the response

was limited by technology and space. In addition, many of the

past connections were implemented by static, point-to-point links.

These links are inflexible, costly and difficult to maintain. By

brokering dynamic connections between the two “endpoints”

regardless of technology and the location of the endpoints, the

ESB brings the equivalent of the telephone grid to the world of

technical components.

It helps to compare an ESB to a telecommunications system. The

telephone grid and the ESB both implement loose coupling,

which reduces to a bare minimum what each endpoint must know

of each other endpoint. The less an endpoint knows, the more it is

independent of change. A telephone caller does not need to

know any information other than a telephone number to make a

call. Similarly, the ESB ensures that the consumer and provider of


Figure 4. The federated enterprise service portfolio holds the services realized by technical components accessed through

an enterprise service bus.

a service know only enough about each other to accomplish the

interface. This enables the underlying service delivery

mechanism to change without having to rewire connections

between consumers and providers. A particular service with five

providers today may have ten tomorrow. The ESB provides a

standardized plug-in environment for the creation, change, and

retirement of service providers, and dynamically links the

consumer to the appropriate provider, keeping both endpoints on

a “need to know” basis.

However, full connectivity does not solve all the problems. Two

individuals connected by telephone, but speaking different

languages, will not communicate. The same is true for technical

components. Differing technology platforms, standards and

development practices isolate components by creating the

equivalent of technical “languages”. To enable communication,

the ESB serves as a universal translator that transforms

messages from the language of the sender to that of the receiver.

Connectivity and language mediation work only if the consumer

of a service can first find the service it needs. All available

services need to be registered and published as available in an

Enterprise Service Portfolio. Using another analogy, the portfolio

is the phone book for SOA. It maintains a timely list of available

services, the supporting profile details of each service, and the

means to address the service (i.e., the phone number) so it can

be used.


The portfolio also provides “yellow page” mechanisms to help

locate an appropriate service based upon desired qualities. The

consumer may want a service that can schedule a shipment with

a specific type of carrier to a specific location. The portfolio

would deliver services that can perform this function and enable

the consumer to pick the most desirable based upon timeliness,

cost, and other factors.

A single portfolio covering the entire enterprise would include

services that are universally shared, but it would also include

services that are of use only to certain communities. A more

useful structure organizes services into smaller portfolios by

community. The resulting federated portfolio is hierarchically

organized to allow communities to use services of limited

generality without diluting the more general portfolio with out-of-

context, inapplicable services. Moreover, the federated portfolio

allows governance of services to be distributed. This divides the

complex governance into smaller pieces and enables each

community to care for the special needs of its local services.

Beyond the ESB and portfolio, SOA encourages technology to

support enterprise data sharing. The objective is to provide a

uniform view of enterprise data that can be used (reused) by all.

This concept started in the early days of database management

systems and most recently continues with data warehouse. A

data warehouse is a processed copy of select portions of

enterprise data. It provides a uniform view but is limited in scope

and timeliness.

Data service technology carries service-orientation to enterprise

data by exposing data services. A data service provides

ubiquitous access to data housed in many types of persistence

mechanisms. Through the use of metadata management, service-

orientation and sophisticated optimization techniques, data

service technology enables uniform access to enterprise data to

match uniform service access provided by the ESB.

A Broad Scope: SOA Involves

the Entire Enterprise

The entire enterprise is covered by the scope of SOA. It affects all

business and technical concerns. Industry approaches such as

enterprise architecture and component based development, as

well as technologies such as process engines, database

engines, rule engines, application servers, etc., are required to

make service-orientation a reality.


SOA relies upon well-founded practices and technology.

Databases will be created, application functions will be

developed and acquired, user interfaces will be crafted and IT

will maintain the infrastructure for disaster recovery, security, fault

tolerance, etc. Going forward, new technologies will advertise

“service enabled” features as key competitive differentiators and

thus strengthen the potential of the approach. As a result, SOA

offers a new way to exploit current technology and inspires

capabilities for future technology.

But SOA includes both the business and technology in its scope.

In so doing it consolidates aspects of the enterprise that need to

work together. Most notable is the gap between business

operations and the IT systems that support them. The infamous

lack of alignment between these adjacent areas of the enterprise

represents 3 key business-oriented problems to be solved by

SOA:

1. IT needs a precise definition/understanding of business

needs. Much work has been done to improve the

communication between experienced business

professionals working in specialties of the business (e.g.

claims management) and the IT professionals who evolve

the supporting infrastructure. Today, business modeling is

used to express formally how an enterprise works in

business terms and with business concepts. These are

mapped to technical models that depict how technology

supports the business concepts. Under SOA, the formal

modeling is not only a representation of the business; in

many ways it is the business. When a business

professional can directly effect business changes by

manipulating a model of the business, the communication

gap with IT becomes much less of an inhibitor.

2. It is easier to experience than to imagine. It is not always

possible to state, upfront, all of the requirements needed

for business process execution. In response, iterative

development methodologies have evolved and blended

with prototyping. These efforts are all driven by IT and

require coordination of IT and business resources to

identify the differences between “as built” and “as

imagined.” SOA defines a paradigm of business-driven

prototyping. Instead of IT working to present a solution

that matches the business vision, the business

professional directly expresses the vision as an

executable business process, with support from IT to

complete the details of implementation.


3. Requirements change while automation solutions are

being developed. The significant advances in iterative

development still require a broad bandwidth of interplay

between business and IT professionals. Requirements,

however, continue to change during this interplay. The

business-driven, model-based capabilities of SOA

improve the time-to-market by reducing the interplay

between the business and IT.

Modeling Manages

Complexity

Top CIOs and business executives use modeling to manage the

complexity of an enterprise. Enterprise-wide visual modeling,

performed with Metastorm ProVision, enables organizations to

improve their performance and competitiveness.

Bringing SOA to the Business User

Metastorm ProVision is the first solution of its kind to answer

industry demand for SOA modeling support. An innovative

solution, Metastorm ProVision is wired “behind the scenes” for

SOA support. Rather than asking business users to adopt a new

technical paradigm, allowing them to create workflows using

Metastorm ProVision‟s acclaimed intuitive interface.

Four significant capabilities within Metastorm ProVision allow for

this superior SOA support:

Preservation of the business analyst's viewpoint, retaining

business terms and not requiring business users to

understand the technical aspects of SOA.

Methods for the technical user to configure execution-

ready business activities so they directly translate into

services.

Auto-completion feature within a service-intelligent user

interface.

Delivery of real-time verification of execution-ready status.

As a result, Metastorm ProVision dramatically reduces the amount

of time and interaction required to transform business processes


into executable functions. Business engineers can take the

execution-ready activities and, at the push a button, produce a

BPEL-equivalent of the model that will reference the services that

implement the process. This provides a preliminary design of the

structure and services, allowing the designer to work through

technical issues such as security, compensation of failures, and

logging.

Modeling is vital to SOA because SOA involves abstraction — the

removal of non-essential information to achieve a succinct, easy

to manage model of reality. SOA, following the lead of MDA

(Model Driven Architecture), uses models to enhance

understanding and to effect direct change. Metastorm ProVision

enables organizations to perform the three types of modeling that

are needed in SOA: strategic, business and technical. The

following sections will discuss aspects of each of them.

Strategic Modeling

To produce change, an enterprise must formally understand how

it works today and how it should work tomorrow. In the early

stages of an SOA program strategic modeling clarifies the

mission, goals, inhibitors, opportunities, etc. and profiles the

enterprise in terms of its capabilities. This form of modeling is

used to analyze the enterprise at a high level and target specific

areas where resources should be applied over time.

The mission of an enterprise states its direction. To accomplish

the mission, the enterprise must achieve its goals. Strategic SOA

maps goals to aspects of the enterprise that are critical to

achieving goals. One such aspect is the capability. The typical

enterprise is armed with dozens of relatively stable high-level

capabilities.


Capabilities depict, at the highest level, what an enterprise can

do. Common capabilities include Inventory Management, Pricing,

Order Processing, Direct Sales and Public Relations. Using

Metastorm ProVision, each capability is mapped to factors such

as related organizational areas, measures, governing rules, data,

and supporting technology. The most distinguished mapping is to

the business processes that comprise the capability. To improve

a capability in support of SOA goals, an enterprise will first turn to

its processes. For example, an enterprise could have goals such

as “increase foreign market penetration” which in turn might

nominate Order Processing as a good candidate for SOA

resources. Order Processing may involve multiple business

processes and be richly described in terms of opportunities,

inhibitors, and influences, as well as substantive factors such as

required data and governing rules. Once nominated at the

strategic level, the Order Processing capability will be analyzed in

detail to determine how it can best support its highest priority

goals.

Business Modeling

Business modeling defines how processes, data, rules, services,

organizations, resources, etc. interact to affect business

operations and maps them to the strategic artifacts they support.

Process improvement (e.g. simulation, analysis, prototyping)

employs the same type of models to prescribe the future and

Figure 5. A business capability profiles enterprise function at the highest level of abstraction linked to the goals it supports, the

processes it includes and a host of supporting artifacts that enrich its definition.


subsequently clarify the gap between the “as is” and the “to be”

states of the enterprise.

Business flow models depict business processes as a network of

activities linked by precedence relationships and driven by

events. Each activity performs a function governed by rules, and

can produce and consume deliverables. A single business flow

will often show the collaboration among various business

participants. Business participants are typically organizations

(within and outside of the enterprise), roles (job functions),

individuals, systems, locations, facilities or even equipment. Each

activity is performed by a participant.

Figure 6. The business flow uses an activity portfolio to define a business process formally in terms of its activities, rules, participating

entities, events, deliverables, and precedent relationships.


Figure 7. The business flow depicts how business activities work together, across organizational boundaries, to accomplish a business process.

Order Entry

System

Manufacturing

Companies

Component

Vendors

Finance

Production

Field

Operations

Pro

du

ct

Submitted

Order

Scheduled

Order

Order

Completed

OrderNo

Ap

pro

ve

d O

rde

rY

es

Rejected Order

No

Priori tized Order

Ye

s

Co

mp

on

en

t P

art

s

Scheduled Order

Product

Shipment

1

Complete

Order

7

Ship Product

6

Build Product

2

Submit Order

4

Schedule Order

5

Ship

Components

3

Approve Credit

G

Expedite

Order?

Credit

Approv ed?

As result, a flow from one activity to another activity performed by

a different participant depicts collaboration among areas within

an organization as well as with external organizations. Figure 7

shows a simple Metastorm ProVision business flow supporting the

Order Processing capability. The business flow model is the main

mechanism for describing how an enterprise functions. This

model has a rich support structure. Each activity requires and

possibly changes data, supports goals, adheres to standards, is

measured, is burdened by problems, etc. The business flow

model is the backbone of a comprehensive definition of the

business process.

Under SOA, business modeling takes a very active role. The

definition of the business process essentially becomes the

business process. This is accomplished by defining reusable

business activities implemented by services. When the business

professional incorporates these execution-ready activities, the

resulting business flow model not only describes the business

process but also can execute services to implement the business

process.


Figure 8. The execution-ready activity is designed to be „wired‟ into a business flow model but carries internal instructions, supplied by IT, for

mapping its inputs and outputs to the (business) service that implements its function.

For example, the activity Schedule Order presents to the

business the ability to schedule an order for processing based

upon supplied criteria. This is the business view. Internally, IT has

worked with the business to enable access to a Schedule service

that can place the current order in the queue for processing and

deliver the results of the scheduling operation. The business

activity encapsulates the details regarding which service is used.

This simplifies the job of the business professional and provides

the flexibility for IT to substitute the hidden service with a

functionally equivalent alternate service in the future without

affecting the logic of the business process.

The execution-ready enterprise activities are maintained in an

activity portfolio. The portfolio is a business mechanism that

profiles each activity in terms of the function performed, required

inputs and produced outputs. It also maintains the tie that maps

to the service that provides the functionality. The portfolio

contains the raw material used by the business professional to

define and refine the business processes. It presents business

activities in business terms and provides mechanisms to help

locate the appropriate activity to meet a business need. A

business professional can now construct executable business

process models by dropping in service-enabled activities and

linking them together according to their required inputs and

outputs.

The service within each activity is able to trigger system

functionality. It will also directly or indirectly operate on enterprise

data. The behavior of the service, whether functional or data

access, is governed by business rules. A business rule can:

Initiate an action – Trigger an event; trigger another rule

Constrain behavior – Prevent an action (e.g. deny credit

approval)

Derive information – Calculate (e.g. a price discount)

Business rules cut across all business services and provide a


uniform mechanism for managing the policies of the business.

When business rules are factored out of services the enterprise

can more quickly institute changes in detailed behavior. For

example, many services deal with tax policies in different locales.

These policies should not be encoded in technical components

but rather exposed to the business as modifiable rules.

With rules and execution-ready activities the business is able to

make fundamental changes in the way it operates. It can add or

remove activities and reroute business flow to change business

process operations quickly. It can also modify business rules to

affect changes in policy.

Technical Modeling

Technical modeling is two-fold—logical and physical. Logical

modeling defines the technical artifacts (e.g. systems,

components, databases, networks) comprising the enterprise

technical infrastructure and maps them to the business artifacts

they realize. It defines technical intent without binding to the

characteristics of any particular technology. As with business

modeling, logical modeling enables the enterprise to achieve a

broader understanding of its technical infrastructure and to more

effectively determine how the infrastructure will evolve. Physical

modeling allows the specification of technical artifacts. It is used

at the engineering level, considering details of the underlying

technology. The primary benefit of physical modeling is to hide or

generalize computable details and to provide a more graphical,

picture-based metaphor for expressing artifact characteristics.

In figure 9, the left side of the Federated Enterprise Service

Portfolio (FESP) is the business view, which includes execution-

ready activities, business services, business rules and many

supporting artifacts. The right side of the FESP is the technical

view. It contains the ESB, the components that realize (technical)

services and the resources required by the components.

Technical service-orientation employs the entire infrastructure of

IT, including technologies such as database, message,

application servers, business process execution, and rule

engines. The components that realize technical services are

implemented across multiple platforms and employ various

paradigms. A component may be anything from a function wired

within a legacy COBOL application to an executable process

invoking external web services. Anything that can provide

functionality and conform to a service interface can be an SOA

technical artifact.


Because of the unlocked potential of legacy components, a key

part of SOA is the visualization of legacy applications and

databases. Legacy modernization tools and techniques demystify

the complex, archaic implementations to expose reusable

functionality. This functionality can be wrapped and adapted to a

service interface. Ideally, the rediscovered functionality is

retooled into a more modern implementation. Technical models

showing modules, database records, parameters, interfaces,

etc., reveal untapped potential in the abstract, and enable IT to

target new service providers.

Although many components can be mined from legacy

applications using tools like Metastorm Integration Manager, a

key technical benefit of SOA is the ability to compose new

services from existing services. Similar to how the business wires

execution-ready activities to create a business process, IT can

build composite services by reusing other services as

components. An Order Validation service, for example, may be

defined to accept an Order and deliver an errata list. This service

could be constructed by composing lower level services:

Product Availability – Ensure the requested products can

be purchased

Customer – Validate the customer information

Credit Approval – Ensure the customer has approval to

purchase

Technical process models choreograph message flows,

decisions and data transformations among component services

Figure 9. Technical models express the mapping of execution-ready activities to enterprise services, and enterprise services to the service components that realize them and the IT infrastructure that hosts the

implementations.


into an executable process that performs the intended function.

Since this choreography can be orchestrated (executed) by a

process execution engine it can be adapted and registered like

any other executable component as a single technical service.

This new service may later be composed into more sophisticated

services.

The ability to treat uniformly anything that can be executed as a

service, coupled with the ability to compose existing services into

a new service, provides tremendous technical potential. IT has a

uniform means to deliver functionality across heterogeneous

platforms, independent of location and available for reuse. The

core SOA technical models center on the definition and

composition of technical services and their supporting

components. Service models define the technical services as

abstract functions, with defined interfaces and quality of service

properties. Each service is minimally mapped to the activities it

supports, the rules it abides by, the data it accesses, the services

it composes or, indirectly, to the technical components that

provide its function. Component models define each component,

its service interface and ties to underlying systems, platform

technologies, and resource artifacts. Over time, new components

will emerge, retire, and transform. It is the job of the technical

models to abstract, visualize and manage the dynamic

environment that delivers enterprise functionality.

In the end, all forms of modeling – strategic, business and

technical – provide the same fundamental benefits. A model

formalizes understanding of some aspect of the enterprise. It

abstracts and thus focuses on the critical properties of interest

while hiding details until they become relevant. Models enhance

our ability to understand and manage complexity and to

communicate essential information to others. Most significant to

SOA, models are leveraged to drive change. Using domain-

specific terms and concepts, models present the relevant

aspects of an enterprise to the agent of change. With Metastorm

ProVision, professionals can affect the change directly via the

model instead of spending time informally communicating the

change to others.

The Power of BPM in an SOA

Environment

After modeling and staging the strategic, business, and technical

aspects of an SOA program with Metastorm ProVision, that

program can be executed with the Metastorm BPM® suite.


Organizations that position BPM as a core component of their

SOA strategies realize more business value from service

enablement as BPM helps optimize the use of the SOA across the

core business processes that most directly impact executives‟

top performance objectives such as:

Increased productivity

Enhanced customer service

Greater competitive advantage

Stronger financial performance

A key differentiator of the Metastorm BPM platform in this regard

is its ability to manage both human-centric and system-centric

processes. The human-centric capabilities of Metastorm BPM

enable the deployment of services to business users in the form

of cohesive, orchestrated business processes synchronized

across the enterprise. Complementing these human-centric

functions, the Metastorm BPM suite offers Metastorm Integration

Manager (MIM), a full-featured integration tool, to handle high-

volume, system-based processes and to leverage even the most

obscure legacy applications.

Organizing Complex Business Function

Requirements

Metastorm removes the complexity of managing access to

multiple types of services—including technical, business

function, and business data services—by applying these services

at the appropriate points in a process. In addition, Metastorm

provides visibility and access to the complete “roundtrip” process

life-cycle, giving organizations the ability to apply SOA concepts

in process design, integration, execution, analysis, and ultimately

the improvement of these strategic processes.

While an organization may have many processes that do truly

stand alone, most mission-critical business processes have

complex data and business function integration requirements.

Traditional integration architectures take several forms, among

them: custom integration code that is replicated across different

integration customers (customers = applications), enterprise

application integration platforms, and message brokers. All of

these approaches are quite complex and exist at a level far

beneath the actual processes and applications that require the

data or the business functions offered by the integration.


Metastorm BPM organizes the services offered in an SOA in the

following manner:

Business Function Services are generally coarse-grained

services that represent a transaction/activity with significance to

the business (for example: creating a customer record, creating

an invoice, or closing an open customer service ticket). Business

function services are usually related to a transaction and require

the planning and control appropriate to the transaction, such as

locking, concurrency, etc. These types of services are

differentiated because of their unique requirements.

Business Data Services provide access to the information

contained in the various applications, systems, and repositories

of the organization in an open but secure fashion, and they

eliminate replication of point-to-point integration between systems

and processes. For example, business data services would

provide a sales order entry process with data about active

customers, available product sets, and current inventory status.

In a well-planned SOA, SQL, host data sources, transactions, and

batch file data sources may be served up by business data

services. Business data services often deal with large, complex

data sets and are often associated with interactive usage when

used in a human process context. For example, browsing a large

list of customers might dictate data services that accommodate

paging, sorting, and filtering capabilities or the ability to combine

asynchronous data manipulation operations.

Technology Services make available fine-grained supporting

functions, offered as part of the platform, such as a function to

create a customer-specific folder in a content management tool.

Other technology services would include single sign on, shared

authorization services, and transaction time-stamping.

Metastorm BPM uses standards-based technologies to

orchestrate the consumption of specific business functions,

business data, and technical service functions within and across

multiple business processes. BPM also provides the ability to

leverage these services throughout the complete lifecycle of each

process, whether the service is invoked as part of a system

action or interactively from a user form. Complementing this is

Metastorm‟s support of a wide array of SOA-enabling

technologies to make process components—including actions,

stages, and user interfaces—available as services, delivered to

consumers via the SOA, whether those consumers are people,

applications, or systems.


Closing Critical Process Gaps

BPM plays a leading role as the process service provider in a

firm‟s SOA, but beyond the technical aspects of this role, BPM

also eliminates the gaps that exist in organizations—gaps

between people, between organizational units, and between

business applications. What differentiates BPM from traditional

workflow is the inclusion of all aspects of the process, as

opposed to a more narrow focus on the movement of documents

and data. BPM technology has focused the attention of

executives on the business processes that make their

organization unique and competitive. As a result, business

processes are increasingly viewed as independent and unifying

assets of the organization.

Metastorm BPM software is specifically designed to close the

gaps across applications and people and create a virtual

“process layer” across the enterprise. This layer supports critical

processes both within the organization as well as external to the

organization, with suppliers and customers.

The visibility that this process layer delivers affords greater insight

into the business and eases the challenge of identifying value-

add services during the modeling and analysis phase of building

an SOA. That visibility also plays an important role in the

execution of services once the SOA is deployed.

Ideal Framework for SOA

In the analysis and modeling phase of process deployment, it is

vital not only to understand the steps and activities that make up

a process but also to identify the various business services and

content required by each process. Metastorm‟s Stage Action

Role (STAR) methodology, designed to align with the BPM

software that will interact with services, clearly identifies how this

information will be used in the process, even capturing the

organizational roles of the people using the information.

The human role in the process is to make decisions using the

information identified, and these decisions result in execution of a

business function. Metastorm‟s STAR methodology allows for the

clear capture of key business functions that need to be executed

in the process. In this way, Metastorm BPM provides the ideal

framework for identifying which systems must be enabled as

services in an SOA to deliver value directly to the business.


When multiple processes are subjected to this analysis there is

an additional benefit. SOAs and services are no longer viewed in

the context of a single process but across multiple processes,

spanning a wide range of business functions and organizational

units. The result is the identification of cross-cutting concerns in

an SOA, highlighting the systems and services required to add

value across the entire organization. This view opens new doors

for value-based analysis and planning business-wide.

Starting with a solid approach to planning and modeling an SOA,

as outlined above, is critical to easing the challenges associated

with deployment.

Provisioning a Wide Variety of Process

Services

From a technical perspective, Metastorm BPM has been

designed based on three simple but significant constructs:

messages, services, and events. These three building blocks are

present at every level of the Metastorm BPM architecture—from

the inner workings of the process management engine and web

server to Metastorm‟s unique ability to provide instant access to a

firm‟s unique business processes.

This architecture makes Metastorm BPM an ideal platform to

provision a variety of process services in an organization‟s SOA.

These services can represent high-level business activities such

as opening a new customer account, or more specific supporting

functions such as adding comments during the review of a

customer‟s annual report. In addition, Metastorm can provision

these services using a variety of technologies, including web

services, .NET assemblies, Java objects, XML messages,

WebSphere MQ messages, mainframe functions, and even

command-line protocols.

As part of designing and deploying an SOA, organizations using

Metastorm BPM quickly view processes as first-class services to

be delivered as part of the services infrastructure. No longer is

business processes locked inside a single packaged application

or even an organization‟s bespoke solution. Processes are

captured, understood, and deployed in a way that enables easy

interaction with other systems and processes, allowing for

coordination across an entire canvas of available business

services.


Advanced Service Integration and

Legacy Control

Another significant consideration in SOA is integration and legacy

control. As part of the Metastorm BPM suite, the Metastorm

Integration Manager (MIM) provides a platform for designing,

executing, monitoring and auditing system-based processes.

When it comes to SOA, customers can leverage MIM to create

services that tie together legacy applications across all major

distributed and mainframe operating systems with new solution

development for seamless process execution across a variety of

platforms and channels.

MIM‟s portfolio of capabilities can transform items like files,

databases and legacy applications into XML-based, message-

driven services. Disparate services can then be orchestrated into

courser grain, higher value business services. These

choreographed business services can be utilized by the

organization and driven in any number of ways, including higher-

level, human-centric business processes. By exposing legacy

assets as services and managing the execution of those services

in key business processes, MIM offers a service-oriented

approach to providing business process integration within the

context of the BPM suite.

MIM also provides three key benefits to the Enterprise Service

Bus (ESB) technology component of an SOA. As a reminder, an

ESB acts as a messaging backbone to facilitate communication

between different services. MIM‟s roles include:

Managed File Transfer – MIM‟s service-oriented, process-

centric managed file transfer capabilities enable data to

be moved across the ESB. This establishes a portfolio of

batch and real-time data integration services for the

organization.

Auditing Subsystem – A complete auditing facility for

tracking, tracing and logging is provided within MIM. This

powerful tool assists organizations in demonstrating they

have developed the business controls required for

compliance with regulatory obligations, such as Sarbanes-

Oxley.


Exception Handling – MIM‟s seamless integration with

Metastorm BPM provides a comprehensive, human-

centric business process management platform for all

forms of exception handling. Because most service-

oriented initiatives are system-based, they cannot provide

solutions when unexpected errors occur. People must get

involved when things go wrong, so the concept of human-

centric exception handling is critical. It‟s estimated that 80

percent of the costs for ongoing operations of integrated

solutions comes from the 20 percent of errors that occur.

Metastorm enables organizations to create rich processes

and resolve these problems quickly, thus keeping costs

down and benefits up.

Conclusion

SOA has great potential to help organizations implement

programs more quickly and cost-effectively in today‟s demanding

business environment. It achieves results that significantly benefit

the enterprise:

Agility – Rapid adaptation to changing market conditions

and internal initiatives

Reuse – Using past work in different contexts and not

reinventing the wheel

Uniformity – Broad-based ability to share regardless of

technology or location

The key to success for SOA is ultimately the value it can deliver to

the business. SOA will have established its foothold when

business professionals gain the ability to control their own

processes and rules directly, as well as adapt to change rapidly

and correctly. Beyond that, SOA delivers a bonus by offering a

real chance for IT to deliver broad-based reuse and component-

based development in a uniform technical environment.

As the leader in EA, BPA and BPM innovation, Metastorm helps

organizations realize business value from SOAs and achieve

Enterprise Process Advantage®—a heightened level of business

performance resulting from increased efficiency, control and

agility across mission-critical processes.

Metastorm ProVision provides the foundation for SOA efforts with

an integrated repository and unsurpassed modeling capabilities

that enable organizations to capture critical components

including strategy, business architecture, data architecture,


application architecture and technology architecture. This

complete enterprise visibility enables critical business and IT

alignment. Building upon the capabilities of Metastorm ProVision,

the Metastorm BPM suite combines the strategic advantages of

business process management with the integration technology

required for SOA to effectively align IT initiatives with the strategic

goals of the business user at every level within the organization.

This powerful synergy of the solutions within the Metastorm

Enterprise platform provides for unmatched SOA support, true

process improvement and greater results for the business.

© Copyright 2009, Metastorm Inc. All rights reserved. Business to the Power of 3,

Enterprise Process Advantage, Metastorm BPM, Metastorm Discovery, Metastorm DNA,

Metastorm Knowledge Exchange, Process Pod, ProVision, and the See.Think.Do image

are either registered trademarks or trademarks of Metastorm Inc. Other product, service

and company names mentioned herein are for identification purposes only and may be

trademarks of their respective owners. 7.15.2009.

The Business of SOA

Documents

Transcript of The Business of SOA