Dan Bricklin's Web Site: www.bricklin.com
Web Services, Business Models, and Storage
The move to Internet services brings to the fore questions about where data is stored and what you can count on in the future.
There is much talk and excitement about Web Services. The technologies seem to finally be in place to allow us to replace "applications" running on individuals' computers with services provided on the Internet. Evolving from simple browser/server architectures known as ASPs, we are adding a more multitiered architecture with servers talking to servers using XML and other Internet protocols.
One of the things I've been trying to do is examine this area and try to see which factors may lead to success or failure. This essay looks at one aspect: Storage.
We have several years of experience now with the simpler browser/server style of systems. What have we seen? We have successes, such as shipping companies like Fedex, which cut their support costs while keeping high customer satisfaction by allowing people to directly access tracking information from the shipping company's database. We have failures, such as the photo storage companies that tried to keep your digital pictures for you (a failure despite the continued growing success of digital photography), and productivity application suites that tried to move your documents into a virtual space.
A story that I hear over and over again is that users do not want to trust online services to hold their data. It's not that they don't want the services to ever see the data -- they routinely give them access to credit card numbers and intimate personal preferences -- it's just that they don't want the only copy to be elsewhere. For example, describing the demise of their online accounting system, Microsoft VP Satya Nadella was quoted on News.com as saying "...most users prefered to have their accounting data on their desktop rather than have it hosted off-site."
This issue of storage is one that is important to the design of new services. The assumption you hear is often that a service will keep all the data created by the user, available whenever they need it from any browser, freeing them from the shackles of their personal computer. Better yet, they will be locked in, and will pay for the service for years to come. What great business models!
That is one of the problems: We are talking about "services" and "business models". A service is something that is performed for you, it is not a tangible thing you are left with afterwards, though it may result in such a thing. If it does not result in something tangible, then to continue to get the benefit the service must be continued to be performed. A business model sets forth what I do and how I get paid and make money. If a company finds that it's not making money, it must change the business model (changing what it does and/or how and how much it gets paid) or else eventually go out of business. If I get my car washed (a service) the result is my clean car. After the car gets dirty again I must go get it cleaned again. If the original car wash goes out of business, or changes how it works or its hours or how much it charges so that it doesn't suit my needs, I am out of luck with respect to that car wash. (Luckily I can take "my" car to another place or do it myself since my car isn't a service.)
This is different than a company that sells a "product". If I buy a cover for my car that keeps dirt from settling on it, I don't have to go back every few weeks. If the company decides to stop making the cover, raises its prices, changes the materials, or decides to only support certain models, it doesn't affect me that much. I already have it for my car. More importantly to us, if I buy some software from a company and it works for me, it isn't a disaster if the company stops. I still have use of what I bought, and if the data it works with follows the right standards, I can always switch to something else if my needs change. In any case, I can continue working and take my time to find a replacement.
The problem with many proposed Internet services is that you are left with nothing when the service stops. We all know that Internet companies come and go and change what they provide. You can never be sure that even rich, brick and mortar companies will not change their business model for a product you are depending upon.
For much of what we have been using the Web and other Internet applications, this has not been a problem. We use the Internet to obtain information that we either store locally (often printing it out to the benefit of the printer and ink manufacturers) or for which we have just a short-term need (like package tracking information). You can't even trust popular sites like the NYTimes to keep what you find there around for any length of time. Redesigns of many news web sites have invalidated old links. Email, chat, and Instant Messaging are transmitted from person to person, but any permanent storage is up to the receiver (and is not done for most of it). Once you buy something from Amazon you have it. If they lost your history, it's no big deal to you -- you already paid, and know to come back to them again if you were happy and sign up again for one-click buying.
People love MP3s and services like Napster that let them get MP3s that they can do things with. They have not flocked to systems that only let them listen when connected to the service and only as part of the service they are receiving. Napster's service was to let you get MP3s, while proposed music services are to let you listen. Once you have an MP3, much like a record or CD, you can use the music in many ways when you want, even if the musician dies or the record company goes bankrupt. A service gives you no guarantee that you'll be able to listen to that song again to cheer you up the next time you feel sad. It may be "our song" but you can't be sure you can take it out to listen again on your 50th anniversary.
Music is fun to talk about because it is so wrapped up in emotion (not just about the business models, but because of how it makes you feel when you listen). More important to our computer world, though, are data like word processed documents, reports, business information, specifications, customer lists, transaction histories, and assembly line product histories. More important to people's personal lives are often personal photos and mementos. I believe that these are things that we are even less likely to want to trust to others to give us access to only as a service. We won't hesitate much to let services work with our data, but we think of the data as a "thing" we should "own" and control. If a change in someone else's business model could block our access to our data, that is a very bad thing. We want the option to use the "our" data at a later time in a way we choose.
To me, the implications are that services must be structured so that people feel they have independent full access and control of their data. One way to do this is to make sure they can easily export it in a form they are comfortable with to keep themselves, or even make that transfer part of the service. (Some of the photo services would only let you download low-resolution copies of "your" pictures, preserving the full resolution for their printing services -- a very hostile thing.) Another way is to make use of the data such that it is mainly stored on the individual's computer. Of course, instead you can try to make the benefits of your service so great that the risk of needing to recreate everything if you stop using the service is a minor cost (a very tough thing to do -- you must be very realistic when accessing the value of those benefits).
Another implication is that services that don't need to maintain the only copy of data that users feel is "theirs" are more likely to succeed. So far, most of the successful ones on the web are ones that may have vast amounts of data, but that data is viewed as a natural property of the service, with no need for the individual to keep it themselves. Such data is often "created" or assembled by the service. If the user does the work to create the data (take pictures, type in information) they more likely feel it is "theirs" and that they would not want to have to recreate it to switch to a different service.
Switching cost can be important when people commit to an ongoing fee for a service. Long distance is an example of a service almost everybody pays for, but that has low switching costs. Even cell phone service has a fixed switching cost (few people know your number, no more than 1 year wait or $200 to change). Cable can be turned off at any point (stopping HBO doesn't make you forget the old episodes of the Sopranos). These services don't really keep anything of "yours" that you need in order to stop or switch. In contrast, the switching costs of some proposed services are high enough to be worthy of business interruption insurance coverage.
The promise of the newer Web Services is that one service can try to alleviate the need for you to hold the data since "standards" will make it easy for one service to provide the data to another, so you are less locked in. Our experience with companies cooperating in sharing data, even when they want to, and the fear of business model-driven changes that could effect such cooperation or the providing such a service, will temper the success of this promise as a selling point.
When you buy a product you try to find what you want at the best price. If a company sells something below their real cost, that's fine -- it's a bargain. You know they can do that with good business sense if it's part of their business model (such as a "loss leader" to introduce you to them), or because of poor business sense (not knowing their real costs). It doesn't matter -- you have the product. When you buy a service, especially one that holds your data, you are more worried about the seller's long-term survival. Buying the least expensive, without being sure the company has a cost structure to support it, is dangerous. You will be very wary of claims of lower cost structures. This means that services are easier for large, rich, established, conservative companies to sell, and harder for smaller, new entrepreneurial ones. (This is even though in reality a large company may not be willing to take the risk to continue what looks like a money losing service that a smaller, more committed one, might.) This is bad for innovation. In our economy, we need the smaller new companies to have as good a chance as possible to succeed. Selling a service that won't hurt you if it stopped, just like a tangible product, is easier for a small or new business.
A key will be to design services that store the right data in the right place. Strategies for keeping just what you need at the right place will be important. As bandwidth becomes more plentiful, this will be less of a technical issue, because the performance penalty for copying data from one place to another will be lowered.
I think this all bodes well for the role of individual's computers (those under their direct control) and the storage they provide. It also shows why there was such an allure to the world of Peer-to-Peer, which addresses creating systems that assume personal control of storage. One of the major design successes of Napster was how it balanced where it kept various types of data.
Issues like this are important. As we saw in the dotCom era, it's easy to have false assumptions that make business models seem so viable. Ideas like the supposed across-the-board expense savings of eBusinesses may belong along with ideas such as that people will trust you to have their only copy of data or that they will trust you to always be there for them or that they'll commit to paying you forever.
Does this mean I don't believe in browser-based web authoring? Of course not. Web authoring is one of those applications that is sometimes better when done using a service, depending on the circumstances. (Web site hosting is inherently a service.) Read "Web Authoring and Storage Location".
© Copyright 1999-2010 by Daniel Bricklin
All Rights Reserved.