THREE STEPS TO SUCCESSFUL WEB SERVICES

Taking the first step—the “leap of faith”—with any new technology can be daunting. This section identifies three steps that will help a company get started with Web services and avoid any hurdles. The three steps detailed in this section are as follows:

1. Start Preparing —What does a firm need to consider before beginning the implementation of Web services?

2. Selection of a Pilot Project —How should a firm select the first Web services pilot?

3. Incremental Adoption —What should the primary considerations be as Web services are deployed across the organization?

Step 1: Start Preparing

In Chapter 3, “Web Services Adoption,” we discussed the four phases of the Web services adoption model: integration, collaboration, innovation, and domination. Here, we focus on the tasks required to get ready for the integration and collaboration phases, discussing the steps that should be considered when preparing for the first Web services project. Think of this section as a pre-project checklist of steps that ideally should be completed before starting the first Web services project. The key topics that are covered in this section include the following:

• Questions to Ask —What questions should be asked today? Also, what questions should the executive team be asking?

• Awareness and Training —Who needs to understand the concepts and capabilities of Web services? Also, who should receive training on how to implement Web services?

• Getting Started —Are there any key tasks that should be considered before starting the first Web services project? What can be done to get started today?

Questions to Ask Today As a firm is considering Web services, Figure 6.3 outlines some of the initial questions that should be considered by any organization beginning its Web services journey.

Figure 6.3: Questions to ask today.

Awareness, Skills, and Training A Web services project is no different than any traditional technology project in that it should be a collaborative effort between the business unit(s) and IT. But as with any new technology, the application of Web services can only be conceived and implemented as well as the skills and experience within the organization allow. Awareness of Web services in both the business and IT communities will be critical to fully leverage Web services and enable new business capabilities.

Business Awareness Web services will ultimately impact all aspects of an organization. Therefore, a priority for any company planning to launch Web services should be basic awareness and training across all functions and at all levels of the organization. Make sure that managers and executives across the organization understand the basic principles of Web services and that they receive regular updates on how Web services are being used and can be used in your organization.

Primary considerations for creating business awareness of Web services include:

• Executive Awareness —It is critical that senior executives and company leaders are aware of the strategic value that Web services can provide. Communicate the capabilities and implications of Web services to the executive team, and make this goal the highest priority.

• Executive Buy-in —Without executive awareness, buy-in, and support, a firm might have the in-house Web services implementation skills but will lack the necessary mind-share to move early projects forward.

• Strategic Planning —Beyond the mind-share required to get the first project underway, the executive team requires a broad understanding of the medium- and long-term strategic implications of Web services. Ensure that Web services are considered in the context of the strategic vision and strategic planning. They may be a key enabler, or perhaps will require fundamentally rethinking the business focus. Look for strategic value in Web services. There might be opportunities to migrate from a low-margin manufacturing service to a high-margin services business.

If a firm does not gain executive mind-share and formulate a Web services strategy during the integration and collaboration phases, it will likely not be among the winners in the innovation and domination phases. In order to really make Web services deliver true business value, the corporate strategy and business model must be explicitly interlocked with the Web services strategy, implementation plans, and the initial projects under consideration.

Java versus .Net Web services today are implemented in two primary ways: Java 2 Enterprise Edition (J2EE) or Microsoft .Net. The relative advantages and disadvantages of these two implementation models are discussed in Chapter 7, “Architecting for Competitive Advantage,” but fundamentally either or both can be used to develop interoperable Web services.

From a technical training perspective, primary considerations should include “What are the current in-house skills?” and “What are the majority of existing applications and infrastructure implemented with?” The answers to these two questions will likely determine whether a firm uses Microsoft .Net or J2EE for the implementation of its first Web services projects.

Technical Training Beyond the question of Java versus .Net, primary considerations when looking at capabilities and training should be the following issues :

• Development Tools —A new breed of development tools, referred to as authoring environments or Integrated Development Environments (IDEs), are emerging to aid developers with Web services implementation. These tools promise to significantly reduce the time and effort required to implement Web services by automating the creation of access protocols (specifically SOAP) and service description documents (specifically WSDL). Further information regarding Web services software vendors and development tools can be found in Chapter 8, “Web Services Vendor Landscape.”

• Technical Team Perspective —Obtain architects’, designers’, and developers’ perspectives and feedback on Web services and the associated Java or .Net development tools. It is likely that they have already been reading up on Web services and testing their capabilities on “skunk-works” projects, using any one of the multitude of downloadable trial development environments available from Microsoft, IBM, BEA Systems, Sun, and others.

• Prioritize Training Needs —Formalize needed Web services capabilities and skill sets. It is probably not practical to train the entire team at one time, so identify a SWAT team of architects, project managers, and senior developers who will form a bridgehead for formal Web services training and skills development. This group should also contain the individuals that will lead the initial pilot projects.

If in-house planning and development resources are limited, consider working with a Systems Integration (SI) partner to kickstart Web services efforts. Be sure to ask for Web services references and check them diligently, vetting the proposed team members to determine their real handson skills with Web services. Make sure that it is possible for key resources from the core team to participate as project team members, or shadow resources, alongside the SI team. Early projects with SI partners will create an ideal opportunity to obtain on-the-job Web services training and knowledge transfer for your staff.

Getting Started Today Having determined the training needs, a firm must start preparing its applications and architecture for the first Web services project. Two key areas to start work on are the standardization of data definitions and XML-enabling legacy systems.

Standardize Data Definitions It is critically important to define and then garner agreement for the data definition standards that will be used across the organization. Web services provide the protocols and standards to significantly reduce the complexity associated with system integration, but they do not guarantee shared terminology and agreement on the meaning of data shared between organizations. In Chapter 2, “Standards, Concepts, and Terminology,” we discussed the flexibility that XML provides but also introduced the challenges of aligning data definitions, jargon, and vocabularies within and across organizations. For example, is what you mean by a “widget” the same as my understanding? Or, for example, in an XML document containing a product catalogue, is the “Price” field the gross price or the net price?

These examples represent just the tip of the semantic iceberg. Recognizing these challenges, a number of standards organizations are actively engaged in defining data schemes for shared agreement and understanding (for example, OASIS, RosettaNet, and so on). Unfortunately, getting agreement on these standards is proving to be a slow and arduous process as Dell Computer experienced firsthand working with RosettaNet:

After three years, members of the computer-industry standards group RosettaNet haven’t agreed on specifications, so Dell Computer Corporation just dropped out. Instead, it is moving ahead with its own system for linking suppliers. “I think it’ll take years to get an adoption of RosettaNet standards. We’re all for it, but I’m not waiting,” says Richard L. Hunter Jr., Dell’s vicepresident for Americas manufacturing operations. ^[3]

Some industries have achieved broader agreement on data definition standards than others (for example, ACORD in the insurance industry and FITS in brokerage), so it is not always necessary to go it alone as Dell decided to do.

Regardless of whether existing industry standards are used or a firm defines its own, it is critical to enforce data definition standards within an organization. This task is perhaps the single most important activity that can be completed in preparation for implementing Web services. As the need for data definition standards in an organization is examined, consider the following activities:

• Check with industry bodies to determine if industry-specific data standards have been developed that can be leveraged. Perhaps the standards for your industry are a “work in-progress,” where a firm can participate in and influence their direction.

• Investigate if any previous projects have started the process of data definition for your organization. Perhaps a glossary of terms, a data dictionary, or data modeling project can be leveraged as a starting point for your data definition standards.

• Making sure that a definitive source of defined standards is published and maintained (once you have defined your data definition standards).

• Making sure that data standards are applied consistently for all projects going forward.

Cutting corners on data standardization now will create a snowball effect later, so invest the time and energy to develop data definition standards as soon as possible.

XML Enabling XML-based messaging is a central enabler for Web services, providing a more simple, flexible approach to connecting systems than traditional custom interfaces and current Enterprise Application Integration (EAI) offerings. XML is literally the keystone of Web services, enabling the creation of standards-based integration across an organization.

XML and Web services go hand in hand. Therefore, XML-enabling core systems pay dividends when implementing Web services. As a firm leverages XML across its organizations, consider the following actions:

• Investigate Emerging Tools —Early adopters of XML, such as Fidelity Investments, hand-coded the software to generate XML documents. Now, a range of XML and Web services enablement tools are on the market, which significantly reduces the time and effort required to generate XML extracts from newly developed or legacy systems. Examples of such tools include XMLSpy and exteNd Composer.

• Consult Key Application Vendors —Many software vendors are already XML- and Web services-enabling their applications. Talk with key application software vendors to determine when they intend to release XML or Web services-enabled versions of their software. Determine whether software releases supporting XML and Web services will be minor updates or major new releases.

• Determining Application Upgrades —Determine the effort required to update or upgrade packaged applications to provide XML and Web services support. Decide which packages will be updated or upgraded, and for which a firm will develop its own Web services support.

Step 2: Select a Pilot

Having begun the preparation tasks, a firm will be well on the way toward laying a solid foundation for its first Web services project. Now, it is time to identify and prioritize candidate pilot projects. Three activities required for this are listed below:

• Guiding Principles —Are there any guiding principles that should be known and followed before the project begins?

• Application Inventory —What applications systems exist today? How can the existing application portfolio be leveraged using Web services?

• Pilot Project —How should the pilot project be identified?

Guiding Principles As a firm targets candidate projects, use these three key principles to facilitate selection process:

• Remember the “Usual Suspects” —The biggest challenges of implementing Web services projects will inevitably be similar to the challenges experienced during a typical IT project or program. These include the following:

  1. Lack of executive sponsorship

  2. Lack of stakeholder input

  3. Unrealistic or poorly managed expectations

  4. Not dedicating business and technical resources

  5. Lack of change management

  6. Scope creep

  Far too often, these challenges are overlooked as it is easier to focus on the technical obstacles or limitations. The reality is that if these six challenges are not a primary focus, then overcoming technical limitations will be the least of a firm’s worries.

• Keep It Simple —The adoption of any new technology inevitably has its fair share of unexpected pitfalls. Unfortunately, these pitfalls only become obvious after the fact. Do not choose a highly visible or mission-critical project as an early pilot. Remember that one highvisibility failure has the potential to cost far more in lost credibility than it could ever return as a run-away success.

• Web Services Are not Hammers for Every Nail —Web services are a valuable tool to be added to the IT arsenal, but they are not right for every project. For example, Web services are a good fit for interoperability and loose coupling, but where high volume and high throughput is essential, Web services add a performance overhead that make them a poor choice.

Application Inventory Before deciding where to start implementing Web services, a firm must know what application systems already exist. Many organizations maintain an application inventory of production systems, but if it does not exist or if it is not up to date, then take the time to review and document the application portfolio. As the application inventory is updated or created, capture information that will help identify initial Web services opportunities. Use these four categories as a basis for identifying Web services “hot spots:”

1. Data Silos —Where information is held within enterprise application silos, limiting operating visibility. This is a primary candidate for Web services-enabled “executive dashboards.” Using XML and Web services, data can be extracted from multiple systems and aggregated, in near real-time, to provide unprecedented visibility of operational metrics. Dashboards can be tailored to the specific needs of business and executive management roles.

2. Manual Duplication of Data —Reducing or eliminating manual data entry is a glaring opportunity for Web services application integration. Look for process and automation breaches where there are gaps that require manual data entry or repetitive fax and print operations augmented with manual effort.

3. Proprietary Interfaces —Applications that have proven difficult to integrate, perhaps using proprietary interfaces requiring specialists’ skills, can be encapsulated using SOAP to provide a standard Web services interface. Once a SOAP interface has been implemented, the new service can be reused by other applications without the need for additional development effort.

4. Manual Touch Points —Use Web services to enable more effective collaboration with trusted partners where manual processes exist. Look at large partners, suppliers, and customers. Where orders are processed manually, consider implementing collaboration Web services to reduce transaction costs, remove transcribing errors, and develop “stickier” relationships. Talk with trusted partners, suppliers, and customers to see who is using Web services or considering their use. If any trusted partners, suppliers, or customers are using Web services, then there may be an ideal opportunity to jumpstart Web services collaboration efforts. Closer collaboration with key partners can deliver dramatic results, as with the Dell case study illustrated earlier in this chapter.

Upon completion of the application inventory, identified primary Web services hotspots will fall into these four categories. This analysis will help identify the first Web services pilot project.

Pilot Projects As long as a company has applied the guiding principles and updated its application inventory, using the categories identified previously, there should now be a good short list of candidate pilot projects. As the risks of failure are significant on a pilot project, especially when using new technologies and capabilities, further filter the short list to minimize risk and maximize return. Figure 6.4 illustrates a four-quadrant view for mapping short-listed pilot projects. Clearly, look for projects that fall within the top-right Sweet Spot quadrant.

Figure 6.4: Maximize return and minimize risk.

Now that a pilot project has been selected, make sure there is agreement on the set of Web services standards that will be used. One of the fundamental goals of Web services is to enable systems interoperability, but the accelerated rate at which standards are evolving can undermine this goal.

As discussed in Chapter 2, “Standards, Concepts, and Terminology,” to ensure interoperability first agree on the core standards and versions that will be used to deploy Web services. The Web Services Interoperability (WS-I) organization has defined the WS-Basic Profile, as illustrated in Figure 6.5. The WS-Basic Profile provides standards that are a good starting point for early Web services projects.

Figure 6.5: The WS-Basic Web services standards.

Step 3: Incremental Adoption

In moving beyond the first pilot project, a firm will have learned a tremendous amount about the real-world deployment of Web services—gaining a better understanding of their capabilities and limitations. It is important to remember that the early Web services primarily focus on integration and rudimentary collaboration, but as standards gain greater acceptance, the Sweet Spot will grow to encompass extended collaboration and innovation opportunities.

For now, limit early projects to integration and collaboration and learn from early successes and failures to prepare for more complex Web services projects. Specifically:

• Don’t Bite off More than You Can Chew— Keep early projects simple and well defined. It is appropriate to push the boundaries of internal skills as well as Web services technology, but do not push these capabilities too far or too fast. Consider focusing early projects on a single departmental application or single enterprise application at a time. By taking a step-wise approach, your Service-Oriented Architecture (SOA) will come together over time.

• Leverage Key Vendors/Partners — Identify which software vendors your firm spends the most with (such as Microsoft, Oracle, HP, IBM). All major vendors, and many others, are actively promoting their ability to deliver Web services. Leverage relationships with these organizations to receive Web services briefings and demonstrations. Their in-house experts can be valuable resources when determining how far to push the capabilities of Web services.

• Leverage Your Peer Network —Talk with peers in formal and informal settings to gain better visibility of what others are doing with Web services. There are a number of peer networking groups you can join that help executives share best practices, lessons learned, and success stories. Examples include Beacon Hill Group, a regionally based in-person network (beaconhillgroup.com), and Chief Officer (chiefofficer.com), an online community with more than 2,000 members. These networking groups provide exposure to cross-industry best practices that can be leveraged to identify realistic Web services benefits, rather than needing to rely on media hype.

• Don’t Forget the Basics —Forgetting project fundamentals such as executive support, expectation management, and scope management lead to project failure far more frequently than technical issues or limitations. Make sure to remember these basics for any Web services projects.

• Learn from Your Successes and Failures —In the early adoption stages of any new technology, both successes and failures can be used as a basis to gather lessons learned. Capture what works and what does not and build this body of knowledge into training for business and IT personnel.

• Get Integration and Collaboration Right, and Innovate From There —Lay a Web services foundation from a skills and capabilities perspective as well as from an infrastructure and architecture perspective first. Once the right foundation exists, innovation opportunities will be far easier to realize.

^[3]March 18, 2002, “The Web at Your Service” by Jim Kerstetter.