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.

The past decade of networking has shown that buyers are increasingly likely to view their own issues and the issues discussed in the media as things apart.  Frankly, there’s plenty of validation for that view.  It seems like hype is the product of networking vendors (and analysts, and the press) more often than technology.

As reasonable as this cynicism may be, it does make it difficult to move forward in a technology sense.  User problems tend to be related to current applications and current equipment.  Planning tends to focus on planning for familiar things, meaning validating current favorable technology experiences.  It may be hard in this model of user deployment of networking, to introduce something new—or even validate its eventual benefit.

Application service providers, or ASPs, are one of the darlings of the media today.  Many vendors and ISPs believe that the current lack of profit among the ISPs will be cured by their developing into ASPs.  The ISPs believe that because the alternative is rather stark and unpleasant—business death.  The vendors believe it because there’s more money on the table if the assertion is true.  Neither reason inspires tremendous confidence.

The basic premise of ASPs is simple.  Software is sometimes costly, in terms of license fees, support within the organization, or both.  While large organizations may be able to bear this cost out of considerable revenue flows, mid-sized and small companies are often not well enough financed.  Thus, they may be losing out on some really good stuff that their big brothers are enjoying.  Ultimately, this may impact their competitiveness.

Networks, particularly the ubiquitous Internet, offer an alternative.  Let somebody like your friendly ISP host the applications as they currently host web services.  The ISP pays the license fee for the software, absorbs the burden of administration, and maybe even offers technical support.  Access to the software is provided on the ISP’s network.  The user gets SAP or Peoplesoft for a few hundred bucks a month.  Great, huh?

Well, you’ve probably caught some of the flaws in the story already, but just in case you missed them, we’ll look deeper into the ASP issues and try to sort out the truth.

The first truth is that it’s not at all clear that there is an enormous number of applications that could be hosted in the way the ASP proponents want to make the concept work.  Here are some issues:

·         Will the license fees for the software be low enough to make the concept work?  Many have assumed that SAP or other vendors would happily license an ASP to serve a zillion users at the same fee they license their software to a single corporation.  Clearly that would simply encourage all the software firm’s users to work through intermediaries, and cut their revenue stream.

·         Do small to medium-sized businesses need this software to begin with?  There was life before SAP, after all.  In fact, many of the applications that these products are targeted at supporting (human resources, for example) derive from Federal and state regulations that don’t apply to small firms at all.

·         How much administrative and support cost could really be displaced for such an application.  We’ve gone months without ever being able to talk to a human at some of the ISPs we’ve used.  How’s your experience been?  Can you imagine saying to your employees, “Sorry, but we can’t pay you until the ASP calls us back on this?”  Most studies have dramatically overstated the amount of support resources that can really be outsourced with an application.

The second truth is that the ASP, as an evolution of the ISP, may be the least credible concept ever to hit a market that’s not particularly known for credibility.  Users today rate their ISP experience as the worst networking experience they’ve ever had, by far.  They rate the Internet as suitable to mission only about 58% of the time.  This is with a set of applications that, in the main, are not tied to business-critical functions.  Imagine what would happen if the same level of Internet availability were judged in relationship to a payroll application?  Question:  Do you want to be paid over the Internet?  Think about it.

Yet credibility of the ASP concept is linked completely with credibility of the network that will deliver the application to the user.  Yes, it is true that there are many happy Internet-based commerce companies.  They’re the same people who are able to buy SAP by themselves, no sharing at all, thank you.  To open the ASP market, you’ve got to dip down to the firms who aren’t big players who the ISPs willingly support well.  Down at that level, the level where the ASP concept has some theoretical credibility, ISP support is appalling according to our surveyed users.

There are responses to both these major points.  The question is, are they credible?  We don’t think so.

Some have suggested that the question of what software the user wants from the ASP can be resolved by moving from targeting SAP to targeting Word and Excel.  We’ve noted in the past that it’s not credible to assume that personal productivity software of this type would be hosted because its cost is too low, its performance demands are too high, and supporting it on the network would be like recreating Microsoft’s support organization but making it really responsive.  There are some specialized plug-ins and applications that could be hosted for small to mid-sized businesses, but not enough to save a couple of thousand revenue-starved ISPs.

Some have suggested that since bandwidth is going to be free anyway, everyone will have the equivalent to an SCSI in bandwidth connecting them to the Internet.  This would make hosting Excel on an ASP equivalent to running it from a local drive.  If you believe this, we’re really sorry for you and we think that maybe you should stop reading Netwatcher and start on gothic novels.  If we haven’t said enough to date to prove the essential idiocy of this view, we’ll never be able to say enough!

Then there’s the “Users are being driven…” group.  Higher administrative costs associated with software updates for things like MS Office are killing the little guy, so these pundits say.  The users are being driven to outsource their applications to avoid these costs.  Yea, right.  Didn’t these guys ever hear of the “I don’t need this version so I won’t update” approach?  There are millions of people running on versions of MS Office that pre-date even Windows 95.  For them, the cost of the ASP hosting would have to be justified by the warm feeling they had over running the current version of something whose version number they don’t even know today.

As we’ve noted in the past, there are some applications that can be credibly hosted.  The best example is the e-commerce execution application that takes credit cards or e-cash and dispenses instructions for the application owner to fulfill a retail order.  With an application like this, a small-time organization could get into direct Internet sales without having to take credit cards, account for the transactions, etc.

Why aren’t we talking about these applications, then?  Because they don’t meet the basic requirement of the whole ASP space, which is to save the ISP.  The problem with stuff that users really want to do is that it has a troublesome tendency to generate actual results, which then seem to constrain our wild flights of fantasy.  If we had a real flavor for what the ASP business could offer financially, it would prove to be a good business in a real sense, but not good enough to keep the wolves from a bunch of silicon valley doors.  Thus, we stay with the hype.

Well, folks, the hype is wrong as usual.  There will certainly be some success in the ASP space, but there will not be nearly enough to save the ISPs.

But there is still a business, and there are still issues that we must address in looking at application hosting.  Two, in particular, come to mind; network framework and client access.

Users, according to our research, want application hosting to take place in the context of a VPN.  In other words, they expect the overall framework for application security and availability/performance to be established at the network level, and from the same supplier who would offer the application.  The good news for ISPs is that the network provider is, in fact, a credible source for application hosting.  The bad news is that the ISPs would have to buttress that credibility by improving their VPN service offerings versus their standard Internet offering, to meet user availability requirements.  A private network today is suitable for mission over 90% of the time, versus the Internet’s 58%.

Assuming that the network was in shape for ASP features, there’s still the question of how a hosted application appears to a user.  Does a shared SAP application have an IP address for every possible user?  If so, how is that address translated.  If not (if there’s a single “SAP host” address), how do users access that address without exiting their VPN (which, presumably, contains their own addresses only)?

Then there’s the question of client access.  Does the VPN’s security and admission criteria provide the filtering of who is allowed to use the application?  If so, it assumes that there would be little or no price penalty for a buyer who elected to buy two or three VPNs, versus a single VPN whose traffic commitment was the sum of the many.  Do we know if that will be true in VPN offerings?  It isn’t true with public frame relay, remember.

Is there a policy-managed filter to these applications, then?  If so, who manages it and supports it?  Buyer literacy in policy management is down in the noise level even in larger companies, and for mid-sized and small ones it’s possible that the policy management burden would equal or exceed the application administrative burden the ASPs are proposing to eliminate.  One deadly sin is as bad as another, as any confessor will tell you.

In the next several months, we’ll be looking at the details in each of these two critical technology areas of the ASP opportunity.  We want you to keep in mind during this review that we absolutely do not validate the conception of the ASP market that is widely held in the industry (those who know us won’t be surprised; we hardly ever validate a popular trend).

There is a legitimate question of the impact of changes in the service provider market on the application relationship.  Some of those changes (the Internet’s impact on software distribution and support, for example) have already been felt by many.  As networks change, the financial trade-off between local and remote applications also changes, and it would be silly not to assume that these changes would not somehow impact how applications (or access to them) are sold.

We all think of voice and IP together these days, but usually we think in terms of voice being contained in IP as a transport network.  That narrow view (“convergence”) is now losing favor with the media, and there is a good chance that this loss of media backing will submerge both the overwhelming hype, and the few legitimate technical points.

In the last couple of issues of Netwatcher, we’ve explored a lot of the technology of next-generation voice (NGV).  This issue will examine how NGV technology and application will interact with the Internet.

The business challenges of CLECs have been discussed in the forum of this newsletter in the past, but most often in terms of what was causing the challenges.  It’s nice to know why you’re in trouble.  It’s nicer to know how you might get out of it.

According to the telecom act, a CLEC is a service provider who has a local exchange service mission, meaning one that offers local voice telephony.  This nice firm definition has been corrupted, as you might expect, by market conditions.  Today, there are a number of very different types of service providers that might classify themselves as CLECs, and we’re going to have to distinguish among them if we’re going to address how they might respond to their specific competitive and business challenges.

The first type of CLEC is the “pure” CLEC, a firm who enters the market to be what the acronym stands for—a competitive local exchange carrier.  Most such companies today are involved in passive resale of the service facilities the RBOCs are required to offer at wholesale prices by the Telecom Act.  We’ll call this group the Purists.

The second type of CLEC is the firm who elects to offer local exchange services to extend a business the company is already in.  Thus, a service provider with a less-than-full service repertoire decided that local telephony is a service the competitive situation demands, and becomes a CLEC to offer it.  We’ll call these guys the Exploiters.

The third type of CLEC is the firm who elects CLEC status to gain access to the wholesale unbundled network elements (UNEs) the Act defines, but who does not really plan to offer local telephony, or at least no more than the law demands to sustain a claim of CLEC status.  We’ll call these the Pretenders.

Purists and Exploiters are both faced with the problem of validating their services against an entrenched incumbent.  They probably rely at least in part on the assumption that the incumbent will have to sell based on fixed tariffs, and they can thus gain an easy economic advantage by discounting a few percent.  This lets them get low-bidder status for those RFPs which mandate accepting the low bid, and it keeps them in business.

The business challenge they face is based on margins.  These two classes of CLEC can’t earn a large margin based on the current wholesale-to-retail spread (about 23%), so their return and profit are probably too low to finance any dramatic build-out.  It’s possible they could raise some seed money in today’s hype-driven financial market, but they’d have to transition to something other than simple discount-driven marketing to win.  The expected entry of the RBOCs into the CLEC space with a series of spin-offs will only exacerbate this problem by reducing the margin on voice.

The Exploiters and the Pretenders are faced with another problem, that of full-service demand.  Buyers are sensitive to total cost and not to cost elements, and discounting on the part of full-service carriers takes place across the whole service base.  Since neither the Exploiters nor the Pretenders are looking to be real full-service voice players, they’re shut out of the portion of the market that earns the most revenue.

What’s the Answer?

Make money like a son-of-a-gun, obviously.  The question is “How do you do it?”

First, if you’re a CLEC, you have to move quickly while the market still believes in them, to seize the capital resources that Wall Street is willing to commit.  Things are going to get real ugly soon, and those capital sources will dry up.  Even an IPO might be a reasonable strategy, if it can be carried off quickly.

Second, immediately make plans to become both service agents (resellers) and service providers, in a facility sense.  That means deciding on what their own networks can do (if anything) and making moves to build a network to do other stuff, to buy services from multiple sources, and assemble a complete service set.

In doing this critical step, you must be ever aware of the issue of margins.  The early stages of any carrier’s life are dedicated to building a credible service geography—what can be called a “positioning deployment”.  This phase is incredibly capital-intensive.  If it lasts too long, demands for cash outstrip the financial market’s willingness to fund, and you the CLEC go down the proverbial tube.

Two factors are necessary to sustain margins in the early deployment phase:

1.       Careful attention must be paid to voice service features; the stuff we call “custom calling” and “Centrex”.  Basic residential or business telephony won’t provide enough revenue gain to survive, and the need to attract customers at a reasonable sales/marketing expense may force discounting if features cannot be provided to draw users to the CLEC’s services.

2.       Some form of data service, preferably one not projected at a very low level (xDSL or frame relay, for example) must be offered.

It is our view that CLECs who buy nothing but basic Class 5 and even Centrex features are dooming themselves to death.  This set of features simply puts them at parity with the ILEC incumbents.  That’s better than being behind (because the CLEC would have to discount big time to come from a position of feature disadvantage to secure a win), but it’s not good.  “Good” would be having features the ILEC didn’t, which is why most CLECs should be looking at NGV technology rather than traditional switching.

The data side of the picture is more complex.  The problem here is the geographic scope of the CLEC, so we have to phrase our recommendations based on the classification of CLECs we used earlier.

The Purists are almost certain to have a very limited service geography—a metro area, for example.  For these CLECs, the only service option is transparent LAN (TLAN).  Since this service has a knee-jerk metropolitan-area association among buyers, a TLAN service salesperson won’t be running into questions like “What about my office in Oshkosh?”  Sales personnel get demoralized easily when all the sales objections are so fundamentally impossible to deal with that there is little chance any rational response will ever be provided.

Most Exploiters and Pretenders will have less a problem with an explicitly limited target geography as with the problem of having too much target geography to support with infrastructure.  An ISP, for example, has to reason that data services like the Internet clearly aren’t going to advance them into the wonderful world of profit because they’re already providing that service.  Something new (like facility-based IP VPNs) might or might not be possible based on the way the ISP/CLEC built the network.  Data CLECs like Covad or Northpoint have spread themselves around the country at the access level, and possibly compromised their ability to link their enclaves into a single national service.

For the Exploiters, as our ISP example indicates, the hope would be that the baseline services already offered could be profitable enough to sustain margins.  If that isn’t the case, then other services that could be offered from modest changes to the existing services’ infrastructure would be the next best bet.

For Pretenders, the islands of existing services built on UNEs (like xDSL Internet access) have to be integrated into a common service base.  This might mean becoming an ISP (but think about how profitable current ISPs are), or it might mean creating some new data service idea.

Like what?  OK,  this model will work to a degree for all types of CLEC.

First, establish local data service enclaves based on xDSL, ATM over xDSL, and TLAN.  These services should be sellable to any multi-site business contained in the region, or any portion of a national multi-site business who has at least a couple of offices in a given service area.

Second, establish the TLAN service as the access vehicle for both Internet and IP VPN services.  A virtual router on a TLAN would provide all the TLAN sites access to the Internet.  Another (or the same one, if you’re into conserving virtual resources) would provide access to VPN services.

Where do the CLECs get these services?  If they don’t have their own facilities to provide them, they wholesale them from somebody else.  Qwest, Level 3, and Williams, to name a few, are eager to enter into deals with carriers to sell national-scope bandwidth and services.  Grab onto one or more of these guys and make a good deal.

This gets back to the key point we made earlier.  You have to sell everything, mister CLEC.  That means you broker what you don’t or can’t build.  You start off your marketing activity with a complete service set, even if it means buying nearly everything from someone else (the Purists who are simply reselling RBOC services won’t find that uncomfortable, at least).

To keep up margins on those wholesaled services, we recommend that CLECs always buy low-level services like ATM or frame relay, and use their own equipment to link them upward to the IP level.  A CLEC can expect no more than about 30% margin on reselling a long-haul provider’s service in the same form he bought it, but could gain over 33% margin from reselling frame as IP VPNs.

The same strategy should be used in the voice space.  Buy national-level bandwidth to link each of your CLEC service enclaves, if you have multiple sites (as an  Exploiter who is a data CLEC would).  If you have only a single site, provide bundled long-distance services from the provider who offers both a good margin and good quality.  The margins on reselling voice services aren’t high enough that you can afford to poison customers with bad experiences on their long-distance calls.

Finally, expand into new cities by first wholesaling facilities from the ILECs there, and then building out your own stuff when customer density permits.  That will guarantee a careful use of capital resources.  The best target cities for secondary growth are those that have a large number of common companies with the home region city or cities.  That not only provides reference accounts, it creates an opportunity to build your own voice/data intra-company service set to these partner cities.

Careful use of wholesaled services at both the local and interexchange level will be key to guarding margins.  With the use of resold services, it’s possible to establish a presence in a market area without a large up-front investment in anticipation of demand.  The wholesale services also offer a way to quickly establish a credible presence in a set of cities that house partner sites for key clients.

With careful planning, most CLECs with access to capital in the current market could expect to build a profitable business.  Without both these assets, you’re doomed.  Sorry, but that’s the truth.

Access the index of CIMI Corporation's recent newsletters.