Why SOA Needs BPM

Untitled Document

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 independently.

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 goals.

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 actors.

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 context.

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 priorities.

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 enterprise systems.

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 glenn.smith@appian.com.

More by Glenn Smith