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. InfoQ posted an article meant to summarize some existing points on the subject and engage the community to further discuss the issue: SOA and Agile: Friends or Foes?
This article brought up a few points of agreement and disagreement between the two techniques and readers have started discussion their points of view.
The article suggested that even though SOA is an architecture, and Agile is a development methodology, that they are not completely orthogonal.
Frank Grossman suggested how many of the Agile practices, such as Collective Code Ownership, might be modified given the nature of SOA in the enterprise:
This article brought up a few points of agreement and disagreement between the two techniques and readers have started discussion their points of view.
The article suggested that even though SOA is an architecture, and Agile is a development methodology, that they are not completely orthogonal.
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.With that validation, the article quickly addressed their main overlap – that both SOA and Agile are concerned with making business agile. Then the article dove right in and suggested three major clashes between the two approaches:
* SOA encourages that architecture be upfront while Agile has a derogative term for this approach coined BDUF.The subject was then open for discussion to the public. The discussion thread attached to the article is shared with this news post so the following quotes come directly from the thread beneath this post. So far, the majority of commenters have not found a clash between SOA and Agile and indeed some are joining the two approaches right now.
* 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.
Frank Grossman suggested how many of the Agile practices, such as Collective Code Ownership, might be modified given the nature of SOA in the enterprise:
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.And Howard Deiner suggested that coming up with the decomposition for an SOA should not be done lightly:
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.This article brought up an interesting issue with respect to two of the largest movements in the software development community today.
