|
Wednesday December 5 2001 Learning from the Mistakes of E-Commerce? Translating the Dot.com Experience for Web Services Given that Web Services will be using similar technologies to e-commerce, is it fair to compare them? Can we look at the "mistakes" of e-commerce and learn from them for Web Services? Well, we can try - surely there is enough common ground between the two technologies to allow for this comparison. In this article, we look at mistakes or myths of e-commerce, how they can be applied to Web Services, and what we can learn from the past. E-Commerce Mistakes - the dot.com Slump So what went wrong with consumer e-commerce? Why wasn't the power of the Internet harnessed to sell things successfully? In a recent article on ZDNet, Adrian Mello argued that there are principally two reasons:
The first reason breaks down into three aspects:
Basically, if your e-commerce website is hard to navigate, takes a long time to download, and makes suggestions for products based on gifts you've bought for someone else, your chances of making a profit are reduced. The other problem, which can still cripple an e-commerce site with the best design in the world, is one of selecting appropriate products. While it may be possible to sell fresh fish over the Internet, it is probably a poor choice unless you can deliver it as well as sell it. Books, t-shirts, and computer games are all fairly safe bets as they can be easily entrusted to regular delivery providers (the national postal system). Cars, on the other hand, are a different matter - most people will reasonably want to take a test drive before they buy, and the Internet can't provide you with a genuine feel for how a car handles, what the visibility from the drivers seat is, or whether it will hold your granny's wheelchair/enough suitcases for your holiday needs. Plus buying over the Internet removes the element of human contact so prized in shopping - you can't ask a sales assistant to show you how? So how does this relate to Web Services? There's no web site to get wrong; there's no product to ship across the country (or world); there's no need to mimic window-shopping. The world is rarely as simple as that, but I think there are lessons to be gleaned from the dot.com experience - we just have to exercise some thought. Translating the Dot.com Experience for Web Services Where do we begin, with the poor site design or the poor choice of product? Site Design Let's begin at the first point of customer contact, the web site. Given that there is no need of a web site for our Web Service, what can we learn from the past here? The first thing to do is abstract the details of the bad web site until we get to the nub of the problem - communication. Now we have something that we can apply to Web Services. The fundamental problem with a poorly designed web site is that it hinders easy, clear communication. If you have to wait for elements of the site to load before you get the information you require, you're less likely to stick with the process until your purchase is complete. If you have to wade through five or six screens before you get to the page for your product of choice, you'd be forgiven for giving up and looking elsewhere. Assuming the site is quick to load and easy to navigate, being welcomed back with suggestions for books on knitting or CDs by Paul Simon because you bought them for your Aunt Vera last time you were at the site might put you off; either that or having to fill in several questionnaires before you can purchase anything might stop you even getting to the checkout. Looking at Web Services, the message is now plain - keep your description of what service you are providing and how to access it clear and simple. One obvious way to do this is to get someone who hasn't worked on the Web Service to review your documentation and try to access the service - if they succeed, you're communicating loud and clear. Product Choice So how does choice of product relate to Web Services? This one should be a bit easier if we look at our Web Service as a product. Just because somebody says that you can sell anything over the Internet, it doesn't either make it happen or mean that you have to comply. Similarly with Web Services - just because you can expose all of your systems as Web Services doesn't mean you should. This should be obvious from a security point of view, if not also bandwidth. Since Web Services essentially expose functions to remote calls, there will be any number of parts of the system that shouldn't be exposed. This is even more important when we consider that it is part of the business process that is being revealed when we expose the functions as Web Services. Choosing a function to be exposed as a Web Service is the key decision - get this wrong, and you're in trouble. When choosing the function to expose as a Web Service, some things to consider are:
If the answer to any of these questions is "yes", you might want to look at another function (granting that if the function was e-mail, the answer to most of these points would be "yes"). While it is certainly possible to provide a Web Service that takes two hours to return a value, unless you are clear in your description that it will take two hours to complete, your subscribers might not continue using the service. If the Web Service requires twenty-three parameters, it might not be that popular, unless it's a really complicated calculation that a limited number of people are qualified to make. If the results are only fresh for a few minutes, network problems could conceivably delay the return long enough for the data to become stale. The final question, relating to transactions, is one that is dogging Web Services. Transactions Although transactional processing could be included in the Web Services world, it is perhaps more cumbersome than many developers would like. In a similar manner to that employed in messaging systems (such as MSMQ, JMS, MQSeries, etc.), the initial call to the Web Service would be performed within a transaction A, which would launch a second transaction B on the publisher system. As transaction B is working, A waits for the return value, at which point it completes or rolls back as appropriate. Without the rollback guarantee of transactional processing, Web Services may be regarded as a poor choice. If the Web Service is started inside a transaction at one end (the subscriber), there is no guarantee that the other end (the publisher) will be within a transaction. When both ends are securely within transactions, the resources used will probably be locked up for much longer than with a transaction taking place over a local network. Write access to a busy database on a large scale in real time could be very slow, and therefore not an attractive proposition. Web Services can partake of transactional processing, but in order to not disappoint the subscribers they should be clearly labeled as being potentially slow (relatively speaking, perhaps). Again, communicating the capabilities of the Web Service will reduce the cause for complaint and disappointment. B2C E-Commerce vs. B2B E-Commerce: As you are probably aware, the preceding comments apply to business to consumer (B2C) e-commerce, and public Web Services. Business to business (B2B) e-commerce, unlike many B2C ventures, has tended to fare rather better. Why is this? B2B e-commerce takes place between two companies that know each other, and have (or develop) a working relationship, one that involves talking to each other and discussing their mutual needs. Compare this with the uncertain world of B2C e-commerce, where you can never be sure what your target audience wants to see, much less how they want to see it. Here's that communication element again: rather than just creating a web site full of flashy graphics that take forever to download, there is a partnership in operation. Both sides of the deal decide what is needed - company A tells company B what they want to see and how they want to see it, company B responds by telling company A their requirements. This way, although there may need to be some compromises, both sides should get what they expect, and, perhaps more importantly, will know what to provide. With a private Web Service, one that is limited to use within one company or between two partner companies, the same applies. Between trading partners, or within a single company, each side will have clear ideas of what they want and how they want it, along with what they have and how they can provide it. Because the two ends of the Web Service chain can talk to each other and expect to be able to influence the outcome, both sides will get what they want (or get a lot closer to it). With public Web Services (as with B2C e-commerce), the publisher provides a service and the subscriber has little to no say in how it is presented. Things to Learn So what, if anything, can we learn from the past? The key issue seems to be communication; if we clearly communicate the purpose and capabilities of our Web Service, then there is no reason why we couldn't expose it to a wider public. For private Web Services, we have the opportunity to communicate with our business partners to make sure that our Web Services provide what is needed. One of the symptoms of poorly communicated ideas in the B2C e-commerce world was people expecting more than the site was capable of providing. The same could apply to Web Services, if they are not clearly documented. In addition, as a 'peace of mind' option, quality of service agreements should almost certainly be implemented to set out what the Web Service will provide, how it will be provided, and the quality of that provision. With a quality of service agreement, there would some recourse if the Web Service failed to provide. Conclusion Clarity of communication is key to a successful Web Services enterprise, whether it is communication between business partners or gaining an understanding of the market. Without knowing what the customer wants, there is no guarantee that what you provide will be what they want - you can please some of the people all of the time, and all of the people some of the time, but you can't please all of the people all of the time. Similar articles: |