By Gary Bolles

Technology: Web Services




You're studying a whiteboard drawing of your company's information technology backbone, and your eyes are starting to glaze over. You've got a spaghetti-like maze of Internet connections and older, legacy networks and systems that fairly screams with complexity and inefficiency. You talk to a Web services vendor, and suddenly you discern a brilliant set of connections between systems that can rescue valuable information from the burial grounds of obscurity—as if all you had to do was provide simple links between systems to let them "talk" more rapidly and efficiently to each other.

Sound too good to be true? In some cases, it may be. Vendors may smooth-talk you into thinking that it's easy to administer new software known as Web services, designed to allow different computer systems to communicate seamlessly through the Web: Simply layer them over your poor, balkanized legacy systems, and suddenly everything connects. It's not easy to find anyone who will speak negatively about Web services nowadays. But buyer beware. Though many companies, from General Motors Corp. to Aetna Inc., are testing Web services software—touted by some as the next big wave of the Internet—technology analysts and companies alike are finding it's not quite ready for prime time.

Why bother with Web services at all? In many situations, the software can speed access to information that your company has bottled up in legacy systems and increase communication between the various departments of a company. Further, Web services can be fairly easy to install—if you have a newer infrastructure without layer upon layer of legacy systems. Because Web services are nimble, says Whit Andrews, a research director at Gartner Inc., companies that have small IT departments and "are aggressive at adopting new technology should absolutely deploy Web services today."

Indeed, according to IDC, the Framingham, Mass.-based technology research firm, the worldwide market for Web services is projected to rise at a torrid clip to $21 billion by 2007 from $787 million last year—despite the economic downturn. Technology consultant A.T. Kearney Inc., says 70 percent of all companies are at least experimenting with Web services, with more to follow. But to justify the investment, it's essential to know the kinds of tasks you'd like the new system to deliver: Believe it or not, many companies have charged into Web services based on the promise of simplicity and efficiency, only to discover later that a lack of strategic planning at the top was limiting success.

Which companies stand to gain the most from Web services? If you have legacy data locked up in older applications, and those applications support frequently changing business processes, then Web services are, at least, worth exploring. According to Alejandro Danylyszyn, senior manager for e-technologies integration at Deloitte Consulting, companies with complex supply chains, or which regularly hand off data between systems—financial services, energy trading, high-tech manufacturing and telecommunications, to name a few—are also ripe for Web services. However, says Danylyszyn, in order to switch over to Web services widely throughout the company, "you're going to have to solve two common problems of early technology adoption: security and performance."

Security standards—which would ensure common ways to verify the authenticity of applications that invoke Web services—are not widely supported. And "wordy" standards like XML can slow Web service performance, since long sets of instructions need to be interpreted along the way. Another drawback: Web services may not be cheap. "Like any investment in technology, you have a high [cost] curve upfront," adds Danylyszyn. "After that curve starts coming down, that's when the payback period begins. Many companies, especially in this economy, are not willing to make that hump at first." If you have to purchase a development environment and Web services platform servers, train programmers who don't know object-oriented coding, and migrate a large number of applications, Web services may require a substantial investment.

In some cases, Web services may end up being simply another much-ballyhooed technology in search of a solution. "The business vision should be driving where you need to implement Web services, instead of saying, 'Hey, there's a need for Web services here,' and trying to identify how to use it," says Chee Yuen Yap, CIO for JTC Corp., a developer of industrial real estate in Singapore.

Tell your business constituents:

We need a clear and strategic vision of the kinds of services you need.

Ask your data management guru:

How hard is it now to pull together the business data that our company needs?

Ask your development team:

What would it cost to create a Web services system that works?



Developing one Web service can be relatively straightforward. Linking a few systems together may not require much work. But beyond simple point-to-point connections, you'll need to update your enterprise architecture to make sure that you have the kind of framework Web services require.

The first task is to assemble a coherent picture of your enterprise architecture as it exists today—something not all companies may have. If you want to make a major commitment to Web services, analysts and IT executives familiar with Web services say, you'll have to shift your architecture from any kind of "black box" legacy applications approach—with data and code operating in silos—to a services approach. You'll have to design your architecture to provide unique business capabilities to the people inside your company who need them most—and do it in the form of individual services that can be reassembled in different ways.

If your company isn't interested in shifting to a services approach that would offer up applications as plug-and-play components—and if you haven't already adopted application services as a "must-have" part of your company's architecture—you should probably stay away from any major installations of Web services, at least for now. "If you have had a coherent development of your IT architecture, you can use and deploy Web services in a better way than if you have a 'spaghetti' architecture," says Marco Bernardini, chief technological architect at Consorzio Operativo Gruppo MPS in Siena, Italy, a member of a large European banking conglomerate. Using technology from Avanade Inc., a joint venture between Accenture and Microsoft Corp., Bernardini says his company is now moving between 5 and 10 percent of all intergroup transactions through Web services software.

For some IT shops, of course, the idea of setting up a services architecture is nothing new. Dan Demeter, CIO for recruiter Korn/Ferry International, said his company's long-time services approach helped make the process of linking his company's Futurestep service to Yahoo!'s recruiting portal a snap using Web services. But if your infrastructure hasn't already been adapted to a services paradigm, be ready for some heavy lifting. "It's not just about building a new application," says Corey Ferengul, vice president at Boston-based META Group Inc., the information technology research firm. "It's about creating a new architectural design."

Ask your top architect:

How easily can our architecture support a services approach?

Tell your application development team:

We need to determine how we'll manage Web services before we broadly deploy them.

Tell your business constituents:

We're moving toward building a more flexible architecture, which will let us more rapidly respond to your requests for new services.



Look before you leap. "You don't go buy a box of Web services," says META's Ferengul. Though rapid progress has been made during the past year to define standards, there is still a list of problems dogging Web services, and it's often up to the IT department to figure out how to solve them. "People who really need advanced Web services—security, transactions, reliable messaging, routing—are also the people who should want to take a wait-and-see approach," says Adam Sohn, product manager for Microsoft's .NET strategy group, which is developing Web services software and tools for business.

Plug and Play chart

On the security front, where Web services aimed at easing company-to-company communications may threaten sensitive corporate data, companies are using Virtual Private Networks and other add-ins to create a security shield. But that's a patchwork approach that can be quickly stretched beyond the point of practicality, analysts say. "We advise companies to expect that they will see substantial security failures…in their Web services implementations," says Gartner's Andrews.

What to do? Focus your Web services projects on applications that are already protected by the corporate firewall, and, over time, phase in your Web services exposure to partners and customers as security applications develop.

If you're planning any kind of large-scale rollout, you'll also have to decide how you'll manage your Web services. Watch how they perform and make sure that nothing breaks as you load up on transactions. These services are increasingly used in a production environment, which can mean cobbling together third-party applications, such as TeaLeaf Technology Inc.'s IntegriTea, which is designed to help spotlight a potential Web services failure.

But given the lack of management standards for Web services, it's best to assume that pieces will be missing. "Right now, Web services management, while critical for a strategic Web services implementation, is really something for the adult swim period," says Gartner's Andrews. "The most visionary enterprises today are thinking about managing Web services before managing a problem."

Does it help to bet on one vendor's platform, such as those from IBM, Sun Microsystems Inc., or Microsoft? "There are too many choices in the marketplace," says Deloitte's Danylyszyn. Each vendor, he says, has a different approach and a different infrastructure for Web services deployment. "There's no right answer," Danylyszyn says, "because there's no one-size-fits-all." Also, not all vendors are providing the right kinds of links between Web services and legacy applications. "We are still using batch mode communications with our back-end systems because the vendor hasn't provided the Web service capability for us to call them directly," says JTC's Yap.

Therefore, if you want to resolve all of these issues quickly—while hoping new standards will become rapidly infused into products—you may need a healthy dose of patience: Analysts say you shouldn't expect to see an end to the standards race for at least another two years.

Ask your development team:

How far can we stretch our security scheme to safeguard Web services?

Ask your management guru:

What problems could Web services create for us?

Ask the major web services vendors:

What switching costs might I incur if I choose to migrate from your platform later on?



Web services require your development team to think in terms of objects. That's not a problem if they're already thinking that way. But chances are, you've got some work to do with your more traditional developers.

First, choose an architect—your chief technology officer, or someone from your chief architect's office—who has substantial credibility with your development teams. Have that person serve as the focal point for your Web services initiatives. Second, give people the resources they need to become educated about the standards, then have them spend time with your developers to make sure they understand this new approach to providing services.

Next, use a small team of developers who can get excited about the potential of Web services to produce real value for the company, such as speeding computer and software code changes so that technologists at your company can respond faster to business needs. But don't expect this to happen overnight. "Web services bring about a new way of thinking about how you build applications," says Deloitte's Danylyszyn. And new ways of thinking often bring change, which is rarely easy to accomplish.

The potential value, say analysts and users, is increased flexibility for the organization—just don't expect it to be completely painless.

Ask your CTO:

How would you manage the cultural changes required to get developers to start thinking of their applications as services?

Tell your legacy systems developers:

This is a great chance to better integrate your systems into applications.

Ask your software vendors:

How easy can you make this migration process for us?

This article was originally published on 04-01-2003