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.
Start a Discussion

Are SOA and Agile a Good Match?

Vote 0 Votes
Roger van de Kimmenade: Are SOA and Agile a good match?

26 Replies

| Add a Reply
  • This questions reminds me of the Dinner Impossible episode I watched last night. Robert Irvine did a dinner for a large Candy store and they wanted candy in each dish. Mac-n-Cheese with Candy Corn sound good? Well, that's kinda the way SOA and agile sound to me.

    SOA is not about technology. Agile is a software development methodology. They have nothing to do with each other unless you don't understand what SOA is and you equate it with delivery of a system that was designed using SOA principles.

    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.

  • 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. Agile emphasizes working incrementally with the business so that all parties benefit -- a path that all SOA-based efforts should take as well.

  • user-pic

    I would just rephrase JP: "They have nothing to do with each other unless you don't define what Agile is meant in the question."

    I am not sure that "Agile is a software development methodology" only. It may be about Business and Market, a grand-son and a grand-ma, or a couple and a mother-in-law...

  • SOA is an architectural style whereas agile is an implementation style. I will agree with JP on that count.

    Still I wouldn't be quick to dismiss this topic because what people care about today is SOA Adoption, not SOA the architecture. What people realize is that making a blueprint is easy while building a house is hard.

    However, 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".

    What I mean to say by it is that Agile and the Continuous Improvement paradigm of BPM are both based on the idea of short cycle times to improvement and reducing the risk of incomplete knowledge. The idea that you can have the "target state" completely known before you begin implementation and have that remain constant through to the end of the process is improbable in complex dynamic systems of which the Enterprise certainly is one.

    So I believe there is some wisdom in the study of implementation methodologies from other worlds, particularly those that de-risk a transformation process by avoiding "big bang" implementation (waterfall, etc) and focus on distributed intelligence and iteration.

    You could make the argument that studying "other" adjacent fields such as Agile and BPM is as useful to SOA Adopters as studying, say Bass Fishing--and that useful metaphors abound when any topic is delved into deeply enough. But it would miss the main point that I'm trying to make here which is that many Enterprise SOA Adoption programs suffer from the kinds of rigid target-states, long cycle times to improvement and set-in-stone policies that make resistance and outright revolt a distinct possibility.

    So I'll persist in saying that those in SOA Adoption would be well served by studying both Agile Software Development philosophies (for their deep and pragmatic application of dynamic complexity in systems) and Continuous Improvement philosophies in business (for their focus on short cycle times and leveraging the expertise of individual contributors).

    My 2 cents,

  • 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.

    I can speak from experience at Xignite where we apply agile development methods to incrementally expand our Web services platform. And, where our customers who use agile methods benefit from the use of our Web services, because they enable them to quickly integrate incremental capabilities into their applications.

    SOA is by it's very nature a highly componentized architectural approach where services can be introduced and augmented without the same constraints that exist when modifying a monolithic application where you have to worry about constant refactoring and whether the new thing you introduce will break what is already there.

    It is the component nature of SOA matching up to the incremental approach of agile that makes them a great match...whether in developing the services or applying them.

    SOA and Agile...two great tastes that taste great together!

    by Joel York, CMO Xignite

  • SOA is both a style of architecture and a services integration technology in which case an Agile implementation approach would be a good match.

  • user-pic

    SOA is definitely an architectural style.
    Unless we are defining "agile" in a generic software development methodology scope, it is an architectural "objective" which is a "must" in the implementation of a SOA.
    Without meeting the agile objectives, SOA implementation defeats its principle of Enterprise Context re-useability of services.

  • I would like to believe that the question is more to do with agility in general rather than the “Agile Methodology?.

    Having said that, I think agility (in business as well as technology) is what you get out of enabling SOA.

  • To answer your question, whether SOA and Agile are a match depends on the cultural dynamics of an organization. I totally align with the definition that SOA = An architectural paradigm, Agile = An implementation methodology. Not all organizations are scaled for Agile methodology due to varying nature of their motivational drivers, enterprise discipline, etc. Not just being agile is good enough, a disciplined agile is important.

    A disciplined agile will always incorporate atleast 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.

  • I assume the term agile in that context refers to Agile development methodology. I am not assuming that the question refers to Agility, because in that case the answer is yes and it is so trivial that it would not be interesting to publish the question and the answers.
    SOA and Agility share some ideas, nicely described in Miko's two cents, 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 development methodology and SOA is architectural style. In many cases SOA does not require applications development and could be implemented by abstracting organization of existing application artifacts.
    Agile is a Bottom-Up approach and SOA is more Top-Down approach (including also some pragmatic Bottom-UP).

  • OK, a bunch of people already weighed in, so I'm going to comment on comments as much as anything.

    I usually agree with JP and Joe McKendrick, but I gotta disagree with how they approached the question. First of all, I saw the Dinner Impossible episode and really can't imagine that the food actually tasted good. Candy corn in soup? No thanks.

    But I don't agree that SOA and Agile are that kind of combination. Nor do I take Joe's position that they are mutually exclusive choices. They are not a tightly coupled combination either. You can use SOA with Agile or without and vice versa. I do believe that Agile's rapid, incremental approach is well suited to the development of individual services and probably increases the efficiency of the engineering organization.

    In closing I think that Joel had the most appropriate candy reference. SOA and Agile are kind of like chocolate and peanut butter -- great tastes apart, but ever better together.

  • Within the feedback i see a lot of: "It depends how the question must be interpreted?" So i felt obliged to react.

    I mean is an Agile iterative approach to implementing business processes a good way to get to a good SOA level?
    And what are your experiences with it?
    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.

    • Well, this can certainly become an ideological discussion based on Roger's input, but I'm going to say, that 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.

      I believe MitM placates tactical audiences that want to have some attachment to the SOA label. SOA is about identifying common business functions and ensuring that they are delivered once and only once in a consistent manner to the enterprise. This is not only software services, but HR services, help desk services and even account management services. SOA is a way to approach a system and orient so that it fulfills the needs of a consumer without requiring the consumer to understand the intricacies of fulfilling the task. Hence, if it is not intended to be consumed, it does not require SOA design.

  • I am not an expert on either of these topics, but it seems to me that we need to get back to basics.

    Agility, the ability to be more responsive to changing conditions, is an objective. Agile development techniques are a way of acheiving "agility".

    SOA is a concept that enables a bunch of disparet parts to be "integrated" in such a way as to perform some higher level objective. (Deck chairs on the Titanic immediately come to mind.)

    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. Yes it has enabled people to do some amazing things, and its impact will continue to grow, but let's not forget why we're here.

    I look at BPM the same way. If you don't have effective and efficient processes, that support the requirements and objectives of the business; if you don't have an IT environment that is able to look at those requirements and leverage its capabilities and portfolio effectively - then most sophisticated BPMS environment world is a waste of time, effort and money.

    Having said that, can technology alter the business and operational process landscape - ABSOLUTELY. It has and will continue to impact business strategy and operations, just as changes to the business environment will place new demands on technology. It has to be a partnership. THIS IS PRECISELY WHY AGILITY AND SOA, (as a means of enabling agile functions to work together), AND BPMS (as a means of managing those functions) ARE RELATED.

    That's my opinion, and its worth what you paid for it.

  • Well, SOA is architectural methodology, not a technology and may not necessary deal with Web Services platform that not necessary provides any service orientation ( but rather integration). This is the reaction to the spirit of the past.

    I more agree with Avi Rosental - building bridge across the river in 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. So, to use Agile Methodology when implementing SOA, the latter must be well designed first.

    Proper SOA in IT is based on concrete knowledge of WHAT/WHY/WHO and Agile Methodology should not cross into this area but instead concentrate on HOW. That is, the 'what we do in the next time-box' belongs to 'how we implement designed feature of the services'. In this and only this case I can agree that SOA can be effectively implemented using Agil Methodology.

    If somebody believes that Agil Methodology can replace the top-down-design-first, I would like to see his or her reaction if Java were released in incremental manner every 3-4 weeks by Sun. Especially when previously released elements of API were constantly refactered...

  • This has become a rather lengthy thread which to me signals strong interest in the topic. I'm late to the party having been out of pocket for the past week but I want to weigh on on one thing I read at the risk of starting a parallel thread.

    Ironically, in the past three days, I've been asked a bunch of questions around what is the role of technical application and architectural governance (think applying the best practices of SOA governance for all types of apps and architectures)in organizations using Agile development methodologies, can the two co-exist and complement each other?

    The interesting statement made above that caught my eye was the one by Sridhar about having disciplined agile. Now, while I've been working in the realm of SOA governance for several years now, I am not even remotely close to being an expert on Agile (yes, I'm still reading the equivalent of "Agile for dummies") so I hesitate to provide technical advice here, but I have to imagine that for organizations and teams building systems using Agile methodologies, if they are doing so without some sort of governance, they are at risk of building very brittle/fragile systems, SOA or otherwise.

    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, if what is governed and the goals of governance are well known in advance and the application of governance is done at the right stages of the lifecycle using methods that make it well integrated in the tools and processes of those being governed (think policy validation as a seamless addition of the development environment), then we have a much better chance of Agile methodologies resulting in faster time to service without fragility, lack of interoperability or architectural integrity.

    So, those of you expert in Agile methodology... is their room for Agile and Application/Architecture Governance? I think so but I'm very interested in this expanded topic.

  • "Agile" and "Architecture" can coexist quite well as long as the people involved believe that's the case. Agile means "no architecture" as much as it means "no documentation", which simply isn't the case.

    What it does mean is that you don't need to do all architecture up front for the vast majority of work. As Sridhar mentioned, it's not uncommon to do some architectural envisioning during an initial iteration. This is indeed a good idea, but that vision must be vetted by the real implementation as soon as possible. After that initial visioning, consideration of architecture is an on-going and evolutionary activity.

    With regards specifically to SOA, the trap I have seen groups fall into is that they attempt to define every possible service that will ever possibly be required up-front. This is where much time and effort is wasted that could be applied to actually building applications that deliver business value. Certainly there are services that just make sense and should be built as services immediately, e.g. security/single-sign-on, etc. Others, though, should not be considered until not two but at least three applications require them.

    This does fall into the realm of Agile in the sense that business value (with consideration for technical risk) should drive what work is done and in what order. If that means building functionality as a service, then great! If it means building it as discrete functionality in one application, then that's acceptable as well.

    Dave Rooney
    The Agile Consortium

  • At LiquidHub, we debate this question persistently as we are students and practitioners of both concepts. With apologies to Miko, I’m not a bass fisherman so I can’t offer a remarkable metaphor. However, in my experience, organizations often encounter an impedance mismatch when the typical “top-down? (often incomplete, always evolving) SOA blueprint meets the “bottom-up? business-prioritized, time-boxed software realization approach associated with Agile software development.

    SOA adoption continues to falter because the SOA blueprint is often created by a centralized architecture team situated in a de-centralized organization that lacks effective IT governance. So, it tends to be difficult to sell this blueprint to independent business units which want business features and functionality that meet their specific needs immediately! And, as Miko points out above, the beauty of agile development is that it leverages short cycle times (i.e., sprints) thus reducing the risk of incomplete knowledge – i.e., elaborating what the business wants now through rapid prototyping.

    To help reduce this impedance mismatch, we advocate a similar approach to the one that Sridhar identifies – an architecture-based sprint (aka sprint #0) which seeks to identify if an SOA blueprint exists and if so, its existing services, its future planned services, its level of maturity, its level of adoption, etc…

    I also advocate leveraging the benefits of the agile software development principles in envisioning and promoting an enterprise (services) architecture – a paradigm I refer to as Express Enterprise Optimization: (http://www.raymondbordogna.com/enterpriseoptimization.html)

  • Hi

    I am curious how SOA would map to Agile.

    Like Miko says - SOA is an architecture and Agile is implementation methodology.

    Again - if we are saying Agile, I am presuming we mean Scrum here. At end of each Sprint we need to have a deliverable. Whereas implementations can be done as Scrums, i wonder how the re-factoring would work out in SOA model.

    Example - b2b scenario, service re-factoring where consumers are outside of Enterprise domain.

  • Agile could be a way to implement a SOA. Agile is an umbrella for a lot of methodologies like Scrum, pair programming, TDD.
    I personally do not believe that a top-down approach works. For me it is like a waterfall approach. I do believe that focus on a specific process and communication with the business on that process will help in getting a SOA. Agile, iterative does not mean that after each iteration the process must be on Production, but it may be ready to be evaluated further by the business. Furthermore this holds also for the B2B case in which testing as soon as possible with a partner will probably be more beneficial than big bang in the end.

    • Of course iterative approach with continuous integration and testing is the way to go with almost all projects beyond a certain size - SOA or not.

      Specifically on SOA, I like how Michael Poulin puts it. Not knowing the path can lead to a nice construction around the water. But is that a bridge?

      Sure, implementations on S-O architecture need to be more agile - but does it need to be aligned to agile methodologies like Scrum/XP? That is a moot point.

  • In my opinion, SOA and Agile better be a good fit!

    Both SOA and Agile are current IT hot topics and therefore it would be great - no, it is mandatory - that they fit together and take IT to the next level. Here are my abbreviated thoughts:

    SOA = Service Thinking - think ITIL (IT service and business service)
    SOA = Technology and Standards - web service and ws-*, e.g. ws-policy
    SOA = SOA Governance - what I refer to "Modern IT Governance"

    Agile = Rhythmic delivery of smaller units of shippable code
    Agile = Ongoing customer validation and testing
    Agile = Most importantly, ongoing communication via daily scrum meetings

    SOA + Agile = 3?!

    Both concepts are great and complement each other. However, as an industry we need to de-mystify them. They are only the next encapsulation of a standards based object-oriented development based on true business requirements (SOA) and IT best practices as they can be found it ITIL/ITSM respectively.

    We, as an industry, need to get better at explaining these – not even new – concepts and best practices. Most importantly, all of these topics need to be discussed within an overall IT context since neither SOA nor Agile have a purpose by themselves, only as additional tools, best practices and ideas within an existing IT context and department.

    Those are just my .2 cents. Would love to hear others respond to this.


    PS Please read my blog if you are interested

  • Somewhere in the discussion thread the words 'PRAGMATIC SOA' were used. Over the years I have seen many SOA efforts follow a heavy 'top down' approach which were not very pragmatic as they did not actually address a business need. They were architectural endeavors with the goal of making systems / processes more flexible but with no short term results.

    I find you can get some very good results by aligning your SOA efforts with application delivery projects. The challenge is that you will have to be very good at addressing change (a fundamental Agile requirement) across both your SOA and business applications to make this work. Here is a white paper called 'How to Leverage SOA Investments with Agile Methods' from my company if you are interested. http://bit.ly/8n88f5

  • SOA has both a governance aspect as well as an architectural aspect to it. SOA as an architectural style is used for building services which require both "operations" and "message payloads" defined. The granularity of the services matter when using Agile practises for building them. Course grain services require a global view of business architecture to address an appropriate enterprise "Canonical model" else continuous refactoring would lead to constant changes to the consumers. Fine grain services can be implemented using agile iterations without much prior thought. Hence it is the granuality and the number of consumers that would lead towards how much of agile one should use.

  • user-pic

    I'm going to abstract agile away from the agility development paradigm to the principle of ability to respond to and adapt to change. In this context it can be applied in any domain.

    In the domain of SOA agile approaches are vital to deliver business value to customers and clients. Clients might not know their complete business requirements, or the requirements might shift, unforseen or disruptive events may occur, new opportunities might surface, and so on.

    Agile approaches can guide the development, maintenance of and continuous improvement of services delivered to clients. Our current service catalogue and service levels might look one way today, but we need the agility in our design of the catalogue and service offerings to be able to modify, enhance, reduce, replace, change, according to shifts changes in the environment.

    In this context Agile guides the deployment and evolution of SOA.

  • Hi Dears,
    I am working on Scrum and SOA as Ms Research scholar, now i wand to identify metrics and KPIs for both. so please guide me.

Add a Reply

Recently Commented On

Monthly Archives