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) should be mapped to this top-down architectural roadmap to determine fit within the model. Some service definitions will fit neatly into the services roadmap, other service definitions may not fit so neatly. In the latter case, perhaps the roadmap needs to be modified, or perhaps the service is simply trying to do too much and should be refactored into two or more services. In any event, each project's services should incrementally augment the services suite being developed under the guidance of the organization's SOA services roadmap.
• Recognition and management of service versioning impact. Services contributed from agile projects must be guided over time towards inclusion into the services suite. Recasting such services to incorporate additional top-down functional requirements will of necessity result in new versions of those services. The core architectural team must define and manage a services maturity model that gives project teams sufficient visibility into plans for new service version rollout over time and the subsequent retirement of back-level service versions.Typically, an IT organization must concurrently maintain at least two versions of a service in production to give service consumers sufficient time to migrate their applications forward.Augmenting this approach with sufficient upfront notification of planned service versions can improve the organization's agility, both by informing service consumers early on of planned changes and by enabling those consumers to participate in the definition of those new service versions.

An Example: Currency Conversion

Let's take a brief look at how a seemingly simple example fits into this SOA services production/consumption model. Currency conversion is a part of many business activities today, and while the basic currency conversion scenario is straightforward, a strategic view of an enterprise's conversion needs can introduce significant complexity. Consider the needs of a multinational distributor. This distributor may support both retail and wholesale channels ranging from a publicly accessible website to storefronts to direct and indirect partner sales via modern SOAP-based partner integration, traditional EDI and even phone support. Add contractual complexity to the mix (some customers may receive a standard exchange rate, other customers may qualify for a preferred rate and still others may have their exchange rate determined by contract) and you can begin to see how what could be considered a simple service definition can grow significantly in complexity. 

It may be that our enterprise's public website team first recognizes the need for a currency conversion web service, and it chooses to define this service with a straightforward interface implemented against a standard exchange rate feed. This service could serve as a "version 0.9" implementation for a more strategic service definition that incorporates complex look-up algorithms based on customer type, contractual obligation and so on while still preserving backward compatibility for users of the service's basic conversion functionality. This enhanced service becomes part of the formally supported SOA services suite available for use by new SOA-based projects within the enterprise, and our original website project eventually migrates to the new service as part of its ongoing application maintenance strategy.

Conclusion

Agile development techniques can contribute to the value of SOA as part of both service production and consumption. Between these two perspectives, however, architectural guidance is critical. Teams must pay attention at the architectural level to guide the produced services towards support of coherent business architecture, while still enabling the rapid and iterative development of business applications that is the hallmark of successful agile development teams.
 

About the Author

Brent Carlson, recently named to InfoWorld's 2005 Top 25 CTOs, is Vice President of Technology and Co-Founder at LogicLibrary, Inc. (www.logiclibrary.com). He is a 17-year veteran of IBM, where he served as lead architect for the WebSphere Business Components project and held numerous leadership roles on the "IBM SanFrancisco Project." He is the co-author of two books: SanFrancisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey) and a frequent presenter at industry conferences and regional user groups. Carlson holds 16 software patents, with eight more currently under evaluation.