By Glenn Smith, Principal Consultant, Appian
Editor's note: Our SOA in Action virtual conference is only two weeks away! Don't miss out! See the agenda here.
Recently there have been a number of articles written about the relationship
between SOA and BPM. Some take a positive viewpoint and emphasize the potential
synergies between them. Others are more negative, focusing on tensions between
the two camps.
Both sides make some good points, but neither addresses the most fundamental
aspect of the relationship, which is dependency. BPM can succeed, albeit more
expensively, without SOA, but without BPM SOA is only an internal technology
initiative which does not directly address any business problem.
To explain this last statement, let's first review what SOA and BPM are, what
value they provide to the enterprise and how they relate to each other.
Proponents of both technologies make similar claims about providing greater
application agility and shorter development times, and both technologies often
seek to become the dominant application development methodology. Both claim
to reduce traditional programming by assembling solutions from components rather
than building from scratch. To a large degree, each can deliver on these promises
SOA is an architectural style for developing distributed systems. It is not
a specific technology, but can be applied to many technologies. It encourages
loose coupling of components and enables flexibility. Individual services can
be modified with no impact on the consumers of those services. Services support
reuse, and can help preserve and extend the value stored in legacy systems by
making their capabilities more widely available.
Services provide stable interface definitions, eliminating the need for consumers
to understand the implementation details and isolating them from internal implementation
changes. Services are intended to be reused in multiple contexts and applications,
but to achieve that reuse, they must provide granular units of functionality.
Therefore, a service by itself should never solve a business problem. Services
are building blocks which require assembly and coordination to achieve business
All of these are good ideas which allow IT to be more responsive, but the only
value that they bring to the business is reduced cost and time for IT development.
In other words, SOA is fundamentally an internal IT initiative. For this reason,
pure SOA approaches often fail to deliver value, as they lack connection to
current business needs. SOA teams are almost exclusively composed of technology
people. At the executive level, SOA is viewed as tactical, not strategic.
BPM on the other hand provides the bridge between business goals and IT solutions.
Today, most successful organizations think and organize around a relatively
small number of core business processes which define their value proposition
to their customers.
BPM suites provide a platform for directly implementing these processes in
terms that business users understand. They provide for modeling, simulation,
execution, measurement, monitoring and most importantly, continuous improvement
of the core business processes. BPM brings together and coordinates the activities
and decision making of people with the data and transactions of systems.
A BPM process is the technical implementation of one of the core business processes
from the external stimulus through to delivery to the customer. BPM is the implementation
of an organization's strategy. BPM project teams are typically dominated by
business people, with technology in a supporting role.
Having established the roles of SOA and BPM in the organization, we can now
consider how they should relate. SOA provides services, discrete reusable fine-grained
units of system functionality. It exposes them to all consumers in standard
ways which can be accessed from many different computing environments.
A business process, on the other hand, consists of a sequence of tasks, some
automated and others performed by people. The role of the BPM system is to coordinate
and monitor the performance of the process as a whole, including the individual
tasks. It does not perform the tasks; it orchestrates their performance by other
This separation of control and execution is necessary to avoid BPM becoming
just another monolithic application. SOA is clearly the best current architecture
for execution of the automated tasks which interface with external resources.
Prior to the emergence of SOA standards and tools, BPM projects had to develop
custom interfaces for each integration. The loose coupling and standards-based
interfaces provided by SOA allow BPM to achieve the promised organizational
agility across both the systems integration level and human-centric tasks. All
modern BPM systems provide facilities for invoking services and for exposing
processes as services. It is this coordination of services in the context of
a larger business purpose that makes them valuable to the organization.
Combining SOA and BPM in a single project exposes the conflicts noted above
between the cultures of the two camps. This does not need to be a risk factor
however, since the loose coupling of good SOA implementations limits the required
interactions. The teams can operate largely separately.
The business, through the BPM team, provides requirements and funding to the
SOA team. The funding of SOA through specific BPM projects guarantees the alignment
of SOA with the larger business goals. The responsibility for delivering business
value lies with the BPM team, not the SOA team. The SOA team delivers the services
to the BPM team, and also announces their availability to other projects.
Corporate governance defines the set of policies, standards and procedures
which constrain the behavior of the corporation to protect the interests of
all stakeholders. Within a corporation, individual functions, including IT,
will have more specific governance policies, standards and procedures whose
purpose is to direct that organization within the broader corporate governance
Common topics of IT governance include data integrity and security, product
lifecycle management, data retention and backup. What is often missing are procedures
to assure that IT initiatives, such as SOA, are properly aligned with the business
Using the BPM projects to drive the SOA functionality ensures that the SOA
projects address business needs. Without this business focus, SOA initiatives
can satisfy all IT governance rules, but fail to meet the larger corporate goals.
BPM and SOA are clearly complimentary technologies. SOA needs the service coordination
provided by BPM in order to deliver real value to the business. BPM needs SOA
to deliver business-user access to the data and functionality housed in other
Furthermore, exposing processes as services makes them widely available and
allows composite processes. Any BPM team working without support of an SOA team
should demand the formation of one, and any SOA initiative not driven by BPM
will be hard-pressed to ensure that the services they deliver are aligned with
initiatives supportive of the overall business strategy. Combined, BPM and SOA
can deliver far more value than either can alone.
About the Author
Glenn Smith is a Principal Consultant with Appian. He has more than 20 years of software development experience including more than 10 years implementing enterprise BPM solutions. He can be contacted at email@example.com.