Reuse in Service-Oriented Architectures: This Time It’s Different

At every talk I’ve given lately about SOA, somebody in the audience has questioned one of its most fundamental benefits: reuse. Effective reuse of business-oriented software has been the Holy Grail of development for many years. Why will it succeed this time, they ask, when it’s been so wildly unsuccessful in the past? It’s a good question. Fortunately, there’s also a good answer, and it stems from the difference between object-based reuse and service-based reuse.

The Challenge of Reusing Business Objects

Reuse discussions have been framed in terms of objects for many years, and object-based reuse really has been successful in some areas. For instance, the collections of infrastructure-oriented classes provided by J2EE-based products and the .NET Framework class library are the foundation for most new applications built today. Yet reuse of business software at the class level has proven very difficult to achieve.

The primary roadblocks to reusing business objects aren’t technical. Instead, they grow out of the very human process of building software. A typical example is the quest in many organizations to create a single customer class that can be used by different applications. Standing in the way of this kind of reuse are two big problems:

• Agreeing on a single definition for customer is tough. Getting different business units to agree on even a common base class for this fundamental idea can be almost impossible. Differences in business strategy, customer type, and more block agreement, as do ego-oriented battles over whose view is correct. And even if agreement is reached, businesses change very fast. The right definition today can be wrong tomorrow.
  
• Even if a single definition is created, enforcing its use is difficult. Developers seem to have an instinctive revulsion for using somebody else’s source code. Left to their own devices, most of them would prefer to create their own customer class, and there’s not much of a barrier to doing this. Without attractive carrots and big sticks—clear rewards and punishments around reuse—developers often prefer to reinvent the wheel.

One of the goals of component technologies such as COM and EJB was to increase reuse of business software. Yet the same kinds of problems occur with components. Since the problems are rooted in people, not technology, this isn’t surprising. As long as developers are free to reimplement rather than reuse, many of them will. While some organizations have succeeded in creating significant reuse of their own business objects, they’ve usually had to create coercive management structures to push developers into doing it.

How does SOA solve this problem? The answer is simple: it doesn’t. Large-scale reuse of business objects isn’t likely to occur anytime soon, SOA or no SOA. But the move to a service-oriented world will still result in more reuse of business software. Here’s why.

The Promise of Reusing Business Services

By far the most successful example of business software reuse today is the proliferation of packaged applications from SAP, PeopleSoft, and many others. While commercial attempts to create reusable libraries of business classes have mostly come to grief (IBM’s San Francisco project comes to mind), reuse of entire applications, often with some customization, has worked well. The lesson is clear: reuse business logic in bigger chunks, such as those provided by a single application, rather than in the smaller chunks of classes.

This is exactly what SOA does. Rather than providing objects for a developer to reuse, a service-oriented application exposes services that developers can access. There’s no common customer class, for example, but instead an accessible application that exposes services such as CreateCustomer, UpdateCustomer, and DeleteCustomer. More important, this service provides access to a specific set of data, such as information about a particular group of customers. The approach to reuse is fundamentally different, and so both of the problems of class-based reuse go away:

• There’s no need for everyone to agree on a single definition of customer. Instead, any client that needs to access this application’s customers must conform to the definition of customer that the app’s services expose. If a client’s view of customer is different, it must somehow map that view into the definition exposed by the service it wants to access. While agreeing on a common notion of customer might be nice, it’s not required for the client to reuse this application’s services. Changes to the service can still be problematic, although only externally visible changes are a concern for clients. Unlike object reuse through inheritance, changing the guts of how a service is implemented won’t damage others who depend on this service.
  
• There’s no need for draconian enforcement of reuse rules. If a client needs to access the customer information this application maintains, the only way to do it (in a well-designed SOA environment, at least) is by going through the services the app exposes. As long as the underlying data can’t be accessed directly by any and all comers, a service-oriented approach requires reuse—there’s no other way to get to the information.

An idealized SOA environment provides a cleanly delineated set of services, with one way to accomplish each function. This kind of normalization makes reuse self-enforcing, since each service provides access to a specific group of information in a specific way. In reality, achieving this kind of perfect architecture will be beyond the reach of most organizations. Still, it’s a worthwhile goal to strive for.

It’s hard to see how business object reuse will ever be successful on a large scale. Because SOA takes a different approach, exposing the services of an application in a useful way, it makes reuse of business logic significantly more practical. This time really is different.

• Reuse in Service-Oriented Architectures: This Time It’s Different
   

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David's books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, Microsoft, Stanford University, and other technology vendors and users.

©Copyright2007 David Chappell and Associates
All rights Reserved.