Brenda,

I for one see SOA and Agile as completely compatible. However, I can see that for those people who see architecture as something you do first, complete - and then move onto implementation, the idea of design-code-test increments looks like skipping architecture entirely or confusing it with design.

My view would be that having established enough architecture for your SOA to get going, the design-code-test increments should be in fact architect-design-code-test increments. How do we avoid chaos breaking out in the architecture? Some agile control and governance specifying what you can vary in the architecture without change process and what you need to pass through a more rigorous review.

To put this into the context of your quote from Gregor - those early projects will have greater latitude to change the overall architecture as the new learning is probably highest. Overtime, the control and governance will restrict change as more understanding and knowledge is built into the SOA system.

None of this is easy - but I fear that the alternative is the creation of monolithic SOA projects with limited chances of success.

Ronan

Ronan - Thanks for stopping over and sharing your thoughts.

I fall in the crowd of classifying SOA and Agile Development as apples and oranges. I wouldn't call it oil and water, because there are some things that agile development practices address that are directly applicable to SOA adoption.

First, my definition of SOA is always at the enterprise level. In my mind, there's no such thing as an SOA project. If I was on a project that was building both services and consumers, I think agile development would definitely be a good thing. The reason, however, is because by the nature of the project definition, the required collaboration should be in place to allow rapid change. At the enterprise level, however, the service provider and the service consumers are likely on completely different schedules, across many different projects and teams, all of which are barriers to communication and collaboration. Without communication and collaboration, agile efforts will struggle.

At the same time, creating rigid service interfaces that don't change is completely the wrong approach. The problem is poor communication between service providers and services consumers, not an interface that changes. The business does not remain constant, and anyone who thinks that service interfaces can be defined once and set in stone is destined for failure. The key to success is change management. Change management is not a problem in agile development because of close communication between the parties impacted by the change.

So, I think the takeaway should be that SOA adoption must ensure that communication and collaboration between providers and consumers occurs. It doesn't mean that service interfaces should change on a rapid basis, as individual component interfaces may on an agile development project, but it does mean that change should be managed.

Brenda -

Fascinating thoughts here - I am a passionate agilist as far as development goes, and am just thinking through how to apply those values and practices to an SOA strategy effort. Todd is correct that it's more difficult at an asynchronous enterprise level, but I still think that Agile principles can be applied in a variety of contexts. I think there is no doubt that certain Agile principles, such as valuing customer communication over contract negotiation and working software over comprehensive documentation can certainly inform and guide SOA efforts.

Great post!

Scott

Some experience with SOA, BPM and Agile

I agree with much written here so far on the shared values between Agile and SOA. www.agilejournal.com latest issue addresses this same topic. Fundamentally, both promise greater responsiveness to the needs of the business through increased velocity and flexibility. Agile's focus on incremental delivery also lowers the risk of tackling the unknown, always present in any effort of value.

Most of us find that implementing a SOA is not a technical challenge so much as it is a people and process challenge. Collaboration on this order may be entirely new to departments who formerly owned all the data and business logic (often replicated in many other departments) needed to deliver a monolithic app. Again, Agile provides a solid framework for how we should interact to deliver (or fail) early and often.

Leffingwell does a good job of discussing the role of "intentional architecture" in larger Agile projects, namely structuring our teams around components (services), each which can be "developed as independently as possible and yet conform to a set of purposeful, systemically defined interfaces." We've found you also need to apply Scrum's team-of-teams approach to divide the work, manage cross-component issues and coordinate the release milestones. You'll also likely want to create a separate systems-level, end-to-end test team to focus on how the components interact to deliver on the high level feature the stakeholders are paying for.
RL

Great dialog! I'd like to hear more from folks about actual experiences with Agile development and SOA. Specifically around the promise of agility/reuse that is at the core of SOA. It would seem that reworking the interfaces a lot would cause potential issues unless you had a lot of that good communication/collaboration going on.

Mark, Taking an incremental approach to a SOA interface is easy. The thing to avoid is taking an *iterative* approach. In a nutshell, it's not bad to add functionality on an as-needed basis to a service's api, you just want to think twice about removing or changing established calls at the api level. No one likes to change their working service calls every two weeks!

Of course, refactoring what goes on behind the scenes is encouraged in Agile. And this is really only possible to do this with confidence if you're investing in automated testing at all the unit/acceptance/system levels.
Richard

I agree strongly with the comments Richard Leavitt and Todd Biske have posted here. Our experiences with agile development and SOA are similar.

Begging your pardon for this very late comment. My take on this is that SOA and Agile forms a perfect combination for doing enterprise software development.

Anders, its never too late to join (or restart) the conversation. thanks for the comment and link to your post.

I couldn't agree more: "Time and time again I have to tell people that SOAP is not short for "SOA Protocol". Service Oriented Architecture (SOA) and Simple Object Access Protocol (SOAP) do play together very nicely, but one can live without the other!"