ebizQ's Business Agility Watch

An interesting discussion broke out on the ebizQ Forum over the question, which came from Roger van de Kimmenade: Are SOA and Agile a Good Match?

JP Morgenthal kicked things off with: SOA is not about technology. Agile is a software development methodology. The system you designed using SOA principles may benefit greatly from the use of an agile development methodology, but the Agile is being used for development of the system, not the SOA.

Joe McKendrick mostly agreed: They are mutually exclusive concepts, but share many of the same goals -- to recognize the organizational and human aspects of systems deployments, regardless of underlying technology.

Miko Matsumura countered with: The philosophy of agile as a software development methodology has a lot to teach those in the SOA Adoption business. I would say those in the "middle" studying SOA Adoption would do well to study the implementation methodologies of the Agile people "underneath" while also learning from the "Continuous Improvement" buffs in BPM "on top".

Joel York added: SOA and Agile are a fantastic match! I'm a little confused by all commentary trying to tell them apart...when the question is do they work well together...you know, like chocolate and peanut butter.

Sridhar Yerramreddy commented: A disciplined agile will always incorporate at least one iteration of strong architectural envisioning phase for guidance towards structured governance, value focus validation and address risk. The key point is that disciplined agile is essentiall for SOA to succeed.

Avi Rosenthal countered with: SOA and Agility share some ideas, however I think that it is risky to tie them together. We should not repeat the mistake of identifying SOA with Web Services by coupling it with Agile methodology. Agile is a Bottom-Up approach and SOA is more Top-Down approach (including also some pragmatic Bottom-UP).

Roger van de Kimmenade, who asked the question, clarified with: I mean is an Agile iterative approach to implementing business processes a good way to get to a good SOA level? So in an Agile/Scrum approach you take a functionality (or in this case a Business Process) and start implementing this Process with its Services. After that you take the next (Sub)Process. It may be the case that existing Services must be refactored (as in an Agile approach). This is a kind of meet-in-the-middle approach.

JP Morgenthal clarified his position with: SOA is a strategic initiative and works best top-down. I know that's controversial and there's many that believe meet-in-the-middle (MitM) can work. I do not.

Dave Youkers brought it back to business basics with: To the extent that one enables or supports the other, then they are and should be related, but they both need to be put into context. That context is the needs of the business. I apologize to all the "techies" out there, but Information Techology is only a tool. Like any other tool its value is derived from people's ability to use it effectively.

Michael Poulin added: Building a bridge across the river in an incremental iterative manner is possible only if you know where the other river-bank is. Otherwise, if you follow just external directions (of the investor), you can easily end-up with a nice construction along the river in the river. Can you call it a bridge? You tell me.

Kelly Emo wrote: I would think that one of the best aspects that SOA the architectural approach brings to teams building systems using Agile methodologies is the concept of governance throughout the lifecycle.

And the answers keep coming...definitely worth checking out (and let us know your thoughts) right here.

Just a reminder, the ebizQ Forum is always looking for sharp minds and great questions, so please email me at peter(at)ebizq.net.