Stories As Services

For SOA to have business impact, there must be less focus on the "architecture" and more focus on the "services" part of the SOA equation. The Agile technique of expressing requirements as independent, coarsely-grained statements of useful business functionality (called "stories") lends itself to the definition of useful services. For example, the requirement "I as a bond trader want to be able to analyze risk of my commercial bond portfolio so I can make trades that hedge my risk" can be immediately conceptualized as a service that would immediately add value to any number of investment applications. 

The discipline of agile requirements definition provides useful guidance to well-formed services. Quite often, services are too finely grained and create an overloaded, unmanageable catalogue (e.g., cluttered with functionality such as "add a customer address") or

The notion of a framework that allows components to be easily assembled to create business value in relatively little time has long been an unfulfilled promise of many component architectures. Prior approaches - including SOA to date - have offered up little more than solutions in search of problems. The reality is that developers, working within real-world constraints of limited budgets and time-to-production obligations, are more focused on the ends than the means. Furthermore, new system development and legacy systems are not conceptualized as services but as large chunks of functionality, typically defined at the user-interface or panel level. As a result, grafting "services" over legacy systems often requires restructuring of those legacy systems or cobbling together legacy code into makeshift, malformed services.  Regardless, the approach creates inconsistent points of system interaction. Given this reality, the mass definition of services across an existing portfolio of applications is not economically feasible; it is also not a logical gamble for future return on investment. 

In the business context, system integration is substantially an efficiency investment and does not typically create business value (e.g., it does not typically produce new products or services that increase revenues). There are real business pressures to drive IT efficiency, particularly in low-impact expenditures. The raw cost of custom application integration is estimated to be a $20bn expenditure, growing at 10% per year[1] and the complex integration of applications creates increasing operational and business risk. As business rules change constantly, the polyglot of redundant points of integration are obstacles to efficiency. 

To that end, SOA offers a number of business benefits. In an increasingly integrated and inter-dependent application world, business applications themselves have become more fragile. The frailness of compound, complex application service offerings presents real business risk: tactically, in the form of failed transactions creating operations and IT rework and catastrophically, in the form of lost customers due to inconsistency and unreliability. By comparison, SOA offers consistent, robust, and maintainable points of integration that reduce both cost and risk in business operations and IT. Specifically, by consolidating business logic, the probability of inconsistent transactions drops significantly as different systems are executing the same rule base. In addition, consolidated points of integration lend themselves to comprehensive testing. As a result, having fewer, highly tested points of integration yields greater confidence across the entire chain of integration: services are well-formed, services are consumed by applications in a consistent manner, and applications are less likely to fail outright in execution or execute in error. Furthermore, changes to business rules are reflected with confidence simultaneously throughout the entire chain. In sum, clearly defined and tested services create high-quality resilient solutions. 

While complete solutions built entirely from components will remain elusive for some time, SOA facilitates component-based functional thoroughness of applications. As the portfolio of well-formed services takes shape - that is, the inventory of coarsely-defined, valuable units of business functionality grows within an organization - complex application functionality is more easily provided and can be immediately leveraged to provide incremental business benefit. With SOA, chunks of valuable business functionality are incrementally and reliably integrated, reducing the time-to-market of new functionality. 

Getting Started

There does not need to be immediate critical mass of services nor expensive IT infrastructure for there to be immediate business impact of SOA. SOA is best implemented in an agile manner, creating greatest business benefit by implementing highly valuable services quickly using inexpensive infrastructure.

Begin by identifying a service with obvious business impact. For example, a bond trader might benefit from the ability to analyze the risk of a commercial debt portfolio so that the firm can make better hedge decisions. This is conceivably useful to traders, clients and business partners in a number of application contexts. This functionality can be defined as a service and made available on an Enterprise Service Bus (ESB), many of which are available under open-source licenses. Publishing the Web Services Description Language (WSDL) to an intranet and company extranet - supplemented by internal and external promotions - publicizes the availability of the service. Because services can be consumed by a variety of development platforms including Java and .NET, as well as user applications such as spreadsheets, a highly valuable service is likely to be aggressively consumed.

In this example, the existence of a highly tested service quickly leads to a "trusted provider" of bond risk analysis. In and of itself this engenders business agility: this service can rapidly be made available in a number of contexts. Responsiveness to changes in the business environment, then, increases in direct proportion to the growth of the catalogue of services that create business impact.

The point is to begin not by taking an arbitrary definition of services, but to iteratively implement service architecture around well-defined units of business functionality. The driver - the domain of services - is addressed iteratively and not as an exercise of big, up-front SOA design. Implemented in an iterative fashion, SOA isn't an unused or academic initiative but a preferred mechanism for development. Subsequently it becomes ingrained and durable in the environment and becomes a key contributor to greater business agility.

Conclusion

There is a symbiotic relationship between business agility and SOA: producing small blocks of complete business functionality capitalizes on the Agile practices of testing and business-oriented requirements capture. SOA also reinforces some of the core values that define an agile organization:

• Eliminate waste by stressing the re-use of coarsely defined services.
• Allow for the maximization of return-on-technology-investment.
• Create build integrity through greater application resilience.

For the agile organization, SOA is a target state of application development, providing the framework for the incremental exposure of leverageable, resilient and valuable business functionality.

About the Author

Ross J. Pettit has over 15 years experience delivering complex development projects and managing multi-national operations as a developer, manager, and consultant.  He holds a BS in Management Information Systems and an MBA.  He is currently consulting to global clients implementing Agile practices as a Client Principal with ThoughtWorks (www.thoughtworks.com).  

Error, missing joomlaboard config file!

 [1] Source: Forrester Research

Comments (0)

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close