There is much uncertainty about the adoption of these network-based services by businesses. Will companies build their own services, or will they use service providers? Furthermore, what will the management struc- ture of these services be? Outsourcing will allow businesses to focus on their core companies, while building their own services will allow more flexibility in meeting uncertain user needs. The jury is out; we now need to wait to see what happens.
In today’s IT environment, managers and investors who understand why particular network-based services have become successful over other services are in a better position to decide what type of network infrastruc- ture is best, given the degree of market uncertainty. Some network-based services, such as basic voice and email, have changed how we live and work and have created vast wealth. Other services, such as videophones, have never emerged as predicted. This way of thinking with an option point of view helps manage the uncertainty in the dot-com and telecom sectors, capturing the most value from these services by minimizing the risk associated with high market uncertainty.
How difficult each experiment is to run and who can experiment are important attributes of management structure. Was permission required of the network owner/managers? How technically difficult is the typical experiment? What does it cost? How questions like this are answered affects the amount of experimentation that occurs and thus the value of the most successful of them. A greater number of experiments indicate a greater expected value. In general, services with distributed management structures allow more experimentation while centralized managed ser- vices imply less, as explained further in this chapter.
While general services are predictable in many instances, the particular architecture, feature set, and implementation that are widely adopted are often not predictable. Email is a good example of this; the demand was clear, but it took several generations of competing service offerings to con- verge to the Internet standards-based solution. In the 80s, X.400 became the anointed email standard; it met everybody’s needs, according to its design- ers, and was championed by most governments and vendors. It seemed that it could not fail because it had options for every need, but it did fail. By the early 90s, the adoption of Internet email seemed to indicate that it could become a serious threat to X.400, yet the majority of industry pundits adamantly still believed in the OSI’s X.400. These pundits asked how X.400 could fail; it was feature-rich compared to Internet email, which could not send attachments or demand proof of mail delivery. The U.S. government even mandated that X.400 be addressed in all responses to RFPs with the U.S. Government OSI Profile (GOSIP) directive. The success of Internet email over X.400 illustrates that even when demand for services such as email is understood, the particulars of the service are not. This indicates that current predictions may be inaccurate for services and feature sets of new technologies such as Voice-over IP, wireless, and general network- based services as the convergence of voice and data becomes a reality.
One important part about experimentation with network-based services is the selection process by which the services become successful, which is similar to how the fittest organisms are selected within bio-environments.
Users select the “best” service — after they see the choices, similar to how bio-environments pick the best choices from many genetic mutations.
Value determination of network service experiments is made by market selection by the users, similar to how bio-environments value a genetic mutation based on how well it survives and passes on the altered gene.
Value is related to user adoption, which is related to meeting user’s needs. There are many examples of both successful and unsuccessful network-based services. In the telephone network, caller ID and personal voice mail have been well received; however, video calling and ISDN have not. There are similar examples in the Internet, with email and Web-based 20 Chapter 2
applications such as the CNN or the Wall Street Journalsite being incredibly successful, while other Web-based applications, such as food delivery, have been a dismal failure. Even multicast has not been adopted by most Internet users. The market uncertainty is what makes it hard to predict what services with what feature sets will best meet user needs.
A very important question is who can experiment with a network-based service? In the telephone network, it is impossible to add new services within the network. For example, in the PSTN, consider the *## services [3], such as retrieving the number of the last incoming call. Users cannot change or add new *## services; only the network telephone company can experiment with them. The Internet is fundamentally different because it promotes users’ ability to create their own services and provide them to others. It is easy for anybody to add new services. The network services provided by many Internet service providers are basic IP connectivity and email. The PSTN does allow some experimentation because PBX vendors not related to the telephone company can experiment. In addition, within the Internet, proposed services, such as Voice-over IP with the megaco pro- tocol, depend on a centralized network server. While hard to categorize, the Internet in general promotes easy experimentation by all, while the telephone network does not.
The ease of experimentation is also important. How complex must experiments be, and what resources are required to perform them? Does network infrastructure need to change to support the new service or fea- ture? To change a telephone *## service, the Central Office switch needs modification, but when the Web was created there was no change to the Internet infrastructure. Some Web technologies such as Java empower edge innovation because it pushes the intelligences of Web applications to the network’s edge. Shifting more processing to the users’ desktops via local execution of Java applets encourages end users to experiment, as the end-2-end argument discussed in Chapter 3 explains. When experimenta- tion is easy, it happens more. When more people can experiment, it hap- pens more. Easy and inexpensive experimentation promotes more experimentation — a good thing when users’ needs are a mystery.
As discussed in Chapter 6, when the variance of a set of random experi- ments is high, the results of the experiments are widely dispersed from very good to very bad. It is the combination of easy experimentation, the ability of end users to experiment, and high market uncertainty that can work magic. These are exactly the conditions under which the Web was created. When market uncertainty is low, experimentation is of little value because anybody can meet user needs. The important point in low market uncertainty is the ability to provide a known good service to users at the best price for a given set of features and performance. It is market
Network-Based Services 21
uncertainty that determines if experimentation makes sense from the point of view of meeting user needs.