SOA Value: Reuse or Agility?
By Bob Rhubart-Oracle on Feb 29, 2008
In SOA Spending Up, So Where is the Value?, Dave Linthicum makes an interesting point about the value of reuse in the overall SOA picture:
The core issue is that reuse, as a notion, is not core to the value of SOA…never has, never will. Not that you won't achieve reuse, and that there is benefit, but that the value of agility, or creating an architecture that's changeable around the needs of the business is far more valuable than any services you can share.
Dave's post drew this comment from Rob Coventry:
Isn't the whole point about agility delivering value without building completely new systems from scratch and leveraging what works? Consequently, it's hard to separate reuse from agility.
There's a chicken/egg aspect to this debate that I find fascinating.
What gives SOA its agility is the packaging of chunks of application functionality as services. That packaging, in conjunction with the architecture, makes it possible for services to be combined in innovative ways to solve business problems. But that packaging also makes those chunks of functionality reusable.
So maybe the issue isn't reuse, but reusability. (If hair-splitting were an Olympic event, that statement might qualify for a gold medal.)
Isn't it reusability that gives SOA its agility, the idea that the various chunks can be easily plugged together and rearranged to meet evolving requirements?
Isn't a service deployed in an SOA, by definition, reusable? If it provides the functionality necessary to fulfill a particular requirement, why wouldn't you use it? And if If you do, that's reuse, and that's black ink on the balance sheet.
Dave is dead-on in his assertion that the focus should be on building and maintaining an agile architecture. But the agility of that architecture is based entirely on the ability to mix-and-match services in the composition of applications in response to changing business needs. Can that happen if those services aren't reusable? So Rob is dead-on as well. Give those guys a cigar.
In maintaining the agility of that architecture, it's important to know what services are on hand, and what services you need. That knowledge is inextricably linked to the value the SOA can generate. If you don't know what's available, you might build a service you don't need, so you end up with two services that do the same thing. That's a red ink exercise.
From a functional standpoint, your SOA might work just fine with two services doing the same thing. But from a financial standpoint, haven't you wasted resources on building a duplicate service? Aren't you continuing to waste resources on maintaining that duplicate? Is there any question that this is going to affect ROI? That kind of financial hit is exactly the kind of thing that effective SOA governance can prevent.
The bottom line is that agility is indeed the ultimate goal of SOA. But while it may be true that you can have an SOA without reuse, can you have an SOA without reusability? And if reusability is a key aspect and benefit of SOA, doesn't it make sense to take advantage? The cumulative value of the reuse of individual services in a well-governed SOA can add up to some major coin. But that won't happen unless reuse is part of the overall objective. When you do SOA, you don't have to do reuse, but why leave money on the table?