BT

SOA and Agile: Friends or Foes?

Posted by Amr Elssamadisy on Apr 14, 2007 |

This article first appeared in Computer Magazine  and is brought to you by InfoQ & IEEE Computer Society.

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? It is impossible to do justice to all of SOA or all of Agile in one article so we will keep focused. This will be one article of a series of articles planned to bring this discussion to the forefront.

Methodologies and Architectures - Mutually Exclusive?

One might argue that software development practices and architectures are non-overlapping. That may be true, but not in this case. Agile methods like XP directly address design and have come up with derogatives like Big Design Up Front (BDUF) to discourage this behavior. Most SOA teams, on the other hand, are almost predominantly functional teams grouped around sets of services. The nature of SOA encourages specific team makeup and types of communication within the teams which is the realm of methodologies.

Agile and SOA are Friends

SOA is an architecture. SOA stresses that businesses must be able to respond to the market and that by building services we can get rid of the duplication and get closer to the elusive goal of reuse. By building services instead of applications, teams can leverage work by others within and without the enterprise.

Agile is a methodology. Agile stresses everything changes and that software development teams must be able to recognize and respond to change frequently. By introducing both technical and non-technical practices teams are able to help businesses become agile.

An architecture and methodology can be used together. They are complementary by nature. Moreover, 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?

Agile and SOA are Foes

You would think that with shared goals the overlap of practices and architecure implied by these two techniques would be in agreement and not in conflict. At this point in time there is little in the SOA community that is Agile and vice versa. Why is this?

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.

Today's Reality

To date, there is very little written on this topic. We are still trying to figure things out. There are, however, a few articles I was able to find:

Carl Ververs describes building an SOA using a full set of agile practices, complete with developers in a war-room, in Agile: The SOA Hangover Cure . Unfortunately this is only for one team building a set of services. In an interview with InfoQ, Geoff Henton and Tom Stiehm discuss using agile methods in building SOAs. This article seems to imply a set of practices for a single project - which is the Agile sweet-spot, but what about inter-team communication? What about maintenance in the future when the services built need to change but already have tens or hundreds of clients? I've suggested that SOA teams communicate via tests and not documents and Frank Grossman agrees, but asks exactly how that will be done in a heterogeneous environment?

Furthermore, in my personal exposure to SOA teams I have never seen any Agile practices used in an inter-team manner. Teams break up and work on their own services and applications and communicate via a interspersed meetings, documents, and WSDLs. SOAs encourage BDUF and little, if anything, is ever done to plan for the eventual change of the services themselves.

This article is short because, frankly, I don't have the answers. This will be the first of several discussions on this topic.  We will start out with an open playing field, and then take the important issues, as they emerge, and discuss them individually.  All comments are welcome and encouraged.

This article first appeared in Computer Magazine  and is brought to you by InfoQ & IEEE Computer Society. Computer magazine, the flagship publication of the IEEE Computer Society, covers all aspects of computer science, computer engineering, computing technology, and applications.

 

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Clash is current not fundamental by Paul Oldfield

I'll follow your lead and take a quick shot at what I'm trying to say, rather than a long article.

My first gut feeling is that the perceived differences are not fundamental, they are more the way teams work today. Let's take your 3 bullet points:

* SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.

Agile has a derogatory term for "too much" architecture up front. The appropriate amount to do up front is rarely "absolutely none". In reality, how much depends in part on the skills of the team, on their ability to write code that is amenable to change, on their ability to separate out concerns, including architectural ones. There is a reasonable hope that people who learn to separate out services will learn to separate out architectural concerns in a similar way.

* SOA encourages teams split along functional lines while Agile encourages cross-functional teams.

This split along functional lines is totally unnecessary, and SOA has no need to encourage it. Even in SOA architectures, it is possible to have teams considering, and working on, the whole system. This desire to split along functional lines is a symptom of Command and Control management. There's nothing about SOA that says it needs Command and Control management.

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

So? If there's a lack of something that we find we might benefit from, let's put it in place. In effect you're saying "SOA doesn't mandate Agile approaches". That's true. But by not taking a position, it isn't ruling them out.

SOA and agility are indeed complimentary by Michael Mahlberg

I'm currently consulting on a project where we actually do both. I also introduced agile techniques to projects and did enterprise SOA planning for another client in the past.

Having been active in both areas I'll try to shortly summarize my experiences related to your bullet-points. (But I don't claim to have any final answers either)

SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.

Surely SOA - e.g. with its emphasis on contract first design - does require some thought beforehand. But the point is the granularity. One of the maxims I value most in SOA is the second point from the 10 soa principles: "2. Shared Contract and Schema, not Class".
This also applies to design. Building a SOA does not have to mean to design all of the building blocks to the last detail - the design authority of SOA should stop at the outward interfaces of the services. The services themselves will need their own design - and that design can and should be evolved in an incremental, iterative way, following principles (like e.g. DRY) that can be quite different from SOA principles (where e.g. redundancy is quite acceptable to ensure document orientation).

SOA encourages teams split along functional lines while Agile encourages cross-functional teams.

I think that services should be defined by business needs. To me this does not imply any functional splitting of teams. Of course there is the idea of these different levels of services (some knowing process rules, some caring about business knowledge, other providing data access) but up to now I have not yet bought into this idea. And when a service (with business value) is in the hands of one team, that team needs to be cross functional to address all the topics that need to be handled in order to make that service deliver its value.

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.

Some of the SOA efforts I have seen would gain a lot from installed feedback loops - this indeed seems to be a part where the SOA world could benefit from agile achievements.
But the loose coupling that results from document oriented SOA approaches plus clear service boundaries are the foundation upon that a changeable SOA environment can be built. With numerous options to implement versioning of messages and interfaces to me the core of the SOA is the possibility to have stable anchorpoints in a changing world. And backed up by agile techniques like test driven design and continuous integration these stable anchorpoints can even be managed.

For me the question is not wether to do agile or SOA but _where_ to apply agile practices to implement a SOA. As most proponents of agile methodologies say, agile works best with small teams. Even processes that claim to be scaleable achieve that scaleability through a divide-and-conquer approach (e.g. scrum of scrums). To me the division along service boundaries seems quite a natural choice.
In my field of vision SOA is not used to implement only one "application". Instead it is used to build environments where different (service-) providers interacts with (service-) consumers. This happens on a large scale. Each service still has a whole eco-system to live in - some even with their own UI.

In my opinion (at least today) the best way to build and manage theses eco-systems is an agile approach whereas the specification which eco-systems are necessary and how they should co-operate has to be done in a SOA way.

Cheerio
Michael

Re: SOA and agility are indeed complimentary by John Reynolds

The whole point of SOA is to provide services in a way in which they can be easily choreographed together to produce composite applicatons. Agile techniques are a great way to develop that choreography.

John

Maybe they are both "right" by Howard Deiner

It seems to me that the basic impedance mismatch between SOA and Agile is that SOA is an strategic architectural concept that believes that if you structure the software that runs your business into layers to allow for Description, Discovery, Negotiation, Delivery, and Composition in a well defined manner, you will be able to reuse those business components to quickly respond to change in the business with a corresponding change in the software. On the other hand, Agile is more of a tactical process oriented concept that claims that it is pretty much fruitless to create large decompositions before hand, and that by application of some rather simple principles: things like Customer Involvement, Iterative Development, Pair Programming, Continuous Integration, Simple Design, and Relentless Refactoring, a design and architecture will emerge from the problem solutions that will fit the organization like glove, be malleable, and form a natural basis for reuse. At this level, SOA versus Agile are more likely to be characterized as orthogonal rather than just different. But the question is somewhat open: would a pure Agile oriented development yield results as good or better than a SOA approach? And how does one come up with the correct SOA decomposition, anyway?

The answer to that last issue leads us to the crux of this problem. If we believe that SOA is the right approach to take, at least as a grand design pattern, then how do we decompose our business into the components that fit the five or so SOA stack pieces? How do we get that right the first time through? We all know how maddening it is to put together tons of code ending in a WS-BPEL application, only to have to rip apart and refactor all the layers into something else that will hopefully yield the same results as the first attempt, yet allow for the solution to problems that engender the refactoring. The answer to that lies in the use of Agile as the way to go about SOA implementations.

It’s my experience that for a problem of any magnitude, it is simply too hard to try to nail a “correct” SOA decomposition on the first time through. There are too many moving parts in a business enterprise. And when we work in that environment, most of the time, we end up implementing business processes as services, rather than seeing the actual basic business components that allow for proper composition at a later date. So if we expect a SOA initiative to be successful, we have to understand and appreciate the importance of using Agile techniques to allow us to design, build, test, and verify the utility of each SOA component as it comes up. Yes, there needs to be some BDUF, but the boundaries need to be left somewhat loose, so that as each architectural spike is explored in subsequent iterations, the “play” left between the component boundaries is large enough to allow the entire codebase to flex into solution.

So I’m not convinced that SOA and Agile are inextricably at odds with one another. I just believe that they attack different problems. They both have their place. They can both be “right”.

Looking through the right lens by Frank Grossman

This is a great time to be asking these questions. Agile getting continually refined over years of code development methodologies that allow development teams to react faster. And SOA a new view of an architecture that has as one of its main benefits being to make your business more agile. It seems there should be a lot to learn, if not applied, here from agile programming that can be applied to an agile architecture. As with any problem it is good to look at it from many angles and with different lenses. Here is a view, from a longer paper by my college Even Leonard, that looks at SOA from a point of view where the XML is a software layer in itself.

At the SOA level of scale, practices like TDD, continuous integration, and collective code ownership take on new meaning. TDD becomes a central practice in developing contracts; by simulating a service described by a contract, and creating test-clients against that simulation, all-parties can participate in the design of the contract. One can take the view point that this is the central activity of software development at the XML-software layer. Functional teams may implement code on either side of the contract, but the team that creates the contract must be cross-functional and practice TDD to ensure the contract will meet everyone’s requirements for the next iteration. From the view of SOA the contract, message patterns, and xml schema are the software. Delivering the behavior described by the contract is done on a lower level of scale and is subject to the constraints and benefits of existing Agile project management. Agile SOA Management might be the name of this new level of scale.

Continuous integration and collective code ownership take on new meaning at this level as well. Instead of focusing on whether our code continues to function while introducing change, continuous integration at the XML software layer will focus on whether our contracts, message patterns, and schema will continue to function. To do this, XML tests created during contract development and from support cases in production need to be gathered and organized to form a new continuous integration system. This system will be responsible for determining the consequences of introducing change into your SOA. In order for the sashimi practice of service development described above to be effective we will need clear feedback on what effect the changes our later iterations will have on the whole system. The tests from the earlier iterations are the basis for determining this.

Collective code ownership also steps up a level. In agile practice at the project level, the code is owned by the whole cross-functional team. In agile practice at the SOA level, the XML software layer is owned by the cross-functional team that designs contracts. In fact one can envision a “SOA Owner” like the “Product Owner” in Scrum, which represents the goals of the whole enterprise. This SOA Owner would be responsible for maintaining a “SOA Backlog” and directing one or more “XML Development teams” through a series of iterations focusing solely on the XML software layer. The SOA Backlog would be a prioritized list of business requirements to meet market demands.

To meet business requirements in the backlog the XML Development teams would deliver: not only contracts for individual services, but message patterns, and shared schemas for use among the services. Then the members of these teams would cross the level-of-scale boundary and become product owners within their own departments. Each of their teams would develop the behaviors behind the XML requirements using Agile project management methods. Additionally, the Scrum Masters/Agile coaches of the teams at the project level would cross the level-of-scale boundary in the opposite direction creating a feedback loop between the two levels. This could be called the Agile SOA Development Lifecycle.

First paragraph fix by Frank Grossman

Oops used the draft version. Here is the real one.

This is a great time to be asking these questions. Agile is being refined through years of software development, allowing development teams to react faster. SOA is a new view of software architecture, which has as one of its main benefits, to make your business more agile. It seems there is a lot to learn from agile programming, or even to apply directly to an agile architecture. As with any problem it is good to look at it from many angles and with different lenses. Here is a view, from a longer paper by my college Evan Leonard, that looks at SOA from a point of view where the XML is a software layer in itself:

Governance is not development by Chris Norton

I think part of SOA's appeal to IT management is that it provides a concrete way to define governance. It gives them a way to say that their enterprise architecture will consist of WSDL and UDDI and WS-* and a well-known set of schemas, and so on, and that everyone will follow those standards. Fine. But unless the governance insists on BDUF, there is no reason why the line-level practitioners can't apply agile techniques to develop software that complies with the governance.

Clashes? Not really by Stefan Tilkov

Addressing the three "clashes":


  • SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.

    I disagree that SOA requires BDUF. It requires an architecture that spans multiple implementations, but this architecture can (and should!) be built using YAGNI principles. Trying to get the overall SOA domain architecture in place up front is just as much doomed to fail as in any large-scale development effort.

  • SOA encourages teams split along functional lines while Agile encourages cross-functional teams.

    I'm not entirely sure what this is supposed to mean. In my understanding, Agile methods argue for multiple small projects instead of a single large one. The service boundaries quite naturally map to separate (possibly agile) 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.

    Which is why I see the two as complementary.

    Is the SOA decomposition static ? by Amr Elssamadisy

    The majority of the comments indicate that there is no clash. I agree conceptually, but there is a definite clash on the ground. To focus on one topic, once the decomposition is done, and each team works in an agile manner in their part - is that *it* ?

    I submit that there is a major problem here - the assumption that this decomposition is correct and does not change. Of course it will change. But it cannot and we get the calcification and momentum build up of the current breed of applications, but now on a *much* larger scale.

    Amr

    Re: Is the SOA decomposition static ? by Frank Grossman

    I think this is a great topic. If services and composite applications each have their own lifecycles, which are working well using agile methods, then when they are published or deployed to the architecture they will arrive with individual high quality. But who is responsible for looking after the lifecycle of the overall SOA? We see that happening in two ways:


    One, no one is looking over the SOA lifecycle so you end up with some big applications that happen to be integrated with Web services. This leads to the calcification you described.

    Or two, you build up a SOA lifecycle that quality and reuse built in, and is humming along; I think of it as one of those factories you see on he science channel “How it’s made”. Everyone one is paranoid introduce a change to the system for the chance that it would grind to a halt. This is where the right people and infrastructure are needed if a business is serious about building their agility through a Service-Oriented Architecture.

    The companies that we see doing the best have some kind of SOA center of excellence that is responsible for organizing the overall SOA effort. These groups can also benefit from using agile methods while developing the SOA lifecycle at XML messaging level. Additionally, to ensure success and agility of the overall SOA lifecycle, these groups need to invest in infrastructure for SOA quality and governance. This infrastructure has two purposes, one is to support the individual teams to build high-quality services and applications, the second and more important, is to check the effect of the output from the individual teams on the quality of the overall SOA before the service or application is deployed into the live SOA environment. Again, the agile practices of Test-Driven Development andContinuous integration are starting points for creating this new SOA Quality infrastructure system.

    Agile Development v SOA by Kelly Waters

    Personally I feel strongly that SOA and Agile are complimentary.

    Agile development does not suggest bad design, just that it's not ALL designed up front. A high level design, i.e. architecture, is useful up-front even in an agile development, with more detailed design decisions taken on more of a per feature basis. Equally I don't think SOA pre-supposes any particular management approach to the development.

    In both cases they enable business flexibility and reduce the cost of change. In that way they are both "agile methods".

    For further reading, you or your readers may be interested in this blog all about agile development:

    www.allaboutagile.com

    In particular there is a description of 10 key principles of agile development, irrespective of which methodology you may be using:

    kw-agiledevelopment.blogspot.com/2007/02/10-thi...

    And there's also an agile development forum "all about agile" for further discussion with peers:

    www.groups.google.com/group/allaboutagile

    I hope these resources are useful.

    Kelly Waters
    www.allaboutagile.com

    Re: Is the SOA decomposition static ? by Michael Mahlberg

    To focus on one topic, once the decomposition is done, and each team works in an agile manner in their part - is that *it* ?

    No, it is not.
    ... Of course it will change. But it cannot ...
    To me SOA does in no way require the decomposition to be static. Perhaps this notion is based on my current environment, but I do not think that even the SOA-Governor owns the services. And to implement the (perhaps pre-planned) SOA does not mean to implement all services on your own.
    A lot of services can be supplied by third parties and their interfaces result from negotiated contracts (both legal and technical). Therefore changes in the SOA don't just happen but have to be negotiated as well
    The opportunity to have different version of service interfaces active at the same time allows for controlled shifts in responsibility and thus enables a changing (or evolving) decomposition.
    Cheerio
    Michael

    Re: Is the SOA decomposition static ? by Amr Elssamadisy


    To me SOA does in no way require the decomposition to be static.


    No it does not require it - that's not what I'm saying. Suppose, 1 year after a service is built, it is used by 10 clients. Now, suppose that it needs to change. This is something any developer can tell you will cause problems in the implementation even if you *know* what you are changing to. In agile-speak, you are refactoring without tests because you have no inter-service tests.

    The classic solution is to build a facade and have multiple implementations. We know where this gets us - it gets us to code duplication, a large code base, and many many band-aids.

    So, to re-iterate, SOA does not mandate anything. SOA as practiced today and as suggested by yourself (by building each service team by team) will produce silos of functionality, even if built in an agile manner.

    There is coupling between the service and all of the clients who use it over time. The change of that service will break the existing clients using it with the methods used today.

    If not, please answer why not and what is the mechanism that will keep this from happening. Negotiation is insufficient to the task.

    Re: Is the SOA decomposition static ? by Stefan Tilkov

    There is coupling between the service and all of the clients who use it over time. The change of that service will break the existing clients using it with the methods used today.


    If not, please answer why not and what is the mechanism that will keep this from happening.


    It will happen, and I don't see SOA as a magical silver bullet that will suddenly prevent this. But that's beside the point (I think). SOA argues for documented (and governed) dependencies between services. This doesn't mean that I will never have to change a service in a way that break its clients -- only that I know I will break them (and thus can take appropriate measures). Compare this to today's infrastructures, where the only way to find out what effect a change will have is often to just make it.

    SOA is a an approach that emphasizes viewing your overall, cross-project, cross-system IT as a whole. And this is infeasible when you go into too much detail. So on the one hand, part of the answer to this discussion is that SOA is only concerned with the service interfaces, not with their implementation. On the other hand, the overall service architecture itself needs to be developed in a time frame of years - and it can (and, IMO, should) be developed according to (many) agile principles.

    Re: Maybe they are both "right" by Frank Krasicki

    Your observation that SOA and Agile are orthogonal is an insight worth noting.

    What is most amusing about this discussion is the religious platitude that the agile movement somehow is superior to heavier-weight methodologies because it is so much more dedicated to the greasing of change during implementation.

    Yet SOA, is unexpected change for the agile crowd. It is non-linear to the trajectory that agile advocates take for granted because they believe they own the golden hammer pattern of methodologies. Agile developers believe whole-heartedly that by embracing change they have inoculated themselves from the ravages of change, that their development methods are eternal.

    Yet SOA is unexpected change. SOA requires heavier weight architectural thought and methods and techniques. The first-order complexity of point-to-point development that agile is so appropriate for is wholly inappropriate at higher orders of enterprise development. Here, CASE tools re-emerge.

    Agile is all about managing change until the change requires the disposal of the agile methodology itself. Today, agile is not alone in twilight. In many organizations, the old guard is trying to shoehorn old and obsolete ideas into a SOA vernacular as if to fool themselves into thinking SOA is just about writing some objects and gluing it all together.

    The fraudulent vernacular of "reuse", "business-driven", and so on has the same authoritative emptiness it always has had - things must be the same - right?

    The answer is no and change has arrived - especially for those stuck in the agile world.

    - Frank Krasicki

    Re: Is the SOA decomposition static ? by Paul Oldfield


    Suppose, 1 year after a service is built, it is used by 10 clients. Now, suppose that it needs to change. This is something any developer can tell you will cause problems in the implementation even if you *know* what you are changing to. In agile-speak, you are refactoring without tests because you have no inter-service tests.

    Hold on, that sounds like an assumption. It sounds like one that doesn't need to be true.

    As far as I can see, you are propounding the same argument that used to say a shared database was a barrier to refactoring. We now have proof that the shared database doesn't need to be a barrier to refactoring and agility. The same approaches can be used to ensure a shared service is not a barrier to refactoring and thus to agility.


    The classic solution is to build a facade and have multiple implementations. We know where this gets us - it gets us to code duplication, a large code base, and many many band-aids.


    Again, if you don't like the results, don't do it that way.


    SOA as practiced today and as suggested by yourself (by building each service team by team) will produce silos of functionality, even if built in an agile manner.


    Ermmm... Surely that's what we intend to happen? Or were you talking about silos within the team rather than within the code? If you don't like that, build your teams some different way.


    There is coupling between the service and all of the clients who use it over time. The change of that service will break the existing clients using it with the methods used today.


    C'mon, we had this cracked 20 years ago. You could provide the new service to new clients, and migrate the old clients to the new service at an appropriate time. Just don't retire the old interface when you publish the new one. Okay, some small percentage of service changes are pernicious and cannot be done this way. So then we change all the clients at the same time. If we've done a good job of separating concerns this is just a hassle. If we haven't done a good job of separating concerns then I don't see how we can hope to make a go of SOA.

    SOA and Agile - Friends or Foes by brenda michelson

    Last summer, I started asking similar questions on SOA and Agile. Here's a link to the original post with reader comments and a follow-on post.

    I agree this an important topic and am glad to see the discussion.

    The SOA and Agile Culture Clash by Benjamin Booth

    See The SOA and Agile Culture Clash, in response to this article, here.

    SOA and Agile Compliment Each Other / Agile Approach vs Methodology by Dwight Ferguson

    First off let me simply state this is unequivocally a debate worthy of discussion for certain. My own views on this article are as follows:

    I believe Agile and SOA compliment one another more so than they detract from one another. I personally view the Agile approach as an effort or attempt to make the act of participating on a software project as flexible as possible for the business. Agile also allows IT to respond more dynamically to a business' ever changing needs in an expedient fashion. I view SOA as an effort or attempt to make the physical construction of a company's software architecture as flexible as possible. An enterprise wide SOA implementation should provide enough of a pre-built reusable foundation that the software projects spawned to address the actual concrete needs of the business are carried out very quickly and in a light weight manner b/c so much of the architecture is being reused. For example, on a SOA project Aspects created for Auditing, Authentication and Authorization can all be reused by the various services that will eventually be created by the line of business software teams.

    There is also mention of Agile as a methodology in this article, that I also take some measure of umbrage to. The majority of Agile approaches are simply just that, they are approaches on "how to" conduct a software project. I do not personally view Agile as a methodology because quite frankly most of the approaches do not offer templates for capturing all the required information, such as the requirements and design models that may be required for a project. In fact, one could use an Agile approach like XP or FDD and still adopt a different set of document templates from a real software methodology. Another good example in defense of this position would be the Agile Unified Process (a.k.a AUP), whereby Agile is the approach, but the methodology for documenting the requirements, and design modeling is the Unified Process.

    To briefly play Devil's Advocate the one thing I will say contrary to my above point is that I believe "that perhaps" the Agile community has done itself a disservice by also creating Agile approaches that also possess their own methodologies, for example Crystal and DSDM, thus causing a bit of an identity crisis or source of confusion for some using Agile as we now have some Agile based projects using Agile purely as an "approach" and other Agile based projects using Agile via the more comprehensive Agile "methodologies". Whether this is an issue or not I'm sure is highly subjective & debatable, but I do know first hand that it is a source of confusion for many companies' IT departments and individuals alike looking at defining IT documentation standards & standardizing their approaches.

    Re: The SOA and Agile Culture Clash by Deborah Hartmann

    Benjamin... your link doesn't work for me.

    Re: Is the SOA decomposition static ? by Michael Mahlberg

    Seems like the discussion has dried up a little.

    I still have to answer Amrs last question - but I just couldn't put it better than Stefan and Paul.
    But I just stumbled across an example of a service change that could have rendered a huge amount of clients useless.


    There is coupling between the service and all of the clients who use it over time. The change of that service will break the existing clients using it with the methods used today.

    If not, please answer why not and what is the mechanism that will keep this from happening. Negotiation is insufficient to the task.

    A service is meant to deliver business value. So if the provider chooses to change the way he delivers the service he either needs to provide a migration path or just might drop this line of revenues. Therefore there is a strong motivation to negotiate - negotiation of the timeline, negotiation about the new service-interface, negotiation of compensation and so on.
    Let me add a recent example from Germany: for almost sixty years television has been broadcasted analog, now this service slowly comes to an end, rendering millions of service consumers (i.e. analog tv-sets) "broken". Of course there is a rather tangible business cause in providing the service (namely collecting advertisement fees), therefore the broadcasting companies seem to drop that business. But of course that's not true. For many years there have been other interfaces to the service (Sattelite-tv, Cable-tv and DVB-T) with a higher QoS (i.e. More channels, better sound and picture quality etc.) and since the new service interfaces really are better (provide added value) than the old ones a lot of the clients migrated one way or the other.
    But even for those client that still depend on the old interface there are ways to connect to the new service-interfaces. In SOA-Speak they utilize a 'client side service adaptor that translates the new protocol to the old one' - technically they just plug in a DVB-T or sattelite receiver that emits the olde analougue signal.
    Although this example does not include any WS-* (or REST ;-) ) specific, technical solutions it shows a business driven way to handle the situation. To someone who likes technically sound solutions the stack of analog-on-digital-on-analog-on-digital... may not seem too apealing - as little as a 'call these three services, perform those calculations, call that webservice'-client side service-adapter - but from an economical point of view it is a sound decision.

    How to Leverage SOA Investments with Agile Methods by Tiago Simões

    Check out this white paper by OutSystems that examines the benefits of SOA as well as the layers of complexity that hinder transitioning a fragmented delivery process to one that is more adaptive and fluid. It further analyzes early measures an organization can take to accelerate the realization of SOA's full potential.

    Agile SOA embraces an incremental approach that, when combined with Agile environments, enables organizations to quickly and efficiently clear the hurdles of SOA implementation and utilization, extending the value of deployment with proven advantage in achieving responsive business change.

    Read the full white paper on how to Leverage SOA Investments with Agile Methods

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Email me replies to any of my messages in this thread

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Email me replies to any of my messages in this thread

    22 Discuss

    Educational Content

    General Feedback
    Bugs
    Advertising
    Editorial
    InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
    Privacy policy
    BT