Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here . Copyright © 1999, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

Those old songs are being sung again. ISPs, RBOCs, IXCs, and CLECs are all eyeing the same dollars and facing the same issues. Are there any new reasons to revisit this old concept?

Yes, and no.

The Internet introduced the first broadly accepted example of a network-resident or "hosted" application. Most companies with a web presence today have it because their ISP hosts their web page. The "web server" application for these companies is hosted by their ISP, in other words. Thus, we have the first validation that there are applications that users willingly offload onto service providers.

At the same time, surveys we’ve done of corporate buyers show that some aspects of application hosting—notably the idea that standard desktop software like Word or Excel would be stored on the network and loaded as needed—is still regarded as singularly stupid. Thus, we have continued rejection of at least one popular (among service providers) class of application hosting

Clearly, there are some applications that users will willingly host and others they won’t. The question is where the boundary will fall. To figure that out, we’ll draw on both logic and research.

Logic suggests that the most likely new hosting applications to succeed would be those related to the only hosting application that has succeeded so far—web hosting. Users today willingly allow their electronic presence to be supported by another. Why?

According to most users, there are three main reasons why ISP-hosted web presence is considered acceptable:

1. The alternative would be to develop the presence internally using skills and resources not presently available.
2. The alternative of internal hosting would be practical only if the user purchased a very fast connection to the Internet, and the cost of this connection alone would probably be more than the cost of ISP hosting.
3. The responsibility for maintenance of the content of the web site falls outside the MIS or networking organization, and the responsible organization has no need or desire to validate or employ local resources.

Interestingly, the idea that content development was difficult, or that ongoing support of the internal option would be expensive in employee resources, wasn’t a major factor. Remember, the idea that word processors and spread sheets are hard to administer on a per-desktop basis was one of the main arguments for outsourcing these applications to the network. Thus, we can infer that one reason why the desktop applications have failed as network-resident applications is that the main "value" of moving these applications onto the network isn’t credible to users.

These three network residency justifications do suggest that other applications that either have the same characteristics as the web presence application, or perhaps even derive in some way from it, would be more credible. That, in fact, is what users believe.

More than 80% of users who use ISP hosting today would expect to use ISP-hosted e-commerce were they to become involved directly in online sales of some sort or another.

The reason online sales extensions to web hosting are credible are the very reasons why web hosting itself is credible. Most users have no current computing system support for e-commerce, so they’d have to purchase or develop it. Most fear that supporting the full e-commerce transaction flow would require more Internet access bandwidth, increasing cost. Most interest in e-commerce is developing in the sales/marketing area, and this group has no particular vested interest in extending current computing or networking organizations’ political reach and power. In fact, users told us (by nearly a 2:1 margin) they’d prefer not to implement e-commerce using their existing systems.

What then would they want from their service provider? The number one answer is credit authorization and buyer authentication. Users see the following flow of activity:

1. The buyer stumbles onto the seller homepage and sees something interesting.
2. The buyer clicks to purchase it, and is transferred to a hosted application that gathers authentic information on the buyer, including address data, and also links to either a credit card authorization system or another system of electronic cash/credit transfer to handle the financial side.
3. The authenticated, "paid", transactions are passed, perhaps encapsulated in e-mail, to the real seller for entry into the seller’s existing order fulfillment system. This entry might be automatic (through an application that filtered and formatted the transaction/e-mail) or manual, depending on expected order volume and other factors.
4. The purchase is fulfilled via standard channels.

This flow doesn’t represent, to the prospective user, a dramatic policy change versus web hosting alone. If it were priced on a per-transaction basis, and if the price were a relatively small fraction of the sales price of the product(s) involved, the concept is viewed by nearly all businesses as at least worthy of consideration. It is particularly interesting to small to mid-sized businesses who currently don’t do credit card sales at all, or who don’t have a particularly efficient or economical way of handling them.

Service providers say that they could, with a hosted e-commerce application, offer these businesses what might well be a lower cost of handling credit sales than they currently have, and at the same time offer a much larger potential customer base. That assertion would have to be proved over time, but it’s credible to nearly 80% of small to mid-sized businesses who are targets for this particular service concept.

The next question is what might be done from there. As we’ve indicated in the past, 22 of the 23 average information network transactions associated with fulfillment of a retail exchange are internal to the company. We could view the company’s order fulfillment process as a network-linked chain of activity involving both humans and computer applications. As the end-point of this chain of activity (the retail sale) changes over to e-commerce, would it not be logical to assume that some impact of this chain would ripple through the rest of the activity?

One way of validating this is to consider the extreme case of a company who elects to change from a store-front retail organization to a web-based sales organization. Such a company could, for example, take the retail transaction output of our first-level e-commerce application and process it through to a wholesaler who would drop-ship the item to the buyer. This process could clearly be absorbed into the network as well:

1. The "seller" receives an e-mail journal entry of the transaction, which is copied to the wholesaler. In this copy, the e-commerce hosted application authenticates the validity of both buyer and "seller", the retailer who will really be billed.
2. The wholesaler ships to the buyer, and invoices the "seller" for the wholesale price plus the shipping cost.

Now, the whole shipping process and accounts receivable process is offloaded, but there’s still more that could be done.

Suppose the e-commerce application, instead of invoicing the wholesaler, divided the retail fee paid by the buyer (via credit card) into a credit to the wholesaler for the wholesale amount and a credit to the retailer for the net margin? Now the retailer’s accounts payable system is eliminated.

How about reporting? The e-commerce application host could offer tax reports, P&L reports, etc. In short, the whole process of business could virtualize. Sales people (whatever they’d do) could be paid commission based on the transactions. Management could see sales reports delivered over the network by the network-hosted commerce application. E-business arrives.

OK, most companies probably wouldn’t go that far, but it’s clear that to the extent that the concept could be applied in less than this extreme level of commitment. Thus, it is clear that it would be possible to extend the web hosting concept to a "commerce hosting" concept, limited only by the extent to which e-commerce really changed the way a given company did its business.

A second avenue for network-based application success would be applying hosted applications to problems associated with internal projection of data in web terms. Here, we are applying the e-commerce model without the specific link to an external e-commerce application.

One example of this would be the use of hosted applications to provide for intranet access to host repository data. If a company decides to web-enable a certain part of its MIS base, it would normally have to create a new set of HTML, CGI, Java, or other applications that linked a non-IP, non-HTML computer and database with a web-enabled set of users.

Imagine an ISP linked to an IBM mainframe data center via a high-speed SNA (or IP, if you like) connection through which DB2 queries could be entered. The ISP now hosts an application that uses CGI or Java to translate a user search request into a DB2 query. That application then formats the result as a table or a database, which it can then present to the user/requestor as an HTML page or as input to a Java applet. This application structure would enable a company to deploy web access to MIS applications without the development associated with internal intranet applications.

It may be clear by now that most of these application hosting application opportunities are linked to the concept of VPNs. Once we move out of the external commerce transaction space and into the supporting transactions whereby a company fulfills its orders and pays or collects for goods and services, we’ve moved into private networking. The user’s acceptance of the application support the carrier could provide would be conditioned on their support of the network services the carrier could offer to move the application data around. Thus, VPNs are a precursor to the use of network-resident applications beyond public hosting.

Some service providers see the light in this space. Interpath, a CLEC/ISP who has a "server city" full of hosting resources, has articulated a "mission hosting" strategy that recognizes the linkage between application hosting and VPNs, and that also provides tools to facilitate the development of mission-hosted applications for their subscribers.

The larger carriers, sorry to say, seem stuck in "Microsoft mode" with the concept. We think this is a dumb idea, and thus one that will ultimately contaminate buyer views of these carriers’ offerings.

The Telecom Act of 1996 was, like all political acts, formulated for a variety of political purposes. As is always the case, the Act juggles the various interests it represents, and nowhere is that juggling more significant than in the balance the Act seeks between fostering competition and promoting enhanced services.

As we noted in earlier issues, the question of how this balance was intended to be struck was the focus of RBOC appeals to the FCC last year. Citing the Act’s mandate for the FCC to promote advanced services, the RBOCs sought relief from the competitive wholesaling restrictions of the Act for advanced services like DSL and the Internet.

At the highest level, the FCC took an important position (but one we’ve told you it was going to take all along); the Telecom Act’s restrictions on the RBOCs apply equally to basic and advanced services. In other words, if the ILEC entity deploys infrastructure, it doesn’t matter what it’s for—they still have to wholesale it, and still have restrictions on in-region inter-LATA services.

At the next level, the FCC has focused on issues of competitive creation of advanced services out of RBOC UNEs. The FCC rules included the following:

1. The ILECs must make caged and cageless co-location space available to the extent that space exists. When that space is exhausted, the ILEC must make space available in controlled-environment vaults or other adjacent facilities, to the extent that is technically feasible.
2. ILECs must permit competitors to tour COs in which the competitor has been denied co-location, identifying the purposes of offices and other space and essentially justifying the assertion that no space is available. The ILEC must remove unused or obsolete equipment to make room for co-location.
3. Any co-location approach that is determined to be reasonable by a PUC for any ILEC is presumptively reasonable for all ILECs. This will reduce the ability of the ILEC to appeal each PUC rule to delay co-location.
4. ILECs may adopt reasonable security measures to protect their own equipment and the equipment of CLECs co-located within their facilities.
5. ILECs may not require new co-located equipment to meet more rigorous safety standards than they impose on their own equipment (by arguing that the CLEC personnel are not as technically proficient, and thus require greater protection, for example).
6. ILECs must permit CLECs building advanced services from UNEs to co-locate any equipment required for UNE interconnection, even if that equipment includes "switching" features that the Telecom Act specifies need not be co-located. ILECs cannot require these switching features be disabled.
7. The ILECs may not assert that certain xDSL technologies that have been approved for deployment by the FCC or PUCs, proven to be non-interfering in other installations, or conformant to relevant international standards, would interfere with operation of other services and thus may not be deployed.

The majority of these measures are directed at reducing the foot-dragging that most CLECs assert the RBOCs are employing to limit competition. By making ILEC obligations clear, the FCC is providing a mechanism to "fast-track" any legal challenges by simply citing this order as a resolution.

Line sharing could have a major impact on the market. While there are extra copper loops available to many business and residential locations, there are locations where there are no unused loops. Competitors who want to penetrate these locations would have to displace a service already installed in order to gain access to a copper loop UNE, and this would compel the competitor to broaden its service description to include the incumbent service—which the competitor might not want to provide. Line sharing eliminates this, and promises faster xDSL deployment.

The FCC has also indicated that it will address what was perhaps the main thrust of the original September NPRM—the conditions under which the RBOCs’ CLEC subsidiaries could deploy advanced services without wholesale obligation. That this, the primary focus of the original RBOC appeal to the FCC, should be left out of the initial order may seem surprising, but it’s not.

The FCC, according to insiders, feared that the endorsement of an RBOC/CLEC entry into the xDSL market would undermine the businesses of existing CLECs immediately, and that certain vague aspects of advanced services co-location regulations might allow the RBOCs to delay their CLEC formation and still hold competitors out of the market with regulatory delays. The timing of the orders in this area thus reflect a desire to first insure that CLECs have a sound foundation for their participation in the advanced services space, and only then provide firm guidelines on the RBOCs’ formation of a CLEC subsidiary for advanced services.

One might also note that the NPRM in September indicated that the RBOC requirements for formation of a "data CLEC" subsidiary were clearly called out in the Telecom Act, and thus didn’t require a lot of additional rule clarification. That’s true to a degree, but the current order does call out the areas where some additional regulatory input is needed.

The most obvious gray area in the concept of an ILEC/CLEC breakup of the RBOCs is the question of the handling of advanced services that cross LATA boundaries. The Act releases RBOCs to enter the long-distance market outside their regions. It releases the RBOCs for regional long-distance subject to compliance with the 14 competitive points. How would this impact a CLEC subsidiary of an RBOC? Would such a subsidiary have any limits on its advanced services scope? How would such limits, were the FCC to assert them, be reconciled with the way the Internet works—in-region or out-of-region web sites aren’t distinguished, or even distinguishable? Where is the "client" or "server" located; the physical location, the location of the network connection, the location of the ISP’s server farm, etc.?

The purpose of these rules is to insure that CLECs seeking to offer advanced services won’t be strangled by regulatory appeals on a myriad of issues in the co-location space. The FCC and everyone else knows that co-location is the key to this all, because without some effective co-location options, no CLEC can ever build an advanced service out of the integration of ILEC UNEs and CLEC infrastructure.

The direction the FCC is taking on ruling advanced services switching/routing features as subject to co-location requirements is a very significant one. Not only does it lift the uncertainty of interpretation on this issue (a critical point for any advanced service since it’s hard to see how one could be created without this capability), it suggests that the FCC may take a more liberal view of what kinds of switching may be subject to co-location in the future. That could bode well for the competitors who want to introduce some voice call routing in co-located hardware.

The line-sharing and spectrum protection issues are also significant. Without some FCC action here, it’s likely that ILECs would object to certain xDSL technologies on the basis of cross-talk impact on other services. This could stifle growth of xDSL-based data CLECs. Line sharing extends the relief in this area by insuring that CLECs would always have access to copper loop, even when only one loop pair is available.

In the long term, the biggest impact of this may be to encourage the CLEC split-off out of the ILECs, even though that issue wasn’t directly addressed in this order. The reason is that the formation of an RBOC CLEC subsidiary for data would have indirectly guaranteed most of what these new rules guarantee. Without effective co-location and access to copper loop, the RBOC CLEC would be as helpless as any other CLEC. However, if the RBOC could threaten other CLECs with its own entry into the CLEC space while still holding that space hostage to regulatory review, they could erode the capital access of other CLECs. Now, with the regulatory delays off the table, the RBOCs have no way to delay the market and they may be forced to quickly move to form their own CLECs and compete there.

There are few concepts as hyped in today’s market as the concept of "directories". We’ve got NDS, Active Directory, Directory-Enabled Networking, policy directories, policy protocols, and so forth. As usual, vendor attempts at creating differentiation have made it hard to navigate through the area with any confidence. Everybody seems to be touting a general truth but saying that their specific version of it is the only one that will work.

Access the index of CIMI Corporation's recent newsletters.