Agile Services In An (SO)Architected World


Because one of the core stated objectives of Service Oriented Architecture (SOA) is to increase business and IT alignment and IT's flexibility in meeting changing business needs, on the surface it would seem that SOA and agile methods are a natural fit.  And within the SOA model of service production, distribution and consumption, use of agile development methods clearly has great opportunity for effectiveness on the consumption side of the equation. However, the approach by which a suite of generally reusable services within an SOA are defined and produced requires a cross-project perspective that could be viewed as running counter to a typical agile development approach. Some amount of up-front architectural thought must go into initial service definition to prevent those services being developed from becoming solely project-centric.  

This is not to say that a "boil the ocean" approach to top-down service definition is appropriate for SOA initiatives. In fact, that approach is likely to kill an SOA initiative before it can get off the ground. Instead it is a recognition of the fact that a certain level of "road map" architectural guidance must be applied to service definition, at the same time recognizing that those services are being built to support specific projects.  An iterative top-down/bottom-up approach to service definition is required to prevent SOA from becoming simply ABOS - A Bunch Of Services - that are project-centric and provide limited to no reusability across projects.

Consuming Services

As the IT organization develops a set of core services, over time these services (if guided appropriately by architectural oversight) become candidates for consumption by application development teams. Clearly having a set of pre-built functionality available to an application team greatly increases the opportunity for rapid implementation and deployment of useful application functionality. This is where the timeboxed nature of agile development techniques can take advantage of SOA. Because many parts of a particular application may already be in hand, the functional scope of a timebox may in many cases be increased, thereby delivering value to the end customer quicker and giving the end customer a greater ability to provide feedback on delivered functionality within the broader scope of the complete application.

Producing Services

Without ignoring the need for appropriate architectural guidance on the service production side of the SOA model, there are also opportunities for agile development methods {sidebar id=1} to contribute to the implementation of services. The danger that must be recognized in applying agile techniques to service production is the potential for those services under development to become solely project-focused in their functionality, not recognizing requirements from other potential consumers down the road. That said, an organization could consider services produced under an agile model to be "version 0.9" of what may become a full-fledged member of the SOA services suite over time. Clearly, a service built in this manner will provide project-specific functionality to the agile team; otherwise the team would not have built the service in the first place. Once produced, this service can be considered a candidate for inclusion into the formalized SOA services suite - but not without some level of evaluation at the architectural level.  

To produce services at this level, teams must consider a number of issues including:

  • Potential for redundant service implementations . If each agile development team is focused solely on delivering its own application, then there is considerable opportunity for other teams to produce similar services as part of their application development efforts. The architecture team must have cross-project visibility over the services being produced (most likely through a design-time service registry/repository) so that it can assess service overlap and begin to guide those overlapping services towards a common and more general single service definition.
  • Feedback against the SOA services roadmap . As part of its responsibility within the iterative top-down/bottom-up approach to service definition, the core architecture team will have produced coarse-grained services architecture - in effect, a roadmap defining broad groups of services which will be required by the business as the SOA matures. This roadmap should be produced through interaction with business stakeholders and should capture the enterprise's view of what is needed by the business going forward. Detailed business process analysis may contribute some aspects of the roadmap, but it is impractical to expect that all aspects of the roadmap will be derived from such analysis. Project-driven service definitions (the bottom-up half of the iterative architectural model)

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.