"SOA is an architectural style the recognizes services (functionality representing process steps) as components."Jack Van HoofEmphasis mine. But I'm willing to give Jack the benefit of the doubt as there are two ways of reading that. The less charitable reading is the one that was jumped on someone talking about CRM (quell surprise)
"Let me start by defining that a service is a specific business process step that can be composed and reused in different business processes."Kjell-Sverre Jerijærvi
Now this really does leave no room for maneuver, and it is completely and utterly wrong. This is one of the big challenges of BPM and SOA in that if you start with BPM, which is about co-ordinating steps, then suddenly every service looks like a step. I've seen this problem on several occasions now, and heard it repeated by many others so it looks to be pretty endemic in BPM driven solutions.
To be 100% crystal clear. If you are doing BPM and then just saying "step = service" then you are doing VISUAL Cobol and replacing function calls with service. The fact that you are using WS-* or XML does not make these elements services. As the SOA-RM says "A service is a mechanism to enable access to one or more capabilities", so it is possible for it to be a single capability, but that is certainly not the only, or indeed the most likely, number of capabilities in a service.
BPM driven SOA tends to make bad SOA as it is driven from a procedural and process view, has poor separation of concerns and is mostly all about driving things from the technology perspective.
SOA makes great BPM, BPM makes crappy SOA.