We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business-Driven Architect

Brenda Michelson

Agile & SOA: Like Apples & Oranges, Google & Search or Oil & Water?

Vote 0 Votes

SearchWebServices.com has a good, short, article by Rich Seeley covering Gregor Hohpe speaking on Agile & SOA as a powerful combination. Gregor, now with Google, is probably best known for his excellent work on enterprise integration patterns (site, book).

The article opens talking about Agile and SOA as apples & oranges:

Talking about SOA and agile development in the same breath may seem like comparing apples and oranges, says Gregor Hohpe, software architect at Google Inc., but from his point of view the terms go together like Google and search.

"Agile and SOA pair up to improve the alignment between business and IT," Hohpe told attendees at the Burton Group Catalyst Conference in San Francisco this past week. He was not being theoretical. He was talking about how Web services and applications are being developed by his employer, "one of the largest civilian computing infrastructures in the world."

The apples and oranges view comes from looking at SOA as being "an architectural style" that emphasizes how systems interact, while "agile" encompasses "a development approach" that emphasizes how people interact, Hohpe said. But in his view agile practices can help developers move SOA beyond theory.

The article goes on to point out how Agile's emphasis on evolution, iteration, testing, learning as you go, and close customer collaboration, can help bridge the gap from SOA theory to real world deliverables.

This makes sense to me. I always advocate starting small with SOA - the project (measurable return, low business risk), the team (good technicians, follow standards, work smart, continuous learners, influencers) and the infrastructure investment (leverage what you have, invest incrementally). So, Agile concepts are definitely appropriate, particularly dealing with the unknown:

He urged anyone planning to start their first SOA project to not only start small but accept that they really won't know what they are doing. He urged them to accept that Agile principle "that you will know more at the end than you did at the start."

I also speak (over and over) to the importance of the "A" (architecture) in SOA for sustainable success. Many readers of the article, and this post, might argue that Agile and SOA aren't 'apples and oranges', or 'Google and search', but rather 'oil and water', because Agile skips architecture, and jumps right into design-code-test increments.

So, an interesting question then, becomes how is that architecture aspect reconciled? Especially as you move beyond early experimentation. How can you leverage agile development practices to implement solutions centered on an architectural strategy? Assuming your staff isn't loaded like Google's.

Right now, I have more questions than answers. Nevertheless, I can't help but think a healthy SOA (service model, shared infrastructure, and assembly patterns) is the perfect feeding ground for business solution development (assembly) using agile practices. As well, I agree with Gregor, that embracing agile concepts for early SOA experimentation is smart.

I'll definitely be doing some research and thinking along these lines. If my schedule works out, I might even sneak out to Agile2006 for a bit next week.

I'm very interested to hear what others think. Have/Would you use Agile and SOA together? How do you reconcile the 'architecture aspect'? Which do you start with? As the article points out:

For the managers in the audience, he also stressed that both SOA and agile development take time for programmers to learn. He warned against the sink or swim approach where coders unfamiliar with SOA or agile practices are asked to start doing both at the same time.

2 TrackBacks

SOA and Agile - Peas in a pod from Enterprise Abstraction on July 18, 2006 11:21 PM

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. ... Read More

Brenda Michelson wrote an interesting piece on whether SOA and Agile development techniques are compatible or not. My answer is that it depends on a number of factors, such as: 1. Are we looking at building a SOA using Agile Read More



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 - Thanks for stopping over and sharing your thoughts.

The agile aspect to governance is interesting. Sounds like a good idea even if you aren't practicing agile methods. Essentially, incorporating a tolerance continuum.

Your point on early projects having greater latitude (and influence) on the architecture highlights the need for careful early project staffing. I always call for the architects who are driving architectural strategies (like SOA) to participate on the early business projects, and your comment reinforces that importance. -brenda

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.

I've cross posted this on my blog.


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!



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.

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.

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

I found Dr Samarin's presentation slides interesting, but I must say I have a different view of the matter.

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.

This is what I have scribbled together...

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!"

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.

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

Brenda Michelson, Principal of Elemental Links, shares her view on architectural strategies, technology trends, business, and relevance.

Brenda Michelson

Brenda Michelson is the principal of Elemental Links an advisory & consulting practice focused on business-technology capabilities that increase business visibility and responsiveness. Follow Brenda on Twitter.


BDA Feed
BDA Comments Feed

Enter your email address:

Delivered by FeedBurner

Recently Commented On

Monthly Archives