Quelle: Darwin, USA
Admit it. you were tempted to skip this story because a)you have no idea what Web services are or why you'd need anessential guide to them; b) you're vaguely familiar with Webservices and think the topic is so technically esoteric thatonly your IS department needs to worry about it; or c)you've heard so much hype about how Web services willradically change the way companies do business that you'recertain the technology's been vastly overrated.
Well, it's a good thing you've decided to read on. BecauseWeb services do represent a fundamental shift inthe way companies build and use software. They canmake it easier to link complex business systems, saving yourcompany time and money and, in turn, letting it respond moreflexibly to business demands. You must learn thebasics about Web services - even if you'll never have towrite a single line of code yourself - because businessexecutives have a crucial role to play in ensuring thesuccess of any Web services strategy. And trust us, youwill need a Web services strategy, because Webservices won't just fade away.
This story will help you understand what Web services are, how theywork, why they won't be the answer to every technology problem andwhat responsibilities a business executive has in shaping a company'sWeb services plans. We promise to keep the gnarly tech terms,three-letter acronyms and unadulterated hype to a minimum.
What are Web services?
One of the more confusing things about Web services is the very termitself. The word services conjures up visions of people paying forsomething and getting something back. But at the most basic level, Webservices are just a new flavor of standards-based software technologythat lets programmers combine existing computer systems in new ways,over the Internet, within one business or across many.
Web services let companies bridge communications gaps - betweensoftware written in different programming languages, developed bydifferent vendors or running on different operating systems.
An example here might help. The Bekins Co., a Hillside, Ill.-basedcompany that handles logistics and transportation for manufacturersand retailers, relies on a network of trucking partners to ship tonsof big-ticket goods coast to coast. It needed a faster and morereliable way to let its trucking partners know about excess freightsitting on the loading dock, waiting to be shipped - faster thanphoning and faxing. Until recently, getting Bekins' mainframe-basedscheduling system to talk to its partners' transportation managementsystems would have meant painstakingly hand-coding links to eachone - years of work. Yet by using Web services, Bekins was able to letits system talk to any of its partners' systems - and to let thosepartners talk back - over the Internet. And it was able to do that injust three months.
That sounds simple enough. But to add to the confusion, you'll hearthe term Web services used in several ways. It describes the overallapproach to stitching software programs together and building newsystems over the Internet. It can refer to the specific software thatlinks two or more systems; you could say that Bekins "wrote a Webservice" to share information with its partners. People talk about theday when companies will be able to "rent" ready-made Web services fromother companies - and the day when consumers will eventually be able tosubscribe to Web services too. What unifies all the term's uses is the notionthat Web services run over the Internet - or Internet protocol-basednetworks, such as intranets - and are built on a specific set ofsoftware standards.
Why are Web services receiving so much attention?
The technology is drawing such huge hype because it promises to makeit easier for companies to integrate software and reuse software thatthey or others have already built, historically an expensive andtime-consuming process.
Why do Web services hold such promise? First, they run over theInternet, which pretty much every company is connected to, and overintranets or other Internet protocol-based networks, which are commoninside companies. Second, major technology vendors, including BEASystems, Hewlett-Packard, IBM, Microsoft, Oracle and Sun, have agreedto support a set of standard software technologies that spell out howdifferent computer systems should interact with each other - anunlikely level of cross-industry cooperation.
The Web services approach doesn't necessarily make earlier integrationtechnologies obsolete. But it makes types of integration possiblethat would have been hellishly complex otherwise. Bekins, for example,first considered using a different computing architecture called CORBAto tie its freight scheduling system to its partners' transportationmanagement systems. But Randy Mowen, Bekins' director of datamanagement and e-business architecture, says he found 50-odd standardsthat he'd have to follow, and a dearth of documentation. "We kind ofabandoned it before we got too far along," Mowen says. "It neverreally materialized because of the complexity."
How do Web services work?
In contrast with the more traditional means of integration that camebefore it, Web services offer a more flexible - or "looselycoupled" - way of linking applications. Think of Web services workinglike an old-fashioned telephone switchboard. If Mr. Smith wanted toask Miss Jones out for an ice cream soda, he didn't need a direct wirefrom his phone to hers; he went through the switchboard operator, whoplugged in the connection and then disconnected it when he and MissJones were done speaking. Mr. Smith could also use the same technologyto call Mr. Johnson at the bank. Likewise, if Mowen's programmerswrite a Web service that pulls information from Bekins' freightscheduling system, it can send that information to systems atsuppliers A, B and C; the code doesn't have to be rewritten for eachpartner.
Using the switchboard example, in order for people to communicate overthe phone, parties on both ends need to agree to use standardtelephones, answer their phones when they ring and speak the samelanguage. Web services standards perform similar functions.
The most important of these standard software technologies is XML, orextensible markup language (yes, it is a three-letter acronym, butit's probably one of the most important ones for a business executiveto know these days). XML is a way of describing data that masks thedifferences between disparate software systems and lets themunderstand each other; think of it as the Esperanto of the computerbusiness. For Web services to work, both sides need to be able tospeak XML.
One important thing to remember is that Web services aren't used tobuild new systems from scratch. Rather, they're a tool to use withexisting computer systems that you want to stitch together to createsomething new. "You still need your customer relationship managementapplication, your core database, your application servers," says EvanQuinn, chief analyst at the Hurwitz Group, a consultancy inFramingham, Mass. "You still need to have a good infrastructure andrich computing resources. If you don't, Web services aren't going todo much in the business world." So don't ask your CIO if he can usethis newfangled Web services stuff to build you a sales-forcemanagement system. Ask him if he can use it to let your newsales-force management system tap in to information from the accountsreceivable system so that sales reps can find out whether theircustomers actually pay their bills.
How are Web services being used Now?
Companies testing the Web services waters generally tackle internalsoftware integration projects first, chiefly because in-house projectsare less risky and easier to test-drive. "People will integrateapplications, processes, business flow, even content," says Gary Hein,senior analyst at The Burton Group, a Midvale, Utah-based consultancy.At Texas A&M, for example, the IS department wrote Web services thatauthenticate users' identification; it is also working on Web servicesthat would pull information from several legacy applications andpresent it over a webpage so that students can check their schedulesand their tuition accounts online.
Some Web services pioneers have already started to develop externalapplications,which use Web services to connect to trusted business partners.Overall, however, it will be 12 to 18 months before most mainstreamcompanies start building Web services that cross corporate firewalls,Hein predicts.
In the future, how will web services beused?
Perhaps the biggest Web services hype - and the biggestdoubts - surround future uses of Web services. Vendors and analystsenvision a world where companies will list their Web services inpublic online directories. A company might be able to assemble a wholebusiness by piecing together Web services created and maintained byother companies. For example, a company looking for a way to check thecredit histories of its customers could have its order-processingsoftware automatically scan the Web to find companies that offer acredit-checking Web service, figure out which company offers the bestdeal, negotiate it and then hook up to that company's Web service onthe fly - even if the two companies never did businesstogether before.
But David Schatsky, research director and senior analyst at JupiterMedia Metrix in New York City, believes that this expansive hype won'tbecome a reality any time soon. Too many technological and businessquestions remain unanswered: How will security be handled? How willcompanies make sure that the company delivering a Web service willkeep the service up and running reliably? How will companies pay forthe use of Web services? Who will be held accountable if a Web servicefails to deliver as promised? "Using Web services to dynamicallydiscover and interact with business partners - maybe ones that youdon't already have relationships with - is risky," Schatsky says. Andaccording to Jupiter, it's a risk most companies don't plan on takingany time soon; only 16 percent of IT managers interviewed said thattheir companies plan to pursue this type of Web services use bymid-2002.
When are web services a bad idea?
Even when it comes to applicationintegration, Web services aren'talways a good choice. Let's say a company wants to link two softwareofferings developed by the same vendor. There may not be any reason touse Web services, Hein says, since those packages probably alreadyknow how to communicate with each other.
Likewise, Hein says, the Web services approach isn't necessary if acompany is able to dictate certain key parameters that software onboth ends of the transaction will use. In other words, if softwaredevelopers agree that both of the applications to be integrated speakFrench, there's no reason for them to speak Esperanto. And Hurwitz'sQuinn notes that if the applications in question have already beenintegrated in one way and "you have a new integration requirementbetween these applications, it would probably not make sense to useWeb services. After all, you already have the integration facility andexpertise in place."
Another drawback is that today, Web services standards just can'tdeliver the same guaranteed, high-level, bulletproof performance thatyou'd get from traditional business applications. Until they do, youwon't want to use Web services in a situation where transaction speed,reliability and security are of the essence. Vendors are working onnew specifications to address these weaknesses, but it could beanother 18 months before such specifications become standards and getmore broadly adopted, Hein says.
What is your role in planning a web servicesstrategy?
OK, if you're not a programmer, you'll probably never have to write alick of XML. But there are a few things you can do to help get yourcompany ready for Web services.
Be realistic about how quickly your company needs to implement Webservices. Web services won't be something that's hyped and thendisappears, Hein says, but the technology hasn't achieved industrialstrength yet, either. His advice? Don't rush out tomorrow and insistthat the entire company and all its partners change over to a Webservices approach. Instead, keep an eye on the Web services market,which he expects will grow in the next year to year and a half, andstart experimenting internally.
Lend a skeptical ear to vendors' marketing claims. Vendors will go onand on about how they've had umpteen people involved in thedevelopment of XML since 1997, or they were the first to roll out betacode that supports such and such standard. And they'll claim that thishas put them way ahead of their competitors when it comes to Webservices support. Take those claims with a grain of salt. "It's tooearly in the development of Web services to make a strategic call onwhich vendor is the best to wed yourself to," Schatsky says. The beststrategy is to work with a vendor that you already have a relationshipwith until the market matures.
Make sure that your company's up-coming business applications supportWeb services standards. "Business managers may not make decisionsabout platform choice, but they do often get heavily involved in theselection of business applications," Schatsky says, such as enterpriseresource planning or customer relationship management systems. Headvises executives to add Web services support to the checklist ofthings they'll need from business application vendors - most will offersuch support by late this year.
Recognize that deploying Web services is as much of a business problemas it is a technology problem. Yes, vendors will roll out more Webservices-enabled software and (one hopes) agree on more sophisticatedstandards. But companies won't be able to point and click away thehard work of deciding which computing resources should be integratedinternally, which ones should be shared with partners and which shouldbe opened up to consumers. "Just because you have an easier-to-usetechnology doesn't mean you change the world's business modelsovernight," Quinn says. So while the IS department is experimentingwith internal uses of Web services, business executives should bethinking about future business opportunities afforded by thetechnology.
Web services are undoubtedly a work in progress, and thegrand Web services scenarios envisioned for the future won'thappen without a serious bit of work on the technology sideand the business side. But if you start experimenting withsimpler Web services now, you'll be in good company - andyou'll also be ready when Web services really start to takeoff.