Hewlett Packard: Web Services on Multiple Fronts

Hewlett-Packard (HP) is a leading global provider of products, technologies, solutions, and services to consumers and business. The company's offerings span IT infrastructure, personal computing and access devices, global services, and imaging and printing. HP's $4 billion annual research and development investment fuels the invention of products, solutions, and new technologies. The May 2002 merger of Hewlett-Packard and Compaq Computer Corporation forged a dynamic, powerful team of 140,000 employees with capabilities in 160 countries, doing business in forty-three currencies and fifteen languages. Revenues for the combined companies were $72 billion for the fiscal year that ended October 31, 2002. Chairman and CEO Carly Fiorina leads HP, which has corporate headquarters in Palo Alto, California.
HP consists of four core business groups:

• The Enterprise Systems Group (ESG). ESG focuses on providing the key technology components of enterprise IT infrastructure to enhance business agility, including enterprise storage, servers, management software, and a variety of solutions.
• The Imaging and Printing Group (IPG). HP is the leading provider of printing and imaging solutions for both business and consumers. IPG includes printer hardware, all-in-ones, digital imaging devices, such as cameras and scanners, and associated supplies and accessories. It also is expanding into the commercial printing market.
• HP Services (HPS). HP Services is a premier, global IT services team. It offers guidance, know-how, and a comprehensive portfolio of services to help customers realize measurable business value from their IT investment.
• The Personal Systems Group (PSG). PSG focuses on providing simple, reliable, and affordable personal-computing solutions and devices for home and business use, including desktop and notebook PCs, workstations, thin clients, smart handhelds, and personal devices.

In addition to the four business groups, HP Labs provides a central research function for the company. HP Labs is focused on inventing new technologies that change markets and create business opportunities.
Recently merged with Compaq Computer, Hewlett-Packard stands as a global information systems titan. The company is number one in servers, external storage, and printing and imaging in terms of market share. In the services business, HP has moved from around number seven to one of the industry power-houses, sitting at the number three position. The company's personal systems unit continues to sell both HP and Compaq products to consumers and all types of businesses. HP's formidable enterprise systems group includes servers, storage systems, and software. The company vies with IBM, Dell, and Sun Microsystems at the top of the server market, with products based on the Microsoft platform, as well as UNIX-and Linux-based offerings. While HP is best known for its computer technologies, printing and imaging is very important to the company, and it is its most profitable sector.
Mike Baker is HP's information technology officer. Baker joined Compaq in 1990. His initial assignments were in the Compaq Systems Engineering Group, and he has held management positions in the company's IT unit since 1992. Prior to joining Compaq, Baker worked for Baxter Heathcare and American Hospital Supply (AHS). His experience at Baxter and AHS spanned a number of IT management roles, including assignments in system architecture, telecommunications, database administration, and application development. He participated in the development of AHS's ASAP system, a predecessor to today's e-commerce technology.
A strong Web services advocate, Baker believes that the technology and its associated open standards mark the next wave in computing. Baker notes that HP has been deeply involved in Web services almost since the technology's inception.
We have been exploring Web services since early 2000 and have been participating actively in the standards bodies, including W3C, UDDI, WS-I, and so on. Currently, we have a variety of internally and externally exposed Web services in production, including:

• Product configuration and price checks
• Product catalog information
• Payment authorization and fraud checking
• Tax calculation
• Product contract and warranty information
• Field services dispatching
• Enterprise application integration
• B2B integration

One of the attractions of Web services to us is that this is really a standards-based addition that allows a new level of interoperability between applications, both within the corporation and outside the four walls of the corporation. With Web services, because they are based on standards, any individual vendor's product isn't critically important to us. Yes, we make decisions about which particular products to do specific implementations on, but the interoperability we're able to achieve is the key foundation stone.
Most companies recognize that a single ERP solution doesn't provide all the functionality that's needed. The ideal is to implement best-of-breed, composite applications that snap on to an existing heterogeneous IT environment and create seamless, cross-functional business processes. The same is true with Web services. We have currently implemented functionality, as Web services are needed, in many places and by many applications. Even though the data provided is not necessarily new, the way it is encapsulated and provided as central services is. We are also thinking about brand-new business models that could be supported using Web services.
For HP, Web services have provided a new, more effective way to build bridges between applications.
Before Web services were defined, we solved application integration challenges by using vendor-provided application adapters, like BEA eLink services and SAP's Business Connector. We also implemented a ZLE solution (HP's Zero Latency Enterprise real-time integration framework) on Himalaya, which serves as a message hub for important supply chain documents, using the publish once/subscribe many paradigm. Now, the Himalaya integration can be easily exposed as Web services.
Baker appreciates the technically agnostic orientation of Web services.
Web services enable us to implement business functionality in a technically agnostic way. This allows us to select the most efficient technology solutions that leverage our existing investments and provide the easiest integration. We're able, for example, to quickly wrap our BEA eLink integration calls with SOAP interfaces and call them from any hardware and OS platform—without having to spend anything on proprietary messaging middleware. The technical agnosticism that Web services provide reduces the cost of technology investments to reach the business-to-business market, and it enables communication with divergent technologies. It's easy to use and implement.
The modular nature of Web services enables us to leverage the benefits of distributed computing without the technical complications inherent in the currently used distributed object models. The use of Web services for such ubiquitous internal processes as tax calculations, currency conversions, or freight calculations allows for a single source of code maintenance and upgrade when business rules, or needs, change. Any and all applications that require these pieces of business functionality will be able to simply consume the available internally or externally hosted Web services.
The Web services paradigm has the potential to deliver many benefits for internal application integration, as well as interaction with external customers and partners. The Web services framework holds promise in several areas of software development and application integration. In theory, the Web services framework can enable new methods for creating and delivering application functionality, including:

• Modular Applications. Developers can divide applications into smaller components for delivery as Web services software. Higher-level applications can aggregate and orchestrate the flow of data and logic between multiple Web services software components.
• Reuse. Developers can expose internal application functions for reuse by other network end points. A developer can reuse a single Web service software component, such as a sales tax calculator, in multiple application flows. Hewlett-Packard might also be able to purchase or subscribe to Web services, which would fit our buy-versus-build principle.
• Choice. Multiple Web services software components can provide identical application functionality, such as tax calculation. Choosing a different supplier for a particular function should not affect other Web services software components, as long as the interfaces those components use remain the same.
• Self-Describing. At the core of Web services is XML. Documents in XML describe the interfaces, formats, and functions of software components, which humans, applications, or other software components can parse and understand.
• Interoperability Without Dependencies. Because the Web services framework uses XML-based specifications, it doesn't mandate the underlying hardware platform, operating system, development environment, or application server. Thus, the framework is ideal for application and data integration between dissimilar systems. The Web services framework brings these benefits to applications, even monolithic applications that support the framework.
• New Value-Delivery Channels. There are many opportunities for HP to provide new services delivered over the Web, which will enhance user experience and satisfaction. The framework also provides a directory for advertising and discovering applications published as Web services software.
• New Business Models. The Webservices framework has the potential to break down the barriers to interenterprise application interoperability. As such, the framework has the potential to provide the technological foundation for a new way of integrating partners, suppliers, and, ultimately, customers into the business process.

The Web service paradigm is about interoperability and platform-neutral communications, as opposed to a specific development language, component model, and platform issues. This is in contrast to CORBA, COM, and EJB, which allow platform interoperability, but have proprietary component models and binary wire formats for distributed information communication.
Given its deep involvement in Web services, HP is utilizing a diverse array of technologies.
As expected in a newly merged company, we're using several technologies. We have the intention to streamline this portfolio. Since we expect to implement J2EE-based applications as well as .NET solutions, interoperability (provided by using industry standards) is very important to us. These standards include:

• Microsoft Visual Studio .NET and Framework
• Borland JBuilder for J2EE applications
• BEA WebLogic (selected as the J2EE application server technology)
• Borland Control Center (a development platform)
• Eclipse 1.0 (an open-source, integrated development environment)
• Jboss (an open-source application server)

HP is taking a centralized approach to Web services development.
We've created a cross-departmental virtual Web Services Center. It defines strategy, recommendations, and road maps for all aspects of the Web services architecture for Hewlett-Packard IT. In this collaborative, coordinated effort we are looking at specific business opportunities, shared business Web services, central infrastructure components, security, policies and standards, and Web services hosting and management aspects.
Adopting Web services doesn't require completely changing your current infrastructure. We're using an evolutionary approach, wrapping legacy applications with SOAP, starting with sending simple XML messaging over HTTP, gradually moving to a stricter definition of a Web service that adheres to all industry standards. It's important to move to a service oriented architecture first, since components can be easily turned into pure Web services at a later point in time. Implementing a services-oriented architecture requires an attitude change, though. Components need to be designed and developed in a way that allows for sharing.
Baker feels that HP's early Web services investments are already providing a return.
The early adoption of Web services has already paid back—we've developed knowledge and experience. It's now a matter of explaining the value and possible return on investment (ROI) to businesspeople. The definition of Web services has been changing, and it is still not used in the same sense by everybody. In the beginning, we used a very loose definition—every software component that could be called using XML over HTTP was considered a Web service. Now that some basic standards like SOAP and WSDL are out, we can easily turn them into Web services that meet a tighter, industry standard-based definition.
One way HP utilizes Web services is through Comprehensive Web Solutions (CWS), a Web application that allows suppliers that aren't EDI-enabled to receive EDI communications transmitted by HP.
The Web application allows vendors to receive and acknowledge supplier-related EDI signals after logging into HP's secure supplier extranet. The EDI signals are transmitted between SAP and CWS, via XML documents through EIA Services. The XML document structures represent the standard SAP IDOC format.

• Hewlett-Packard generates an SAP purchase order for goods or services from one of its suppliers. The exchange is first initiated as SAP standard Intermediate Document (IDOC). This is translated into an 850 XML document, based on the structure of the outbound IDOC. (This process is also repeated in the same manner for 824 signals, which are acknowledgment signals for 856 and 810 signals received from the vendor.)
• SAP forwards the XML 850 to EIA Services.
• EIA Services sends the XML document to CWS via an HTTP post transaction.
• Comprehensive Web Solutions validates the content of the 850 XML document.
• The validated 850 XML data is passed to the CWS SQL Server 2000 database, where a stored procedure parses and maps the XML document to an in-memory tree structure that represents the nodes in the document. The document's contents are then shredded to facilitate mapping the node's elements to specific tables within the CWS database for record insertion or modification.
• The supplier logs into HP's secure supplier extranet to access the CWS application and is presented with a display of all purchase orders assigned to the company's SAP supplier code.
• The supplier reviews and acknowledges the purchase orders.
• The purchase order acknowledgment data is immediately generated by constructing an XML template to retrieve the data directly into XML document fragments. The data retrieved by the template also applies the signal-specific XSLT style sheet to produce the 855 XML document structure for the SAP IDOC message. (This procedure is also repeated for these additional signals: 856, Goods Issue, and 810.)
• Comprehensive Web Solutions forwards the 855 XML document to the EIA Service via an HTTP post transaction.
• EIA Services sends the 855 XML to the appropriate SAP environment.
• SAP retrieves, validates, and finally posts the acknowledgement.

Baker says CWS marks a big improvement over the technology it replaced.
Previously, these processes were handled by an application distributed to the targeted vendors. Called Harbinger, it was developed by Peregrine Systems. The application was installed on the supplier's system, and it followed traditional EDI processes to send and receive EDI signals in the standard X12 industry standard format. The VAN was still used to broker the EDI signals between HP and the vendor. In some cases, a paperwork solution was still implemented between HP and the vendor.
Comprehensive Web Solutions offers benefits on multiple levels, notes Baker.
Web Services provides several benefits over traditional EDI services. The greatest is bypassing the VAN. The VAN is a third-party interface that brokers the EDI signals between partners. Traditional EDI required HP to FTP the EDI document to the VAN, which routed it to the appropriate vendor's queue. The vendor retrieved the signal when it logged into the VAN. The service provided by the VAN was very costly, and it isn't needed using Web services.
The primary benefits of CWS are:

• Efficiency of development and maintenance, especially when multiple applications must be interconnected
• Design to industry standards (such as RosettaNet), where applicable, to permit exposure and brokering of the services
• Isolation of the vendor-specific platform, so that the implementation can be changed without affecting other applications
• Less complicated support, since all the hardware belongs to HP
• Reuse and knowledge leveraging across multiple architectures, development teams, and projects
• Fast and inexpensive integration of new suppliers, without the need to invest in additional software on the supplier's side

Security is fundamental to CWS, says Baker.
All communications require SSL. User authorization to the Web front end is handled through the supplier extranet. Comprehensive Web Solutions also handles user privacy by filtering data content according to HP's privacy regulations.
Baker believes that security is critical to a successful Web services implementation.
Not surprisingly, there's more sensitivity to security today than there ever has been in the past. I've been in the industry for twenty-five years, and security was almost nonexistent very early in my career. Concepts about security, while they were developed to some degree, were rarely implemented.
The situation is certainly changed today for a lot of reasons. Now, we're very sensitized to the importance of security. When we talk about Web services, we consider it to be a pivot point in the way that we deliver IT services, and we just want to pay a tremendous amount of attention to security from the start. We hope to avoid, quite frankly, some of the problems we've had in the past, where we needed to retrofit security into existing systems.
I don't think all of this is any great surprise to anyone who follows the industry. If you look at what's going on in the Web-based application frameworks, there's a fair amount of pretty obvious scrambling going on to fix up issues in security. Certainly, there's been a lot of commentary about Microsoft's problems in security—it's almost become comical about the number of different security patches they're releasing for their product line. It's also true in the open source world that there's a pretty continuous churn of trying to close down exposures.
So, if we look at using these technologies now, we're really kind of coming up the stack a layer or two, and we're looking at it from an application perspective for the applications we're providing. But, in our program efforts with Web services, we're saying that security needs to be designed from the start. We don't want to go through another one of these generations of retrofit.
Baker is highly pleased with the way the rollout has proceeded.
Our Web services experience has been very satisfactory. New development environments are making creation and implementation really easy. But, to achieve the full benefits of Web services, we need to change to a service-oriented architecture as well, which offers several challenges—organizational and design-related changes, as well as technical and operational ones. It's a paradigm shift: Instead of thinking and implementing in "silos,'' we're moving to a culture of sharing and reuse. That starts with providing an environment and tools for people to find out what's being developed or implemented in the company. An internal UDDI registry, as well as an XML schema repository, design guidelines, and processes for rolling out truly shared Web services, is really needed. An internal UDDI repository is currently in pilot mode and will be in production soon.
Web services are definitely an improvement over traditional middleware solutions, notes Baker.
Web services make cross-platform integrations a lot easier: Instead of buying proprietary middleware, we were able to use Web services to integrate different OS platforms, thus saving license and maintenance costs. Our configuration Web services provide a single, definitive rules engine utilizing SAP IPC, which can be used by a variety of applications that need product configuration information. This ensures delivering consistent results, regardless of the application that makes the call and saves. Another benefit is the integration of smaller, external business partners who wouldn't have been able to invest in a comprehensive EDI infrastructure. Web services allow them to submit their business documents, including invoices, shipments, and confirmations, using industry standard components and the Internet, without having to make huge infrastructure investments.
Baker believes the business potential of Web services hasn't yet been fully exploited. Nevertheless, he's looking forward to taking advantage of future Web services technologies.
We certainly don't see many "killer apps'' on the market that clearly demonstrate the business opportunities the Web services paradigm provides. Microsoft's myServices vision, which allows for subscription-based functionality, hasn't really taken off yet. We're seeing vendors exposing the functionality of their application packages as Web services, and we applaud this, since it will make application integration a lot easier. It also will be helpful to review more successful business cases and to develop better ways of determining the ROI of Web services-based solutions. The availability of key, enabling Web services, such as microbilling, subscription management, and security functions, will further help the rollout of a services-oriented architecture.
Baker believes that, despite existing limitations, Web services are definitely ready for everyday use.
We would like to see better processes and tools to help the management of Web services, from the business level to the infrastructure, especially the security aspect. But this doesn't preclude us from further rolling out a services-oriented architecture and using Web services in internal enterprise application integration and, in selected cases, offering exposure to the external world.
Baker feels that a Web services initiative requires a full organizational commitment. He suggests that businesses create an internal Web services task force.
Establish a Web services center of expertise, which can start as a virtual team. Then, develop an enterprise-wide vision and road map of the implementation. Start with exploring the business opportunities of Web services, and communicate them. Build a repository of business Web service examples. Develop road maps and guidelines for all architectural layers—ROI calculation algorithms, design and development guidelines, central infrastructure services, and security aspects—built around the hosting strategy. Determine your priorities for a rollout of Web services, and focus on a couple of pilots. Facilitate knowledge and experience sharing through internal Web services community events and training sessions.
Web services aren't particularly easy to implement, notes Baker, but they also don't present any insurmountable obstacles.
It's going to take some diligence and some follow through. Anytime you introduce new technologies in IT, you're going to have failures and successes in the appropriate use of the new technology. We need to be rational about that, and we need to exercise diligence processes to really assess each one of these early exercises. We need to assess how successful these processes actually are at delivering against the total vision. Then, you may want to take some corrective action to bring them in line. But it's not going to be easy, and there's a lot to change management that needs to go on.
Baker offers some final thoughts.
We consider Web services to be the next wave in computing. It's really early in its life cycle, particularly in terms of deployment activity, but there's a lot of power in standards-based approaches. It's a lot more powerful than some things that we've seen in the past. We, as a corporation, are embracing Web services. They're going to make a very durable and long run.