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:
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].