SOA and Agile are two approaches that have a hard time to live together. Martin Fowler just wrote about it: http://martinfowler.com/bliki/EvolutionarySOA.html, Jim Webber talked about it on Developer Summit and some other places (http://www.infoq.com/interviews/jim-webber-qcon-london, http://www.expertzone.se/dev07/) and I wrote a piece on it a couple of years ago: "Why SOA is broken" (https://lowendahl.net/showShout.aspx?id=116).

Yesterday we ALT.NET Sweden had an unconference and I facilitated a talk around agile and SOA. The feeling I got from that discussion is in line with what Martin mentions in his post:

"the fundamental question I ask is "is change predictable?" Only if change is predictable is a planned design approach valid. My sense is that if predictability is hard within the context of a single application, it's doubly hard across an enterprise."

The problems with most SOA efforts is that the bussiness- and SO architects often put to much comfort in that their process and message model is "done" and therefor won't need hands on after it left their hands. This is a smell in oh so many ways. First of all, when a bussniess says it's "done" with it's processes, it'll be a done bussiness. Bussiness evolve and change otherwise bussiness die, this was one of the reason for SOA in the first place; to allow for bussiness to change. Secondly, saying that you are done with something as complicated as bussiness processes is like saying that you and the work you do is perfect (if you just where a bit more humble of course ;). There will always be a need for change and that change will flow down to the team that builds the process automation tools, no doubt.

So as Martin concludes I would like to say +1. Bussiness evolve, bussiness processes evolve in an iterative and incrementel fashion, so why shouldn't a complex task as building automation for thoose processes have the possibility to evolve iterative and incrementel as well?