Surfacing SOA by leveraging composite applications

At the Microsoft Architects dinner in Wellington, Richard Hook gave us some hope that SOA and BPM may be accessible through the familiar MS Office. With a highly professional borrow from The Devil Wears Prada, perhaps the ultimate in product placement movies, Richard showed how workflow could be done.
Unfortunately, we do not seem to be at the stage where development of business process is a natural part of doing the business. So the Miranda, Andy, Emily and Nigel roles in this brave new world would still be chained to a business process designed and built by some super business analyst, developer, implementation team.
A lesson that could have been taken from the movie itself is that the people who do the job are the key part of a successful business process. Empowering them to develop or extend the processes that they are involved in is essential to avoid missing large chunks of what actually goes on in a business. I suggest that offering them a Visual Studio-like workbench is not going to be the answer and neither are we likely to spawn enough process development experts for it to successfully occur in the background. In the real world, the people at the sharp end of the business are innovating all the time. This can be seen in the unhappy state of spreadsheets and Access databases dotted around shared filestore or "C: drives" in government and major businesses. The data in these repositories is essentially hidden from management dashboards and reporting tools but is arguably the very data that demonstrates how the business is operating.
After all the standards work done in expressing business process (BPMN, BPEL ...), the means of changing a bit of XML that represents the executing process does not seem a big ask.
Of course there is a fairly entrenched IT world out there with waterfall development, change control and other reasons for not doing things. It is hard enough to get the idea across that the business analysts might work with the same toolset as the developers to shorten the solution development process.
Certainly, if an organisation is wedded to MS Office, it is reasonable to take on all it offers as SOA componentry at the much neglected user interface layer but for the looser arrangements of the Office 2.0 world with a process execution engine may be a viable alternative for developing dynamic business processes where change can be effected at the shopfloor rather than in the ivory tower of IT or process improvement departments.