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.