Brenda posted about the compatibility of SOA and Agile, comparing them to apples and oranges. I'm not sure of the best metaphor to use, but in my opinion they're undoubtedly compatible methodologies.
It's human nature to want to 'waterfall' processes. From architecture to software design and development. EA, SOA and, of course, Agile, all benefit from an iterative and incremental approach. Another key practice I've heard applied to both is to, "do just enough, just in time" -- or just in time/agile architecture.
Amongst the strengths of agile methods are the strong assertion that you don't know all the answers up front, that you're willing to accept and embrace change at any point. These are excellent principles to apply to SOA as well, within reason. Assuming you're going to start from zero and work out a complete and workable architecture, followed by a representative development and implementation is probably folly.
Architecture, among other things, is meant to constrain and guide development. In this regard, EA, SOA and agile should be able to live together harmoniously as long as the architects and developers come to a pragmatic consensus about boundaries and collaboration. This means having a good working relationship between the two camps, and a good idea of the reasons and methods behind the respective schools of thought. This, perhaps, is the hardest thing of all to accomplish. It certainly requires a lot of trust on both sides.
The approach we've taken thus far is to have architecture define a set of well validated services, interactions and general interfaces based on our EA practice, which is directly traceable to business desires. During implementation we have used an agile methodology to actually construct the innards of the services, integrate, and to build human interfaces and detailed components of the desired system.
The architects take care to guide the direction, and assert control only over the critical (architecturally relevant) portions. Usually this means staying at a fairly high level of abstraction. The remainder (the details of implementation, integration, detailed data structures) are left for the designers/developers, and if they choose, an Agile approach. This works best if the designers/developers and architects will interact as the project proceeds to make adjustments and clarifications as needed. In this way the architecture, and the implemented system both come closer to meeting the true needs of the business in the end.
I'm keen to hear other opinions in this regard, as admittedly my SOA and Agile experiences are still quite new, and only partially tested in the real world.
