In essence, SOA is an architectural approach that seeks to align business processes with service protocols and the underlying software components and legacy applications that implement them.
So far, so good. Then they go on to say:
Both processes and services need to be carefully coordinated to assure an effective SOA implementation. You can’t really do SOA without a clear model of the business process to be supported.
Not sure that I fully agree with that: you have to have a clear model of your business process before you can implement SOA? Aren’t the underlying services supposed to be reusable even if the business process changes? Isn’t that really the whole point of SOA?
And you can’t link your business processes to your service models without the modeling standards the OMG is developing as part of its Model Driven Architecture® (MDA®).
Oh, I get it now.
They do include a nice diagram showing where the OMG standards fit in one representation of an SOA environment (see the newsletter for the full-size version). You can see where BPMN, BPDM and BPEL fit in, which I talked about in my posts from the BPM Think Tank last week, plus other standards such as SBVR (Semantics of Business Vocabulary and Rules) for business rules.
I also like that they’re platform-independent about this, and that they don’t equate SOA with WS-*.
You can check out the newly-formed OMG SIG on SOA if you want to get involved in discussing this MDA approach to SOA.