Services vs business processes == OO vs procedural?

A while back I gave a presentation at one of ObjectSharp's SMART events on "Bridging SOA & BPM" (http://www.objectsharp.com/ttdinvitation/invite070510.htm). The slides for the presentation can be found here: http://www.objectsharp.com/cs/files/folders/68276/download.aspx. One of the things I thought about saying during that presentation was that the question of whether to approach an enterprise architecture from a "services first" (i.e. SOA) perspective or from a "business processes first" (i.e. BPM) perspective is analogous to the question of whether one should approach application design from an "object-oriented perspective" or a "procedural perspective".

Now, before I elaborate on that, I'll just say that I chose to leave it out of the presentation because I view it as something that could be easily misunderstood. In saying this I am not saying that SOA is anything like OO. In fact, in my experience, the single greatest impediment to successful SOA adoption is getting people to let go of the OO mindset they have developed over the past 20 to 30 years. To be successful at SOA you have to "let go of your objects" and think more in terms of (business) documents and document exchanges. Many of the web service development tools have contibuted to this problem by making it so easy to turn your objects into services simply through the annotation of the appropriate attributes. Services should be thought of as having well-defined boundaries and, as such, stepping across those boundaries should never be taken as "lightly" as a call on an object residing in the same address space as the caller. Instead, invoking a service should be viewed more like what happens when you apply for a passport: you send off a self-contained application form (or document) and it is processed asynchronously by the receiving service. This notion of self-containment is important and is often lacking; i.e. each document in an exchange must contain the complete context for the request to be processed.

Furthermore, objects typically have an interesting life-cycle whereas services don't; think of services as simply being out there on the network receiving request messages, processing them, and sending out response messages or request messages to other services. The individual handling of a given request may have an interesting life-cycle but not the service itself.

Returning to my analogy, the key point that I am trying to make is that when looking at how things get done inside an enterprise, one can view it from a process-oriented perspective (which is analogous to looking at the software system from a procedural perspective) or they can view their assets as a set of self-contained resources and/or processes that systematically structures the various business capabilities the business can provide (which is analogous to viewing the software system from an object perspective).

Using documents as the input/output of self-contained business processes/capabilities goes hand in hand with organizing those business capabilities into discrete, felxible, self-contained (i.e. autonomous) "business services". In this view of things, the internal logic of the business process is hidden, or encapsulated if you will, and the only visible "interface" to the business service/process is the documents that can be exchanged and how those document exchanges are choreographed. That is, from a SOA perspective, internal process (or orchestration) logic should be hidden inside a service boundary and the emphasis instead must be placed on the documents being exchanged, their hopefully standardized syntax or format, their shared meaning, and the "business protocols" governing how they are exchanged.