- 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.
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