The simplified integration promised by Web services poses some potentially drastic changes for IT departments. That's why we asked industry analysts what changes they think will affect IT the most. Surprise—it's not the technology.
Get a jump start
Although user organizations will sometimes develop their own Web services, more typically they will consume Web services from providers such as Microsoft, Oracle, IBM, and Sun. We also anticipate the introduction of lower-level Web services from third-party providers. For example, while Microsoft will retain proprietary control over high-level services such as its Passport single sign-on and user information capture facility, it will accommodate third-party developers creating lower-level services for the .NET environment.
To exploit Web services effectively, application development groups need to adopt modern componentized programming models for in-house application development. Organizations still writing monolithic programs in C or COBOL will not be able to easily incorporate Web services components.
Although implementation of Web services is still a year or more away, enterprises need to start mastering the new Web services protocols and technologies to understand how they can be used for business advantage. As a first step, advanced technology groups should review the extensive information and downloads offered at the major vendors' Web sites and begin experimenting with these technologies.
Companies must also develop IT infrastructure to support Web services, using environments like Sun's Java or Microsoft's COM+/.NET as they are meant to be used—not as just another way to build silo applications. Also, IT operations groups need to develop and refine the Internet skills required to run and maintain applications with embedded Web services, such as security.
Check out CNET Enterprise Business
This article appears courtesy of CNET’s Enterprise Business section, where you can explore IT business solutions on various topics, including ASPs, Linux, groupware, information systems infrastructure, and supply chain management.
New skills needed
The impact on IT departments comes in how this delivery of software-as-services can shift costs, simplify process integration, and change the balance of skills in the organization. The reliance on Web services standards simplifies integration because it reduces the number of options necessary for connecting systems. This does not reduce cost and time of integration efforts to zero, but it can enable an IT department to improve its systems integration rather than having to rely on outside contractors to do integration on a time-and-materials basis.
Although the potential benefits of Web services are great, the risks of moving to a service-oriented world also exist. Service providers must be given a certain amount of trust, and with no frameworks around with which to build trust, this can be a risky proposition. Therefore, the primary services that are used will come from private communities of companies trading with each other. This means that companies will be reluctant to extend their catalogs and business processes into a public domain for quite some time. IT departments will have to solve the problems of security, trust, privacy, and sourcing when selecting which services should be used. Furthermore, IT departments are not accustomed to service-oriented systems, which require a flexible, dynamic mind-set—much like client/server and Internet computing did at their start.
Web services require a rethinking of systems—if not a redesign. For enterprises to succeed at Web services, they need to embrace the concept of SODA (services-oriented development of applications). SODA requires developers to work with dynamic modules of services rather than static code.
Too early to commit
Web services are one of the most perplexing technologies of the year. Many IT managers understand that Web services can improve their infrastructure, increase return on investment, and decrease deployment time, but they are afraid to commit because the market is too young and they don't know which vendor to trust.
The bad and the good
Con: The vendors are changing. Major players in this area include Sun Microsystems (Java), Microsoft (.NET initiative), IBM, and iPlanet, as well as niche players such as SAP, which announced its own Web services at Sapphire '01 in June. Customers have trouble separating fact from fluff, which makes it difficult to commit.
Con: The technologies are in flux. Java technology is mature and well accepted. IBM uses Java 2 Enterprise Edition (J2EE). Microsoft has come out with the .NET architecture, which is immature but may hold promise. Even though it doesn't quite exist yet, many managers are adopting a wait-and-see attitude toward .NET so that they cannot be accused of choosing unwisely. Additional confusion is added by the immaturity of technologies such as SOAP and UDDI.
Pro: The potential for cost savings with an out-of-box solution can be huge. After some of the major implementation debacles of the last few years, most companies understand the value of a short implementation time. If they can purchase a product that promises quick returns and a lower IT investment, they have a hard time ignoring it.
Technology issues with Web services are relatively simple compared to the business issues, and therein lies the greatest challenge for IT managers: ensuring appropriate and robust Web services implementations by keeping development teams focused first on the right business issues. The basic idea of Web services is simple: use widely supported, Internet-friendly technologies to connect your systems with customers, partners, and suppliers—no matter what technology is used for the systems on their end. But the business issues mount rapidly.
With vertical industry standards for Web services yet to develop, which Web services design has the greatest likelihood of adoption by your partners? How will your systems use dynamic registry lookup without committing you to unknown, untrusted business partners? If your primary partner's Web service isn't available when you need it, do your business policies require you to retry after a time or failover immediately to an alternate service? How will you and your partners test Web service connections before going into production? Will Web services be used simply to more efficiently do business that you already do, or will they be used to open new business models and opportunities? Will you implement Web services while standards are immature and adoption is thin or wait until more of your potential partners are Web-services ready?
Beyond building the right technology skills for their team, IT managers will have a much greater challenge leading teams to anticipate and address the new Web services spin on business and design issues.
Will Web services affect you?
Are Web services a big deal for programmers? How will you prepare for “services-oriented” development? Send us an e-mail with your thoughts and suggestions or post a comment below.