04:33 PM

Other Voices: Tire Kicking And Web Services

A Web-services expert recommends various ways to evaluate and adopt technologies such as XML to optimize your application development strategy.

In the IT industry, a tire kicker is a potential customer who engages in lengthy interactions with a vendor firm but will never buy its products or services. I've known a few of these over the years myself. These clients were frustrating because they often had large IT budgets and real problems that required our expertise, but we could never get a purchase order out of them. A version of the tire-kicker approach, as it turns out, may be a smart way to begin with Web services.

Web services are being adopted in multiple ways. Some firms are beginning on the inside of their organizations, behind the firewall, where pilot projects can be conducted safely without worrying about immature Web services security standards and lack of commercial solutions. This approach is an example of the inside-out approach, where a firm begins internally behind the firewall, and uses Web services as an alternative platform to enterprise application integration. Web services have a compelling value proposition as an open XML-based integration middleware solution in contrast to traditional, proprietary, and expensive EAI solutions. This inside-out paradigm is valid, and can provide great business value by extending business processes outside the firewalls to facilitate collaboration with external trading partners.

A competing Web services adoption paradigm is the "outside-in" approach, where a firm begins at the edges of the enterprise with collaborative Web services in customer-facing or supplier-facing business processes such as procurement, collaborative product development, and demand forecasting. Outside-in advocates argue that the interactions with trading partners at the edges of the enterprise are ripe for Web services because of the nature of the business processes at the edges-"frequent coupling and decoupling, distributed business processes, and the incompatibility of systems between enterprises. Web services are a great platform for resolving these issues, and I agree with this assessment.

The inside-out versus outside-in debate is a common one with Web services these days. I often argue that some industries are more prone to collaboration than others, such as electronics, automotive, and even insurance. Some industries, however, are characterized by complex legacy IT infrastructures, and therefore internal integration provides a more immediate payback. We know that many firms are well along the adoption path with Web services for both internal and external consumption. I still contend that firms deploying external Web services probably experimented internally first, behind the firewall, before exposing services to the outside world. It still really doesn't matter. What matters is that firms are using Web services, in multiple scenarios, for both internal integration and for external collaboration solutions. More important, these firms are accumulating knowledge for the future phases of Web-services adoption--innovation and domination--where Web services are delivering real business value.

However, there are other ways to begin Web services activities in a corporation. Let's explore a few of these alternative Web services adoption pathways for a moment.

The "Play It Safe I Value My Job Approach," also known as Risk Minimization: This is one where a firm implements Web services, or any emerging technology for that matter, in such a way that corporate and financial and business risk is minimized. This adoption path clearly argues for the behind-the-firewall approach of integration, although as I point out above, collaborative Web services also can be deployed behind the firewall as well.

The "MBA Approach," or Business Value Optimization: This approach, one that I emphatically advocate even with pilot projects, is predicated on the belief that for Web services to gain the most traction with the business, they must be deployed in ways that add unmitigated value to the business. This means selecting business processes that are hindered by integration problems, and where a value proposition exists compared to traditional integration approaches, or where there is upside opportunity to improve customer satisfaction, increase competitive advantage, reduce costs in a process, or things of this nature. In other words, "Where can we drive business value?" should be the first question asked, not the first question asked after a pilot project has been completed. Once business value has been identified in a number of areas of the business, pilot projects can then be scoped to help implement the ultimate production solution that will be deployed to deliver the real business value. In other words, make the pilot projects "real" in that they should build knowledge and capabilities that will lead very quickly to the targeted business value.

I advocate a business perspective on Web services from the outset. Web services are a business decision first, followed by the technology decisions. Projects should begin with a business analysis of the firm--its industry, its competitors, its customers, its business processes, its value chains--the core business value chain as well as the IT value chain, where the IT organization is broken down into processes that map to related business processes--and then begin targeting the deployment of Web services where business value can be best delivered. Seek revenue generation, cost reduction, process improvement and operating efficiencies, and focus on customers and competitive advantage. This kind of analysis injects business thinking into Web services, elevating the conversation from one of technology and standards to one focused on the business benefits that may be realized through the selective application of this nascent technology paradigm.

However, don't forget the infamous "Tire Kicker Approach." I'm not advocating tire kicking, mind you. The Tire Kicker model is a variant of the Risk Minimization Approach, except that it's far more frustrating for the vendors and it consumes both vendor and end-user resources in the process. In this case, let's assume there's actually a qualified Web services deal coming soon, so we'll call this the Modified Tire Kicker Approach. Talk to your vendors--the incumbents, the best of breed solutions, and the new entrants. Engage in detailed discussions about their solutions and capabilities, and how these fit with your business goals. Ask the tough questions. How do the vendors support Web services standards, how they will bring value to your developing Web services strategy, and why you should involve them in your pilot and ensuing Web services projects. My advice: Kick a lot of tires, but kick them quickly. Be up front with your vendor partners--you're evaluating them with a project in mind, and be clear about timeframes, business objectives, and potential vendor roles in your targeted solution. You must get busy with Web services soon, so the Modified Tire Kicker approach means that you are going to do something in the foreseeable future.

Here's six critical steps to bear in mind as you look ahead to evaluating and beginning a Web-services project:

  • Begin with business goals. What are the business objectives with Web services? Be explicit as to the desired outcomes. Even pilot projects should be launched with an eye toward a production-ready solution that drives legitimate business value.
  • Which adoption phase? Determine early on which adoption phase should be the initial focus of Web services efforts. If integration has the better value proposition and customer-focused benefits, start there. If collaborative processes have a better payoff, start there. These decisions should be made in the context of standards maturity and risk/benefit analysis.
  • Identify business process candidates. Based on industry and company structure, value chain and business process analysis and the adoption phase targeted, develop a list of processes that, if enabled using Web services, will result in the business goals identified above.
  • Evaluate IT capabilities. Does your IT organization have the skills and capabilities needed to drive the targeted Web services projects to achieve the desired business results? Consider augmenting your Web services team(s) with vendor and consulting resources, while maintaining oversight of these projects. Assure knowledge transfer is explicitly built into partner arrangements so your team has the necessary skills to do this independently.
  • Select core vendor partners, and begin. Based on all the above, you will most likely begin these projects with a few partners to facilitate. Consider how a few core vendor partners might facilitate this project. This decision will be based on business goals, adoption phase chosen, and how much of the Web services stack you choose to implement. Remember, standards are very volatile, so be wary.
  • Begin projects and learn. These early Web services projects are all about rapidly accumulating knowledge and driving business value. Early wins and rapid knowledge will create competitive advantage.

A winning Web-services adoption pathway is one that builds on business principles and, most important, focuses on real business value. All of the adoption pathways mentioned can generate business value, but only if you get started with Web services now.

Eric Marks is a business author and industry analyst with The RipTide Group, a Web-services consulting and solutions firm based in Newburyport, Mass. Marks is the author of Business Darwinism--Evolve or Dissolve (John Wiley & Sons, 2002) and co-author of Executive's Guide To Web Services (John Wiley & Sons, 2003), and can be reached at [email protected].

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service