BPM and SOA - how do these concepts relate?

A number of BPM sites are writing about the connection between SOA - Service Oriented Architecture and BPM - Business Process Management.
It pushed me to think about these concepts and how they relate and differ.
Thinking about it, first we need to define what we mean by SOA. SOA seems to come in a number of flavours:

1. SOA: An architectural style.
From this perspective, SOA is a means to describe the complex reality of a system (this can be on a business, application or IT level) as a interrelated network of services.
In my view it is simply a means to reduce complexity, by breaking up the complex world of IT and business in smaller, well, let's be honest, components. These components, such as a business component, is something (people, knowledge, effort, IT, functionality, process, data) that can provide services to other components, and that will often use other components to be able to deliver it's services. With smart composition design rules (coupling, information hiding, etc) elegant architecture patterns can be composed.

Is this architectural style useful for BPM? Well, YES!
When thinking BPM (from a process architecture perspective), when defining processes and units (people, systems) that can execute (parts of) these processes, a good way to model reality helps a lot. And SOA can be a way to describe components that are able to execute parts of a process.
Depending on architecture level, we can see:
- Business components, that are used to execute a process (in reality: a concrete or abstract notion of a department of other organization unit)
- IT components, that are used to either execute parts of processes (straigh through processing), or are supporting a business component (aka people) to perform work in the process.

2. SOA: A technology
For some, SOA is also associated with technology. In this case, we talk about some type of access to functionality and data in systems, preferably on some type of open standards (think service bus/hub, SOA grid)
And for some BPM is a technology that executes processes.
While this is not my direct notion of SOA and BPM, also on this level we can see a relation.
When creating a BPM system, that executes some type of straight through processing (or mixed mode with workflow management), well, you will need services to call, as automated steps in the proces execution layer. You can develop this steps and supporting components in an adhoc fashion, but in the end it will be better to have a uniform integration strategy. SOA with open standards, that is.

Some points of view:
- When you start with a BPM tool, and want to create services to be able to perform straight through processing, you are forced to do SOA.... And soon after that, you will need SOA governance (how to decide which services are needed).
Vice versa - if you want to build a SOA based IT landscape, for a while you can work on a architecture that does not explicitely talk about proces. You might get away with a portal that uses services. Or systems that talk ot eachother p2p or eda or messagebased or subscription based, through "services".
But as soon as you want to start using SOA infrastructures in a more business oriented way, the first word that will fall is business process.... and you're back at BPM: a way to think about what services you need....