Amr Elssamadisy has started a new series/discussion at InfoQ on SOA and Agile.  The initial article asks "SOA and Agile: Friends of Foes".  This is similar to a conversation we had here last summer.  Including the high quality comments.  Below are some excerpts.   I disagree with the last two clash bullets, especially the third.

Article Open:

"SOA aims at making the entire enterprise agile by using services as the building blocks for applications. Agile software development aims at making organizations agile by introducing practices that increase communication and feedback. Which is right? Which is better? Are we comparing apples and oranges? Can they be used together, and if so, how?"

On the Friends side:

"SOA and Agile share the same broad goals. They both recognize that change is an inevitability and that organizations need to effectively cope with that change. So we would expect that Agile is by default the methodology of choice when building SOAs and vice versa - right?"

On the Foes side:

"One of the main reasons is that they come at the problem from different roots and initially different directions. Agile is historically grass-roots and small-project based, although throughout the past years the community has gained experience and learned to adapt the principles of the Agile Manifesto to large projects. SOA is a newer initiative and is top-down in nature and takes a divide and conquer approach to software development. This approach, especially the 'divide' part, typically results in low-bandwidth communication between teams such as documents, specifications, etc... .

Specifically, here are three areas where SOA and Agile clash:

• SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.
• SOA encourages teams split along functional lines while Agile encourages cross-functional teams.
• SOA does not have a position with respect to feedback and change of the services once they are built while Agile is focused on frequent and feedback at both a technical and personal level."

I encourage you to read the article and the comments. 

Posted by brendamichelson in SOA • agile | Permalink | Comments (1) | TrackBacks (0)

Last week's post on Agile & SOA has generated some great conversation.  There is general agreement that Agile and SOA share values, particularly around the end goal of business responsiveness.  The question though, is how to provide that responsiveness (velocity and flexibility), in a sustainable manner (architectural integrity).  Themes that emerged in the comments were separation of concerns, increments vs. iteration, and the three C's: communication, coordination and collaboration.

Today, I'm pleased to add another voice to our conversation.  Annie Shum, a leading SOA and technology thinker, was kind enough to share her views on SOA and Agile in an email conversation, with permission to post here. 

In the first business-driven architect guest post, I’m thrilled to publish Annie Shum on Agile and SOA:

“Adding a bit more to the discussion but from a different perspective based on my favorite metaphor of SOA analogous to a set of architecture and urban city planning blueprints plus administration policies whereas developing software is more akin to building buildings, bridges, or other structures in a city.   

The former is a meta framework where city planners, building architects, policy makers, construction contractors, government officers including zoning permits etc have to come together to create a master plan through  collaboration & communication - all under some explicit as well as implicit policies & overarching governance. It’s not about the city planners dictating individual buildings but more about the overall cohesion of the city: the neighborhoods/community planning including security (courts, police buildings, fire stations etc), education (schools, libraries) and recreation (parks, zoos etc).  The relationships matter more than the individual structure to the city planners.  Meanwhile, the contractors can go ahead and build the buildings according to their own business models as long as they comply with the master blueprint of the city planner office, the zoning laws, leverage the common infrastructure based on city standards etc.

To cut to the chase, that’s what Agile vs SOA is all about. Historically, software development has been by and large project centric. To me most software development projects are still akin to “building little house on the Prairie”. Whether you use Agile or waterfall approach has both pros and cons. Obviously Agile has a lot of compelling benefits (note: I favor Agile) but only work effectively if there is constant communication between management and developers as well as clearly spelled out accountability methods to manage rogue development. Above all, transparency is critical regardless what technique is used: agile or otherwise.

In a SOA shared service ecosystem, so long as the enterprise architects act as the city planners and work collaboratively with business process owners, LOB exec, software architects, developers, database architects IT staff, capacity planners, performance analysts, etc to create a cohesive set (maybe incrementally) of architectural patterns, blueprints, what services to share, what standards to comply, what policies to follow and to specify etc,  then the software architects & developers are in theory free to implement their services (encapsulated by standards based interfaces, contracts and policies) and composite app using their technology choices and development approaches: Agile or not or more likely a mixture of agile and traditional method…

So it hinges on the SOA ecosystem cohesive architectural patterns, policies and blueprints that act as the beacon & “glue” for the enterprise. That’s why reflective modeling is so critical: it’s the closed loop modeling process from begin to end throughout the lifecycle of services that can guide this complex SOA transformation. Having a pervasive metaframework for modeling different aspects of SOA, I see Service oriented based modeling as the intermediary and the bridge connecting business & IT as well as connecting architecture patterns with software development."

Posted by brendamichelson in SOA • agile | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by brendamichelson in SOA • agile • architecture strategies | Permalink | Comments (11) | TrackBacks (2)