WebServices dot org

SOA, Agile, and XML Software Development

SOA does not prescribe a process to transition from our current state of rigid monolithic applications to loosely coupled services. There are several SOA maturity models which mark several waypoints on this path, but they do not describe how to get from one stage to the next, only what your resources should look like once you get there.

This transition is the first place where Agile and SOA really complement each other. In agile we talk about the principle of “sashimi”, the practice of implementing narrow “spike” solutions, as opposed to far-reaching wide designs. Although a single service or composite application requires up-front contract design, the overall pattern of movement can be evolutionary. By replacing a slice of our monolithic application with a high-quality service, we can step-wise move toward to goal of enterprise agility.

Agile practices give us a way to do this successfully by putting constraints on each step of the evolution. Time-boxed iterations, Test Driven Development, and Daily meetings, all provide mechanisms to check our progress toward our goals. Consider again the similarity of SOA and OO as ways to organize our resources. We’ve already learned that OO Design without inspect and adapt cycles tends toward over-designed, over-built systems. Service-Oriented Architecture, without agile practices to inspect and adapt, is vulnerable to the same pit-falls that our over-built OO systems have fallen into.

Recently I heard Alan Shalloway talk about how the principles underlying the practices of design patterns, TDD, and refactoring are identical. In his talk he demonstrated how using these principles can lead to design solutions that meet the present requirements, and are resilient to change at every step of their evolution. I believe that the same principles are at work in SOA. Again the difference is a level of scale.

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.