[Christopher Koch]Is SOA Another Fake Path to IT Agility?

先看到本文的译文版，SOA：通往IT敏捷性的又一歧途？(AMT吉少华 编译)，译文链接：
http://www.amteam.org/bacohome/amt_erp.asp
刚开始没弄明白敏捷性指的是什么，个人觉得Agility译为灵活性更好一些。

I'm concerned that in all the talk I hear about IT agility these days, IT is launching itself down the path of failed expectations yet again. Everyone agrees that speed is what IT needs today. A recent survey by the Business Performance Management institute found that the number one thing business wants from IT today is quick, flexible and responsiveness in application delivery.

And it is equally clear that IT is not fast enough. The same survey found that only 11.2 percent of respondents could keep up with business demand to change processes. Worse, some 36 percent report their company’s IT departments are having either “significant difficulties” (26.6 percent) or “can’t keep up at all” (9.2 percent).

The survey also found that IT faces a huge backlog of processes that need fixing. On average, 40 percent of all core business processes are currently in need of IT attention.

The theory is that if only IT could become more agile, IT could eliminate the backlog of applications and businesses could get what they want. But what does agility really mean? And what must IT go through to achieve it? I fear that this is becoming yet another buzzword designed to gloss over the intractable issues that IT has little control over: aging application infrastructure and organizational bureaucracy.

Service Oriented Architecture is hailed as the conquering hero of agility--indeed, I've done my own share of reporting about the broad enthusiasm that the analysts and vendors--and some CIOs who work in corporate bureaucracies that love IT (such as telecom and financial services, where IT is often the product itself)--have for the concept.

SOA at least addresses the new reality in those highly aligned, super-powered IT companies today, which is that business is no longer merely dependent on technology; business is now “embodied in your technology,” as Forrester analyst Randy Heffner puts it. To make a change in the business, today, you gotta change the technology. If the technology is inflexible, changes in the business will be that much slower, ultimately affecting the business’s competitiveness.

The top factor limiting its ability to improve business processes, according to the survey, is lack of time and resources (47.7 percent) followed by limited budget (41.5 percent). Lack of business comprehension and process understanding were a distant third and fourth, at 26.8 and 26.5 percent, respectively).

So it follows, theoretically, that if you reduce the time that IT spends on changing business processes, or improve the productivity of the people doing it (or both), IT would not feel so much internal pain and the cluelessness about process (remember that fixed variable of corporate bureaucracy) would be free to come to the fore.

Backers of SOA seize upon this productivity possibility by touting the advantages it brings to the software development process. Build a composite application that is swaddled in web services and you have abstracted your code high enough away from the infrastructure to make it reusable in multiple contexts.

Reusability then, is the productivity driver that will create agility. I haven't found any really hard numbers, but the estimates that people keep throwing out is that if you can reuse these chunks of code in software projects you can reduce the effort required by up to half.

But now I'm starting to hear that the predictions that people had about reusability aren't panning out. I've seen some early stats that say only 10-30 percent of services are being reused.

Second, I think the rush to reuse tends to overlook the complexity of figuring out how to build these composite applications so that enough people in different divisions around the company can make use of the service you have designed (again, here's that silent menace of bureaucracy rearing its ugly head again--how are you going to find out what business people want in those different areas of the business and then get them to use it?).

Another argument for the service-oriented style of development is that it makes the service easier to change, even if you don't reuse it. A service, with its loose integration and separation into different business functions (like "get customer" or "credit check"), is easier to "upgrade," for example, than a traditional monolithic application where all those different functions may be tightly integrated together and may all need to be changed even if you just want to tweak the credit check process. But I'm hearing too many stories in my story research from architects who talk about how hard it is to design a good service and how they have had to rewrite them. I'm not trusting this "improved changeability" assertion yet.

And let's not lose sight of the fact that all we've talked about so far is development methodology--the tactical piece of SOA, the piece that's been around ever since object-oriented programming came along. Service oriented development assumes nothing about why you're doing it in the first place. Is there a business reason to rewrite code, or is it simply assumed that this development methodology will automatically lead to benefits? The architects I've spoken to who have done this work say there is absolutely more work involved in creating a good service-oriented application than there is in doing traditional application integration (surveys show consistently that SOA is being used for traditional application integration at most companies). So there is actually an extra cost being generated by SOA development up front. For there to be a benefit from that work, therefore, it must eliminate work somewhere else, because the methodology in and of itself does not create business benefit.

That's why it's important to understand that there are two important components to SOA's promise of agility: the tactical development piece and the strategic part, which has to do with figuring out how the organization can take advantage of the development methodology to bring about real business benefits. This second part seems dodgy and susceptible to the forces over which IT has limited control: applications and bureaucracy. For business unit leaders to buy into SOA, they have to see the business benefits they are going to get for the extra project cost and time that doing service-oriented development entails.

Jeff Gleason, director of IT strategies for TransAmerica Life Insurance Company rolls his eyes. "I’ve heard this a hundred times, where a business sponsor said, 'Well, if you’re going to make me pay for creating this service the first time, you just blew away the cost benefit of my project, and it’s not going to get sponsored. And so I want you to go ahead and hard code it because I need that functionality.'”

Gleason changes those peoples' minds by showing how many times that potential service has been hard coded in the past, how much it is costing to support all the extractions and data storage feeds and how all that will go away. But it will only go away if Gleason knows how other business units will want to use the service he proposes to build. That means understanding all their different processes and getting their permission to fiddle with their systems--which, according to Gleason, meant he needed the CEO to demand cooperation from the different business units.

This is the real cost of SOA-based agility. Lining up the organization, understanding enterprise business processes and getting buy-in on enterprise sharing.

Isn't this what IT has been trying to do for the last 20 years?

More importantly, if that's the real cost, it reveals entire categories of companies for whom such an effort will have significant ROI challenges. Some big categories come to mind: small companies already locked-in to a single vendor and networking platform (Microsoft, of course) and companies that have made a big bet--say 80-90 percent of the software infrastructure--with a single enterprise software vendor--SAP for example. On the flip side, companies with many duplicative systems or a penchant for frequent mergers and acquisitions may have an easier time proving the case for the strategic side of SOA, in which case they are also proving the case for enterprise architecture, a centralized development methodology and a centralized staff of project managers, architects and developers. After all, you can't have reusable services if every department builds them differently, from what I'm told (there's that bureaucracy thing again).

It seems like organizations have to look at the two pieces of SOA, the tactical development piece, and the strategic business process piece, and consider them each in isolation and then together. I've come upon CIOs, for example, who have seen a value to service-enabling a particular process but who are much less sure whether they can ever afford to build an architecture around it. In which case, SOA is an opportunistic, perhaps isolated, adventure--a programming trick--rather than a strategy. I've seen other cases where CIOs talk about services being reused dozens of times across different business units to enable quicker product introductions (again, I'm talking about the superstars in telecom and finance, here). They think the investment they have made in SOA has created that thing called agility. In which case, we're not talking about programming at all, but a dramatic organizational shift that may not be cost-effective, or even feasible, for many organizations.

All the surveys I've seen all say CIOs are taking SOA seriously. They are doing it or planning it. And they believe it will have dramatic strategic implications. In a recent CIO/Computerworld survey, for example, 77 percent of respondents said SOA will bring greater business flexibility. The question is: Are they planning to do it because they think it is a shortcut to this agility thing--that it will somehow magically allow them to do an end run around the old foes of application infrastructure and corporate bureaucracy? If so, they may be in for a surprise.

 原文链接： http://blogs.cio.com/node/261