Reuse and SOA Benefits

Post by "WilliamLuo", 2006-11-12, 12:02
-----------------------------------------------------

From: Li Qiang

Subject: <MO Architect Reading> SOA and the Reality of Reuse

很多人认为SOA能够带来最大的好处之一就是重用，事实是否如此呢，请看David Chappell的观点。
Via：http://www.davidchappell.com/HTML_email/Opinari_No16_8_06.html

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: "lease 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 Benefits Some 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 Services When 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.

其它观点：
http://devhawk.net/2006/09/19/A+Question+Of+Context.aspx
http://blogs.zdnet.com/service-oriented/?p=699