SOA and the Reality of Reuse

Not too long ago, I spoke at a Gartner event where the keynote speaker posed a question to the audience. "How
many of you work for a company that once had a large-scale object reuse program?" he asked. In a room with several
hundred IT managers from the largest American firms, nearly every hand went up. He then made a follow-up request: "Please
keep your hand up if your firm still has a large-scale object reuse program".

Only one hand remained in the air.

I dont think anybody in the room was surprised by this, least of all the speaker. His goal was to provide
a clear demonstration of what everybody knows: the reuse of business objects failed. Despite heroic efforts from
many IT managers, architects, and developers, the cultural and business barriers to reuse were just too great.

Ive spent much of the last two years flying around the world talking with people about SOA. What Ive
heard from virtually all of them is that reuse of business logic is nearly as tough with services as it is with objects.
Even Gartner is now saying that you should expect to reuse only a fraction of your services, maybe just 20% of them.
Yet if service reuse is so limited, how much value will SOA really provide? If an organization reuses only one in
five of its services, why is it building the other four? The one that does get reused had better provide significant
value to make up for the cost of the four that sit idle.

And sometimes it does. In fact, there are clearly cases where services can provide real advantages. Anyone creating
an application that must be accessed in different ways, such as by a JSP front end, a Windows Forms client, and
a mobile device, might well find that building this application in a service-oriented style is an excellent idea.
Letting these various clients access the application via common services will make life simpler for everybody.
Also, as Ive
argued before, if a service provides
the only way to access widely used data, such as customer information, developers who need access to that data
can benefit from reusing this service.

Its also clear that some organizations are able to achieve significant reuse of business services. With top
management support, strong commitment, and diligent effort, at least a few companies are reporting significant
savings from SOA-based reuse. This was also true with object reuse, especially in the early days. Strong commitment
from the top and significant investment can produce benefits. Yet how many firms embarking on the SOA path really
have both of these things? And how many will have them five years into the effort? The reality appears to be
that widespread reuse of business logic through services will be a difficult goal for manyperhaps even mostorganizations.

Reuse and SOAs BenefitsSome people argue that service reuse isnt the only advantage of SOA, and theyre right. But the most touted
benefits of SOA clearly do stem from reuse. The most obvious of these is that reuse can allow creating applications
faster and for less money, since new software can build on what already exists. Sadly, this is exactly the kind of
reuse thats proving to be so difficult. The same issues bedevil everybody:

Creating services that can be reused requires predicting the future. Doing this is very difficulthow can
a services creators accurately guess what future applications will need? Organizations that identify immediate
potential for reuse appear to have had the most success here, since accurate prognostication isnt necessary.
Similarly, firms that are able to consolidate multiple redundant applications or external services into a single
reusable service have reported sizable savings. But the "If you build it, they will come" approach is tough
to turn into real reuse.

If an application does expose a useful service, its rarely exactly what the client wants. There might be
one piece of missing data, for instance, or the service might expose information that this client isnt allowed
to see. The creators of the service can be forced to create myriad variations to satisfy their customers.

Even if one part of an organization does create a service that could profitably be reused by some other group in
that company, the manager who owns this application usually doesnt have much incentive to let this group consume
its resources. Whats in it for her? While some firms address this problem by centralizing ownership of all
reusable applications, this isnt an option in many cases. What business group is willing to give up control
of its mission-critical application? SOA mavens sometimes argue that the entire notion of "application" needs
to change in an SOA world, which certainly makes technical sense. But somebody still pays for each chunk of code
that provides services, and whoever that is wont allow reuse of those services by other groups without clear
incentives to do so. Creating those incentives appears to be more than a little challenging for most organizations.

What about business agility? Another strong argument for SOA is that it makes IT systems easier to change and so makes
the business more adaptable to a changing world. The primary reason for this is that exposed services can make reconfiguring
software much simpler, especially if the services are driven by some kind of easily changeable orchestration. Still,
isnt this just another form of reuse? Arguing that SOA allows easier reconfiguration presupposes that the new
arrangement will use existing services in new ways. Given this, a large share of the business agility benefits that
SOA promises are actually based on reuse. And as with objects, service reuse is proving to be hard.

The Inevitability of ServicesWhen object technology first appeared, it was promoted largely on the premise that it would enable reuse, especially
reuse of business objects. Today, most software uses objects, but not because of their potential for reuse. We
use objects because the major development platforms and tools require it. Objects certainly do have benefits,
but once the big vendors embraced object technology, mainstream developers had no choice but to follow.

Something similar is happening with services. Both Microsofts Windows
Communication Foundation (WCF) and the forthcoming Service Component
Architecture (SCA) created by IBM, BEA, Oracle, SAP, IONA, and others, are aimed at supporting applications that
expose services. Both still use objects, of course, since services model external interaction rather than internal
function, but the reality is that well all be creating service-oriented applications soon. And this is a good
thing, since the move to service-oriented communication has clear benefits. (One big one is that liberating communication
from the object model used in constructing the application makes interoperability much more achievable.) But this
move to service-oriented applications wont happen because those services will be extensively reused. Instead,
as with objects, the major vendors are forcing this shift through the platforms they provide.

Object reuse has been successful in some areas. The large class libraries in J2EE and the .NET Framework are perhaps
the most important examples of this. Similarly, service reuse can be successful in some organizations. Yet the kind
of widespread reuse of business logic thats commonly advanced as a key benefit of SOA isnt likely to happen.
With SOA as with objects before it, the reality is that removing technical barriers to reuse is just the beginning.
The human challenges that emerge once these more obvious problems are solved are more difficult to overcome. Whatever
we might wish, the barriers to pervasive reuse of business logic remain high.

Now Available: Understanding .NET, 2nd
Edition

Version 2.0 of the .NET Framework changed the .NET world in a number of ways. It also gave me a good reason to
produce a new edition of my most recent book, Understanding .NET. The goal of this book is to provide a
big-picture view of the entire .NET world, and the target audience includes developers, architects, IT managers,
and students.

One reviewer of
the second edition called it "a terrific survey of and orientation to .NET technology", another says "This
is a fantastic book, and a must read for developers who need to get to grips with .NET development", and a third believes "its
still the one indispensable .NET book for managers, decision makers, and strategists". If you or the people
you work with need an introduction to the .NET world today, the second edition of Understanding
.NET is now available.

David Chappell is Principal of Chappell & Associates
(www.davidchappell.com) in San Francisco, California. Through
his speaking, writing, and consulting, he helps information technology professionals around the world understand,
use, and make better decisions about enterprise software. David has been the keynote speaker for conferences
in the U.S., Europe, Asia, and Latin America, and he’s also delivered keynotes at many in-house events. His
popular seminars have been attended by tens of thousands of developers, architects, and decision makers in
forty countries, and his books on enterprise software technologies have been published in ten languages.
In his consulting practice, David has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University,
and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business
plans.