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.

By Glenn Smith, Principal Consultant, Appian , 10/15/2009

www.appian.com