BPM and SOA: Better Together.

Jasmine Noel

Executive Summary
Enterprise competitive and cost pressures are creating the need to rapidly adapt and
streamline business processes to create new business value or increase operational
efficiency. To that end, enterprise processes are becoming increasingly explicit and
business process management (BPM) is evolving from a paper-based diagramming tool
to a comprehensive solution that models, monitors, simulates, and redesigns processes for
competitive improvement. The endgame of BPM is unprecedented process flexibility –
where workflows (both human and automated) can be determined in real-time by the
events or outcomes within the process. This helps allow the business to act appropriately
and competitively regardless of the situation.

For this endgame to happen, processes must become independent of specific information
resources and specific task automation applications. The integration technology must
loosely couple the applications and resources that make up the process, otherwise the
logic of a process will get hard-coded into a particular technology platform, which may
be expensive to change and therefore defeat the entire purpose of BPM. This is where
standards-based service oriented architecture (SOA) comes in. An SOA provides the
technical ability to create that process independence. SOA standards, such as Web
Services, make information resources and task automation applications available yet
loosely integrated for process designers to use and reuse at will. Thus processes modeled
with BPM tools can be rapidly implemented in production via SOA infrastructure.

Together BPM and SOA facilitate the next phase of business process evolution from
merely “automated” to “managed flexibility.” Thus business automation will no longer
be about hard-coding a function to be repeated infinitely. Automation will be about
creating services reusable in many different ways in multiple processes that can be
continuously improved. This helps allow enterprises to achieve dramatic improvements
in market capture, cost effectiveness and profitability.

This paper explores the relationship between BPM and SOA in creating business agility.
It outlines how solution suites such as IBM’s Process Integration suite narrow the gap
between sophisticated process modeling and actual enterprise implementation.

© Copyright IBM Corporation 2005 All Rights Reserved 1

BPM is the future for enterprises
The business need for process management is clear. Streamlined, automated business
processes can help deliver huge gains in organizational and cost productivity. Flexible,
event-driven business processes often exploit evolving opportunities in the marketplace.
Thus the holy grail for enterprises from the smallest corner business to the largest
multinational is to maximize both automation and flexibility in the processes that create
corporate value. This can help the enterprise be both competitively agile and cost
efficient.

To that end the business world has spent the last 30 years becoming more process aware.
Enterprises have learned how to document and map their processes, developed analysis
techniques to identify bottlenecks and unnecessary steps, and developed process maturity
models to document quality control and performance improvements. All of this activity
has helped to increase executive awareness of how their business actually operates in a
complex world of interdependent companies. It also helped companies understand the
difference between core competencies, value-added processes and utility processes.
Progress has been made to improve corporate competitiveness through improved process
management. Indeed the market for business process management (BPM) tools is
expected to reach $3 billion by 2009, according to IDC1.

Yet the global marketplace is not static and today’s business trends demand the continued
evolution of business process management. Business cycle slowdowns require
companies to examine and streamline their business processes to help them save time and
money. Whether it’s the ability to mass produce custom computers, cars or shoes or the
ability to rapidly coordinate supply-delivery logistics for an unexpected event or
corporate merge, enterprises must have more flexibility in how their processes create
business value. Many consider the current preponderance of niche marketing, rapid
customization of product design and manufacturing through just-in-time systems to be
the death-knell of “one-size-fits-all” products and services. Thus it is no surprise that
today’s business thinking is rife with continuous improvement, task definition based on
real-time collaboration, and modeling decision making for unexpected events. Instead of
creating corporate chaos, all of these business trends are really pushing enterprise
processes away from traditional notions of static automation and towards flexible
automation where real-time process adaptations are part of normal, daily business
operations (Figure 1). The endgame of BPM is unprecedented process flexibility – where
process flows can be determined in real-time by the outcome of a specific task or
notification of specific events or the recognition of an emerging economic or market
trend. The future lies in being able to adapt core value-added processes with
unprecedented speed, allowing companies to act appropriately and competitively
regardless of the situation.

1
Source: IDC 2005 Software Market Forecaster database, May 2005

© Copyright IBM Corporation 2005 All Rights Reserved 2

 Static: Automate a function once, repeat forever

Flexible: Automate a service once, reuse service in different ways

Process A Process B

Figure 1: Static automation vs flexible automation

Today’s BPM Suites Forge Ahead

Business process tools began as a way to more easily diagram and document enterprise
processes. Most enterprises have used diagramming tools such as Visio to create
diagrams to gain initial understanding of their current process flows. Process diagrams
alone have limited value. Once created, the diagrams may be difficult to change, may not
be easily actively mapped against actual business metrics, and may not simulate how
process changes will affect performance. Today’s BPM suites are evolving to automate
the modeling, monitoring and redesign of complex, collaborative processes to help
achieve competitive improvement. For example, IBM’s Process Integration solution is
comprised of monitoring tools, modeling tools, business connectivity tools and process
integration tools (Figure 2).

Beyond simply creating process flow diagrams, today’s BPM suites contain sophisticated
modeling capabilities. For example, IBM® WebSphere® Business Modeler V6.0 allows
business managers to design and simulate processes. It is designed to model:
• Key process progress and performance metrics and dynamically link them to the
associated process map
• Historical data such as typical volumes
• Organizational roles, collaboration between those roles, personnel skills
• Business functions automated by specific applications or services
• Business rules and external corporate relationships
• Complex timing, event-driven sequencing and sub-process dependencies.

The ability to represent the complexity of real-world business communication,

collaboration and available personnel and computing resources is the first step in freeing
business processes from being carved in stone. IBM simplified the modeling interfaces
with “drag and drop” business process modeling, providing a structured environment that
allows easier participation in business process design and making it easier to incorporate
changes to an existing model, generally without the need for development resources.
New processes can be modeled by combining existing processes or components in new

© Copyright IBM Corporation 2005 All Rights Reserved 3

ways and/or modeling new functions or communications to an existing process. Process
reuse becomes a reality.

Enterprises already know the key progress and performance metrics for their core
processes. The benefit of today’s BPM suites is mapping these key metrics within the
context of the entire set of processes. For example, WebSphere Business Monitor V6.0
allows users to receive real-time information about their processes in a graphical business
dashboard view, thus permitting line of business managers to monitor the health of a
particular process at any time. Users can set up performance thresholds and when
performance drops, they will receive alerts. IBM’s solution also maintains historical
performance information allowing current patterns to be analyzed against historical
baselines. Thus business managers have an entirely new level of visibility into the actual
operation of their business. It becomes much easier to identify problem areas.

The combination of robust modeling and real-time data collection is intended to

dramatically increase the accuracy of simulations of changes to the process model. For
example, IBM WebSphere Business Modeler simulation and analysis allows analysts to
“run” the process with real business constraints, allowing a company to obtain valuable
business performance information. Thus business analysts can quickly model multiple
“what-if” scenarios to help them determine which process changes will create the most
positive impact. Enterprises can introduce incremental changes in a controlled manner to
help improve overall efficiency. This changes process reengineering from a single
massive project that is usually difficult for an organization to absorb all at once to a
continuous improvement effort where smaller organizational changes can be more easily
implemented over time. In other words, the advancement of BPM suites has taken
enterprise processes from a paper-based diagram to a usable model.

Model IBM WebSphere

Monitor
• Complex Business Monitor
• Real-time data
scenarios
• Event handling
• Ease of use

Redesign
• Bottleneck
IBM WebSphere
identification
Business Modeler
• What-if
simulation

Figure 2: Continuous business process improvement

Connecting Process Models with Automation Reality

Today the leap from model to reality is across a huge chasm. All of these brilliantly
designed and continuously improved process models must be implemented in the real
world by real employees interacting with real software applications which must be
integrated with real integration platforms. For BPM to be successful and valuable to the

© Copyright IBM Corporation 2005 All Rights Reserved 4

enterprise, the speed and agility of IT organizations implementing and integrating the
process automation components must match the speed and agility of business analysts
redesigning the process. This implementation speed and agility can only occur if the
processes implementation and integration can become independent of specific
information resources and specific automation applications. Without this implementation
and integration independence, the process model will likely become hard-coded into a
particular technology platform and may be expensive and time consuming to change,
which defeats the entire purpose of BPM.

One reason this hard-coding occurs is that enterprise computing environments have been
designed and built along traditional, static automation theory. Traditionally, process
automation is achieved by finding a repeatable business function and building a specific
computing application around it to eliminate errors, improve task completion times etc.
A business function could be anything from transaction processing to decision support
analysis to resource planning. Applications would capture the logic of this individual
business function and design specific data structures associated with that function and
create a single, tangible software entity. This tangible entity historically has been
incredibly difficult to change because of time, effort and expense of rearchitecting and
recoding the software from the ground up. Given this scenario, automation worked best
if business functions and processes did not change because the cost in time and money
simply was not worth it.

However, as discussed earlier, this inflexibility now threatens the competitiveness of

many businesses. Thus, software development as a whole has been evolving to improve
the flexibility of business applications. The most recent evolution and broad acceptance
of Java™ 2 Platform, Enterprise Edition (J2EE) standards and application server
platforms dramatically simplified the development of new applications. Instead of
designing an entire application as a monolithic entity, J2EE platforms provided the basic
application structures in a pre-built fashion. This freed developers to focus on only the
value-added portions of the applications. Studies have shown that the rate of new
application deployment has shrunk from years to months and some aggressive enterprises
now have the ability to affect application changes on a weekly basis.2

Yet regardless of this increased application flexibility, many of these applications are still
individually considered and designed with little thought of communicating with other
applications. Similarly there is sometimes little consideration of how people
communicate with the application and transform the application’s output to perform their
process tasks or make a decision. Thus to implement a process one must physically
integrate these applications to provide the required communication.

Communication is the technical foundation of process execution – communication

between applications, communication between applications and human decision makers,
communication between human team members. Much of the struggle to implement new

2
“The State of J2EE Application Management: Analysis of 2003 Benchmark Survey” and “The State of
J2EE Application Management: Analysis of 2005 Benchmark Survey” Ptak, Noel & Associates

© Copyright IBM Corporation 2005 All Rights Reserved 5

or redesigned process models in the real world depends on how difficult it is to build and
change communication between existing and planned applications.

There has been no standard way to formalize those communication links between the
individually created applications. Therefore the communication between applications,
and between applications and users, is being hard-coded into separate monolithic
software entities. The result is integration spaghetti that is highly dependent on the
interfaces and data structures of the applications being integrated (Figure 3). This tight
coupling means that changing one of the applications often requires changing the
integration solution as well. Something as simple as a location dependency can be
hardwired into a tightly coupled application integration solution making it difficult to
move and consolidate applications as many enterprises do to help lower operational costs.
Tight coupling generally also means that if the process is changed, new integration links
between different applications must be built. In this scenario, process independence and
flexibility depends on the sophistication of the integrator and rigor with which best
practices are followed.

ERP Database

Mainframe

Financials CRM
®
UNIX

Java .Net

Business process changes Every change requires a change in the

integration technology
• Slows down business
• Increases operational cost
Application implementation changes

Figure 3: Tightly coupled integration spaghetti cannot rapidly adapt to change

This situation is complicated by the fact that there are several different integration
technologies to choose from, including distributed computing remote procedure calls,
object request brokers, message-oriented middleware, enterprise application integration
(EAI) products, and electronic data interchange (EDI) systems. The larger the enterprise,
the more likely it has implemented many or all of these different integration technologies.
Even if an enterprise standardized on a particular integration technology, the problem is
not resolved because enterprises themselves are not static entities. Companies merge,

© Copyright IBM Corporation 2005 All Rights Reserved 6

competitors are acquired, business units are divested, partnerships are formed and
dissolved. Without common standards to facilitate application communication,
companies may quickly become mired in efforts to create custom integration pipes
between different corporate systems. How can an enterprise hope to implement the
flexible processes they have modeled if it takes six to twelve months to make changes in
the integration technology between disparate enterprise systems and applications?

Just as business process management capabilities needed to evolve over time to add
flexibility to process design, so too do application integration systems need to evolve to
automate the new flexible processes in the real world. This integration evolution requires
the ability to create independence between process and service implementation, to
remove the tight coupling between a specific integration technology and individual
business applications. This is where standards-based Service Oriented Architecture
(SOA) comes in. SOA provides the technical ability to create that process-
implementation independence.

SOA augments BPM

The goal of SOA is to expose an organization's computing assets as reusable services that
can communicate and integrate more readily. The goal is to eliminate the integration
spaghetti that exists in most enterprises today. An SOA provides a common
communication framework to organize and describe capabilities provided, usage policies
and service provider locations without exposing the details of how the provider is
implemented. It is a systematic approach to integrating existing applications and
developing future ones. Under this architecture, the software designer assumes that the
application will be integrated, that a common way to share different types of information
and transactions between applications exists, and that there is a common information bus
to transport that information between applications.

SOA’s are also a tool for designing business processes. Application services can be
combined to deliver new, composite business functions or processes. Similarly a single
software service can be reused within the context of multiple business processes. Thus,
SOA can be viewed as a set of design principals that can be applied to the design of both
computing assets and process assets. Since the design approach to both computing
services and process is similar, SOA provides a common language for business analysts
and IT developers which can potentially close the gapping chasm between them.
Business processes, functions and data may be considered and designed simultaneously
due to broad access to applications and databases.

A key aspect of implementing an SOA is to provide a loosely coupled integration

platform that will allow specific application instances to change and evolve without
affecting the core integration technology itself. Similarly process modifications that
require different applications to communicate should not affect the core integration
technology itself nor should they alter the application instances that are part of the
environment.

© Copyright IBM Corporation 2005 All Rights Reserved 7

 ®
ERP app Database zOS app Java app

SOA Integration

®
Financials CRM app .Net app UNIX app

Business process changes SOA integration minimizes the

effects of change on the environment
resulting in:
• Faster process implementation
Application implementation changes • Lower operational cost

Figure 4: Loosely coupled integration can rapidly adapt to changes

Creating this process/service independence helps facilitate the best alignment between
business process modeling and actual enterprise implementation (Figure 5). New and
changed processes modeled in the BPM solution may be implemented in the enterprise
infrastructure more rapidly because the SOA solution decouples the designed process
from the specific implementation of particular applications that communicate only
through a specific integration solution.

BPM models, simulates and

redesigns processes
Designed processes
Monitors
are implemented with
performance for
SOA infrastructure
improvement
SOA infrastructure orchestrates
analysis
business processes and
mediates service providers

Service changes should not impact processes

Process changes reuse various services as
needed

Services are exposed to be

used in various processes

Figure 5: Relationship between BPM and SOA

As an example let us examine how IBM’s Process Integration suite helps narrows the gap
between sophisticated process modeling and actual enterprise implementation (see Figure

© Copyright IBM Corporation 2005 All Rights Reserved 8

6). WebSphere Integration Developer imports process models designed and optimized in
WebSphere Business Modeler. Users actually implement the model by drag-and-drop
from a list of existing SOA services onto the imported model.3 The solution then
automatically creates the Java-based code that will orchestrate communication between
the service components as specified by the process model. WebSphere Integration
Developer’s GUI is designed to permit non-Java programmers to generate the necessary
software for process integration according to generally accepted implementation best
practices. The orchestration code is then deployed onto WebSphere Process Server in the
production environment to manage service-to-service communication.4

The key to this scenario is that SOA ideals are incorporated at every stage and in every
product. There is separation between actual process integration and specific information
resources and automation applications. As changes to the process model are introduced,
WebSphere Integration Developer creates new integration paths that are deployed on
WebSphere Process Server. These integration paths should not affect the service
implementation. Similarly, changes to individual services implementations should not
affect how WebSphere Process Server coordinates the processes. In other words, IBM’s
solution is designed to provide loosely coupled integration in a standards-based way.

IBM WebSphere
Business Modeler
IBM WebSphere
IBM WebSphere Integration
Business Monitor BPM models, simulates and Developer
redesigns processes
Designed processes
Monitors
are implemented with
performance for
SOA infrastructure
improvement
SOA infrastructure orchestrates
analysis
business processes and
mediates service providers
IBM WebSphere
Service changes should not impact processes
Process Server
Process changes reuse various services as
needed

Services are exposed via Web

Services to be used in various
processes

Figure 6: IBM WebSphere Business Process Management Solutions, a practical implementation of

the BPM-SOA relationship

3
WebSphere Integration Developer can also be used in conjunction with Rational® development tools to
create new SOA services specified by the process model.
4
The full process model is also supported by and works with WebSphere MQ Workflow which manages
the people-to-people and people-to-service communication and WebSphere Partner Gateway which
manages the connection with external partners by transforming data among ROD, EDI and XML formats.

© Copyright IBM Corporation 2005 All Rights Reserved 9

Just as new object-oriented development paradigms unleashed the power of code reuse,
SOAs allow business analysts and IT architects to access the power of reusing automated
business services. Once process designers have direct access to reusable automated
business services, their focus can shift to making more sophisticated use of event driven
process architectures and continuous improvement of those processes.

It is anticipated that the combination of online business services automatically collecting

and reporting near-real-time data and the ability to more accurately model event triggers
will take just-in-time business intelligence and decision making to new levels. For
example, a process can be designed such that the automated monitoring system notifies
the business manager when particular transaction thresholds dip below a predefined level.
The manager then uses an analysis application to determine whether to trigger another
automated service that pushes promotional advertising to website visitors. In this way,
the business manager has a just-in-time process to shape demand for a particular product-
line. This process can be rapidly implemented because the transaction system,
monitoring system, analysis application and promotional advertising application can all
communicate the specific situational context via the loosely coupled integration afforded
by SOA infrastructure.

More importantly, this process can be modified on a regular basis by combining different
automated services. When enterprises have the ability to focus on sophisticated use of
automated services, business flexibility and competitiveness may improve without
dramatically increasing incremental costs of making frequent process changes.

Widely accepted standards make enterprise-wide SOAs a reality

SOAs, as a design approach, can be implemented with virtually any existing integration
technology. Indeed several enterprises have made forays with service oriented
approaches using object brokers, frameworks such as CORBA, and message oriented
middleware. The problem with these implementations is that not every application
vendor or internally-developed application is implemented in a specific integration
technology. Without wide-spread adoption of standard integration protocols, any SOA
may be doomed to be limited in scope. With limited scope comes the need to build
integration links between the different SOA implementations, and enterprises may end up
where they began – with supporting spaghetti links. Quite simply, the standards and
protocols must be ubiquitous for SOAs to facilitate the loosely coupled integration
software support across departmental and enterprise boundaries.

Widely adopted standards such as Web Services provide the opportunity to truly create
an enterprise-wide SOA for two reasons. First, implementation and location
dependencies can be removed because the only requirement for communication is that the
interface remains stable and each endpoint application understands Web Services
standards. This understanding allows each application to send requests to the appropriate
resources and interpret the response. It also allows software vendors to automate the
creation of those application requests, as IBM has done with WebSphere Integration
Developer.

© Copyright IBM Corporation 2005 All Rights Reserved 10

Second, most software vendors already support or plan to support Web Services
standards and protocols. This near universal standards support means that regardless of
the packaged applications, application development platform, or integration technologies
in use today enterprises start using these software resources as services with loosely
coupled integration. Widely accepted standards such as Web Services can make existing
information resources and existing automation applications available for a process
designer to use and reuse at will in an SOA environment. For example, processes
implemented with IBM WebSphere Integration Developer can include a Web Services
compliant service, regardless of the vendor technology used to implement the service.
Many enterprises have invested too much in older application and integration
technologies simply to throw them out and start anew. This evolutionary approach is a
realistic option for many enterprises to adopt SOA over time.

Better together
Together BPM and SOA help facilitate the next phase of business process evolution –
going from merely automating repeatable processes to flexible automation of dynamic
processes. This evolution is occurring because enterprises must compete more
effectively by adapting to market changes faster, improving efficiency continuously and
streamlining collaboration across traditionally siloed departments. Modern BPM
solutions, such as IBM WebSphere Business Modeler and Business Monitor, have helped
to dramatically simplify the modeling, monitoring and redesign of extremely complex
processes containing automated functions and personnel decision making. These BPM
solutions make process models living representations of how organizations operate to
deliver value and how organizational operations can change to help increase that value.

Making those value changes to processes a reality requires integration between existing
and future applications that automate specific business functions. Automation only
becomes flexible if it can be reused and reintegrated in a dynamic manner. A standards-
based SOA infrastructure is designed to deliver the automation flexibility and Web
Services is designed to provide the technology standards to make dynamic integration a
reality across departmental and enterprise boundaries. Solutions such as IBM
WebSphere Integration Developer and Process Server help simplify the transition from
process model to actual implementation by creating an SOA infrastructure that provides
integration flexibility.

SOA assumes that IT portfolio items will change over time. SOA infrastructure assumes
that business processes dictating how and when those items will be used and
communicate with each other will change over time. This process independence from
how specific automation components are implemented helps make technology resources
as flexible as the process models provided by the BPM solution. Enterprises may then
fully merge process improvement efforts with technology resource management. When
both are done together, enterprises may achieve dramatic improvements in market
capture, cost effectiveness and profitability.

© Copyright IBM Corporation 2005 All Rights Reserved 11

About the Author

Jasmine Noel is a founder of Ptak, Noel & Associates, an independent analyst and
consulting firm that works with clients to identify, understand and respond to the
implications of today’s trends and innovations on the future of IT Management. Noel is a
recognized expert in infrastructure management and is regularly quoted in publications
such as NetworkWorld, eWeek, InformationWeek, and InfoWorld. She also has
contributed articles to several leading publications on various IT management topics.
Noel served previously as director of systems and applications management at Hurwitz
Group, where she formulated and managed the company’s research agenda. She was also
a senior analyst at D.H. Brown Associates, where her responsibilities included
technology trend analysis in the network and systems management space. Noel holds a
bachelor of science from the Massachusetts Institute of Technology and a master of
science from the University of Southern California.

[email protected]

IBM, WebSphere, Rational, and z/OS are registered trademarks of International Business
Machines Corporation in the United States, other countries or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Other company, product or service names may be trademarks or service marks of others.

This publication was produced in the United States. IBM may not offer the products,
services or features discussed in this document in other countries, and the information
may be subject to change without notice. Consult your local IBM business contact for
information on the product or services available in your area.

This information could include technical inaccuracies or typographical errors.

© Copyright IBM Corporation 2005 All Rights Reserved 12