The ASP Wave: Bill or Bail Water

The application service provider (ASP) market resembles a mere ripple far out at sea. Yet by the time it hits the shore it could have the size and velocity of a tsunami, washing over the world of communications with even greater speed and impact than the ISPs did. ISPs themselves may become ASPs, and smaller regional ISPs may face a tough battle against virtual ISPs that have established a business relationship for ASP services beyond e-mail and access. New skirmish lines are being drawn every day.

This market is estimated to reach $20–$30 billion by 2003. The ASP market—including companies like Equinix, Usi, Applicast and Interpath—will lure network service providers (NSPs); traditional carriers such as LECs, IXCs and PTTs; and ISPs and integrated carriers. VARs, systems integrators, data centers, service bureaus, content providers and independent software vendors (ISVs) are all moving to this market.

The business drivers are no mystery. “A number of factors are driving growth in the ASP marketplace,” says Jennifer Kula, senior consultant at TeleChoice. “Topping the list? IT shortage of application experts, total cost of ownership of data centers, and faster application deployment enterprise-wide.”

According to Kula, the ASP value chain comprises three major groups: the ASPs themselves, who implement, deliver and support software; the application infrastructure providers (AIPs) for data center capabilities such as access, network monitoring, and processing and storage; and the application integrators and software vendors.

Surf’s Up ASPs will require intensive bandwidth on the delivery side, so initial chokepoints will be at the LECs, especially in outlying areas, and in residential neighborhoods too far from the ILEC/CLEC switching facility to benefit from affordable access products such as DSL. Sub-second software response won’t work without plenty of bandwidth, and applications must process quickly or drown.

“Bandwidth is key. As DSL providers, access providers and software providers play a pivotal role in the success of ASPs,” says Kula, “ASPs will demand more from these vendors in terms of service level agreements [SLAs].” Journalists and analysts who expect a bandwidth glut do not see the ASP wave heading toward the beach.

The ASP market itself concerns developing, delivering and supporting software—chiefly, but not exclusively, browser-enabled software, be it the near-and-dear e-mail (and its variants) and growing VoIP; financial suites from SAP, ADP and Oracle; or knowledge management from Synergistics.

EDS will offer Synergistics’ products in its wholesale apps rental service (hosted in existing EDS data centers), and some of the NSPs and hybrid companies such as PSINet and USi are offering financial applications from some of the above ISVs. Applicast even offers front-office applications, such as Siebel and BroadVision, which can be used in a number of vertical markets: retail, travel, finance, manufacturing, and even telecom.

With a different twist, ASP Portera develops its own applications—mainly business services software and enterprise resource planning (ERP)—for subscription use by clients in consulting and professional services.

Add yet another major player to the fray, a combined AIP, now that Level 3 and Convergys have agreed to develop and market advanced Internet solutions. This alliance will integrate Level 3’s OSS with Convergys’ business support systems (BSS) in a turnkey approach. The BSS applications will be hosted at Convergys, and Convergys will add outsourced marketing capability, such as call center support, through its existing capabilities. Service delivery is end-to-end.

“We wanted to lower the barriers of entry to almost any Web-centric pursuit,” says Ed Magnowski, vice president of strategic alliances-information technology practice at Level 3. “The approach with Convergys reduces the worry about back-office processes. So this alliance is a true business enabler, allowing the clients to focus on their core business.” By making its Softswitch technology as open as possible with APIs for people to build applications against, Level 3 plans to enable an “xSP” development environment, where the xSPs can develop application-based access and network-based application functions directly to the Softswitch and Level 3 network in real time.

Davinci, an ISV with a wireless inclination, takes a different approach. “We are offering product opportunities for telecommunications carriers to get into the ASP market, and to provide wireless capabilities for ASPs already in the business,” says Steve Rodin, the company’s president. “Davinci provides a platform by which we can deliver wireless applications, and those applications can be shared among a number of users—the ASP’s own customer, such as the telecommunications customer, or the telecommunications customer providing services to their business customers, or in turn providing service to the business customers’ end users.” This platform could be a wireless VPN for application use within their own company, or a wireless portal. Davinci also offers an electronic bill presentment and payment product, along with customer care self-service products that include feature activation and delivery of customer service information via wireless devices and the Web.

While the ASP market today is not dominated by Sun Microsystems’ Solaris servers and Java code, Sun’s tagline—“The network is the computer”—is the next wave about to breach the communications seawall. In fairness to Sun, the penetration of its servers and code is quite evident. Leading software vendor Solect runs its core product on a Solaris platform, with Unix. Microsoft will likely build on its servers market, its own access market (MSN) and massive software markets, and leverage its investments in NSPs and in content providers. A good percentage of end users may end up looking at screens similar to the ones in Microsoft Office and Windows that they already know. But the applications will not reside on the PC (except for a client, such as a browser or Citrix solution), and it will not be hosted on the enterprise’s servers, but elsewhere. It could be sitting in a BT or EDS or Exodus data center somewhere.

James Landsman, director of EDS’ wholesale applications rental service, sees a clear preference for browser-enabled applications. EDS’ wholesale offering runs on either Unix or NT, depending on the application. “This model for our wholesale architecture gives subscribers anytime, anyplace access for applications,” says Landsman. “This access could be over public Internet, or where performance is paramount over private or virtual private IP networks.”

But the ASPs are not just about software applications executable through an HTML or other interface. They are also about transport, access and bandwidth, hosting and partnering, provisioning and activation, and customer management, data collection and billing. Being without good billing is like being up a creek without a paddle, but in this market it’s more like being on a tidal wave without a raft. If you can’t bill for it or collect it, it doesn’t matter how fast you can bail water—eventually, you’re going under.

In this new ASP world, the end user (or end enterprise) needs to be provisioned and billed in a time when capabilities such as billing for VoIP are just being refined by the billing ISVs. There are not yet ASP pure plays, in which the ASP tends end-to-end (even USi outsources the transport component). As numerous ASP business models emerge with varying degrees of outsourcing, functions such as provisioning, billing, and customer and service management must occur between businesses, as well as with the end user or subscriber. So if a data center is functioning as a service bureau and renting applications, as with the EDS approach almost ready for market, then the billing and revenue sharing can get a bit tricky. Not only does the revenue relationship between the data center and the software vendor need to be resolved, but also throw in a layer for an ASP leasing transport and access, too, or a virtual ISP leasing space and applications, then stir in the end users or end enterprise. The economic models are in turmoil.

In the case of AIPs like EDS and GTE—building off data center and service bureau strengths, respectively—the big systems integrators offer billing (or billing capability) through a relationship with an ISV in a proven environment. This arrangement leverages some of the same advantages seen in telecom service bureaus: low start-up costs, proven expertise, low per-unit operating costs, scalability and short time to market. For example, GTE can take Solect’s IAF product, spin it through the branding mixer, and out comes NETime. This new product can be used for hosted applications, or by a hosted application to bill its end users, or leased by an ASP or ISP to bill its subscribers. “We are building our wholesale offering on two levels,” says EDS’ Landsman. “We do not make the assumption that every general partner we sign is going to want to have a significant billing capability, so at the first level we can interface with their existing products and provide them with an invoice-ready type of feed. Or, we can bill for them to the end client.” Which level makes the most sense will depend on the capabilities of the EDS customer, just as in the telecommunications wholesale environment.

The Product and Pricing Plunge

Are pricing models floating billing, or is billing floating pricing models? By analogy, recall that when frame relay was launched, no one could bill other than on a fixed-rate basis, and it was easy for each carrier entering the market to follow suit, whether billing had gotten more sophisticated or not. Complacency in pricing and billing is what the market had come to expect from the very first frame relay roll-out, and it was easier to accommodate along the way, from carrier to carrier.

Capabilities available from vendors such as Solect, Portal, Convergys, Davinci and XACCT translate into creativity and flexibility for the product and pricing people—for all the different application components ASPs are offering, from e-mail to VoIP to ERP to Web hosting. Although the current ISP model of a monthly fixed rate for dial-up access and e-mail may be around a while, the more recently offered applications have the opportunity to drift away from the fixed-rate doldrums. It is always there as a pricing option when it makes sense. But even something as mundane as e-mail will probably see change.

“There is a difference between an end user passing 20 text messages a day, and a user packaging “Gone with the Wind” in an e-mail and sending it out to 5,000 recipients,” says EDS’ Landsman. “ASPs are looking for ways to define these differences, and we can distinguish between these types of usage and create billing and pricing scenarios based on that.” EDS is building its wholesale capability from the ground up, soon to be launched at its Plano, Texas, data center. EDS sees four dominant pricing models: monthly; deriving transactions based on what someone is doing with an application by interrogating IP packets; pricing based on packaging; and pricing based on what the user is doing with an application.

Unquestionably a part of service definition, product pricing deserves a placeholder of its own. At least on a per-unit basis, product pricing is about projected margins, which providers either make or go mad trying to make. An interface to build and define product attributes, and to establish and modify pricing, is like having a thumb on your hand—it is vital for full dexterity. And to regress to the legacy telecom world of batch processing and waiting months for IT to change a rate buried somewhere in a subroutine is to die a watery death.

Bill, Don’t Bail

“A lot of the billing vendors today,” says TeleChoice’s Kula, “can’t handle the applications offered by the ASPs, such as ERP, collaboration, expense management, travel management, videoconferencing. The real key part is joining the network to the subscriber management and billing systems, and extracting the information out of the network in a readable format for the billing vendor.” While the downstream portion of most billers can handle ASP services, the extraction of data off the network is the issue. To a lesser extent, customer support functions need to be modified, and for providers billing in a paper world, formatting may take a twist or two.

Although the ASP customer base is a mixed bag, and will become even more so, some requirements sought are branding capabilities, SLAs for items such as quality of service, top-notch functional solutions, and scalable and extensible solutions, to name a few. For the ISP as the ASP’s customer, or for the ASP as the wholesaler’s customer, or any combination that can be dreamed up, this also translates into flexible rating and pricing plans, electronic bill presentation and payment, auto-registration and customer self-care—in the BSS and revenue assurance domains, for sure.

The whole point in the ASP market is to do all the billing and related activities done in other communications segments, for similar and radically different services: develop, price, order, provide, activate, authenticate or authorize, use, collect, mediate, rate, calculate, discount, invoice, report, account, service, manage, and then some.

Kula speculates that more billing vendors are not pushing into this market faster because a divide has grown between IP billers and non-IP billers. “They’ve segmented themselves—either they’re strong in wireless, or they are strong in cable, or they are strong in traditional telecom. It’s not that they can’t handle it—it is just quite a marketing feat to get there.” It may be more important than some vendors recognize, because moving to the world of IP may look like convergence today, but much of the ASP activity is not convergence opportunity at all—it’s new.

“IP-based billing is not about convergence,” says Solect’s Michael Couture, product managers of ASPs. “It is a conversion.” As carriers such as Sprint embrace moving to an IP network, and as carriers such as Level 3 build an IP network from the ground up, such statements grow more credible. If the large contingent of BSS vendors are to enter the ASP market or even get more involved in IP billing, they need to turn to and tack quickly into the wind.

The comprehensive functions and capabilities common in other communications segments are recognizable in the ASP space. Interfaces must be established to core network elements for provisioning and mediation back toward the BSS. This includes management and configuration over the full gamut of different routers, gateways and servers for calls, messages, applications, and so on. User authentication is a big issue from both a revenue assurance and security standpoint, and many vendors are building capability around specialty servers, such as RADIUS or CiscoSecure, for control. Statistical collectors, such as those from Cisco, and mediation devices, such as from XACCT, ensure that data bursts, calls and ERP application transactions are pulled from the network and formatted into usable records for billing, to be rated and blended with pricing components such as QoS and cross-service discounts.

Before this can happen, though, there must be definition of service, or what makes an application a service. “Service definition enables the logical definition and physical mapping of services to applications, defines the attributes of the service to be collected for rating, and provisions for service personalization and activation,” explains Solect’s Couture. “Billing and customer management are categorized into what we refer to as the service provider domain. This includes service definition, user and account management and security, pricing and bundling, usage collection, and rating and billing.”

As an example, a business may establish a relationship with an ASP for use of ERP software, such as financial and human resources suites. The ASP provisions what, when and how the business accesses and uses the software, such as how many users, what segments of the software are available, and to whom. The business acts by establishing user controls so that the employees may inherit the subscribed capability, or they may apply additional filters at the user level. For large customers all the usage and/or consumption enterprise-wide could roll up into hierarchy billing structures. Generically, when subscribers attempt access to the network, the authentication/security server gets the log-in requests from the different devices. It validates and correlates customer profiles and user IDs, and cues the application-specific device as to which services to make available. In the case of Solect’s IAF, all of the interfaces for service definition and administration are HTML-based. Solect’s Couture points out the cost advantage of having customer self-care: decreasing reliance on a call center for service and account support, especially in environments with lower-cost HTML front ends.

As part of the authorization process (and the pricing profile), QoS is considered, as well as control of port allocation, and certain customer self-care functions, such as the purchase of services and posting of funds for prepaid accounts or to settle accounts. Vendors such as Davinci, with its electronic presentment and payment capability, not only enable these features for ASPs but also offer wireless and wireless-Internet capabilities. “Our capabilities are device-agnostic,” says Davinci’s Rodin, “and are built on a Java platform for use with Unix or NT. Our systems allow delivery to Palm Pilots, to the Web, to anything you want.” Besides the billing and payment product, Davinci’s customer self-care allows feature activation and rate plan subscription changes. Its products have rules-based engines, business and data, and deploy a scripting language for business development.

Mediation is the line customarily drawn between the network and OSS, and billing and the BSS bunch. It was thought until recently that these lines would diffuse further. Not so, by some opinions. While OSS and BSS are intrinsically bound, even in the rising tide of the ASP market, mediation capability is a must, and it stands in the middle between the network streams and the revenue streams. While an ASP network source must create suitable log files like any source data generator in order for mediation to work, mediation processors are taking on a different look and feel. They must be able to mediate and massage data and information from video streams, voice and data traffic, software usage, contact management, and calendars into billable formats.

“With IAF Horizon, we use PDCs, or provisioning and data collection, to provide bi-directional interfaces to different network services,” says Solect’s Couture. A collection agent (PDC) sits on the network host, access server or Web server, on or by a network element. The agents collect pieces of data of interest, and send them back to the central server. For some services, Solect relies on the agent already built by XACCT or Narus, rather than reinventing the wheel. Instead, it builds a PDC specifically to collect from XACCT—thus taking a step back.

The PDCs are shipped with descriptions of all provisioned, managed and collected attributes for the respective services, such as FTP or telephony. Currently, the PDCs are standard and developed by Solect, and are not configurable by the ASP customer, although a third-party software developer’s package is now available. Those customers with the desire and in-house resources may develop PDCs themselves. However, the overall development approach simplifies implementation, and new agents can be introduced as the market demands.

Sink or Swim

Although some contend that real-time rating and data availability are critical in the ASP world, their argument may hold water only for prepaid services: once a prepaid account is depleted, the provider does not want to realize a week later, or even a call later, that the subscriber got extra goodies. This is not to say that real-time rating is not highly desirable; but if extended throughout the billing life cycle it may be expensive, and in a credit-based economy we do not characteristically live and die by real-time billing. Initial (raw) rating of “calls,” whether voice, data or video, absolutely has its place: in credit monitoring and thresholds, in certain types of fraud profiling engines, in analytics and dashboard EIS for finance and marketing. The uses of data available in an immediate fashion are limited only by imagination and functional capability .

Displaying all billable events and items in real time, such as on a start page, may wreak havoc with volume discount schemes, step or threshold, especially at a business level. The true-ups could prove meddlesome to provider and customer alike.

In the ASP market, just as in the communications segments, when a user logs in and is authenticated, the system must immediately precalculate what the user has left, based on the pricing plan and services available. This engine could end up doing double duty, if the user makes a voice call while simultaneously streaming video. Regardless, the usage must be ticked off in real time, or must be provisioned anew if the user provides funds. This whole process is iterative as the user logs off, logs on, pays more, uses more and continues the cycle.

Meanwhile, billing calculates usage or other measurable product parameters that have been extracted from log files or similar mechanisms, whether it is duration of use, how many times a feature is used, the number of bytes stored, or how many messages or megapixels are passed. The metric will vary by application, and new applications with new metrics will keep coming. The billing system must bill for them. Solect uses a rules-based rating engine (co-developed with Telcordia), as do most vendors in the IP and ASP space.

The remainder of the process beyond product definition, assignment of service, usage and collection is not a mystery. Once rates have been applied to application or product metrics, the job of calculating may require re-rating, discounting and promotions, hierarchy roll-ups, and inevitably complex taxation. After this occurs, bills, whether electronic or paper, need to be formatted and rendered, then dispatched to the customer and to the customer support environment. Feeds are sent to the systems for general ledger, accounts receivable, sales compensation and marketing analysis.

On the Beach and Beyond

Key differences arise in billing, as an enabling system, when it moves from traditional telecommunications to the ASP world. It becomes less of a once-a-month event to the customer, moving away for the slicing and dicing of monthly invoicing, and migrates to a near real-time environment of I-billing products, at least from a presentation standpoint.

While I-billing is making inroads in telecommunications bill delivery, telecommunications remains without question predominantly paper-based. But while ASP and e-business offerings may still display one-liners on a paper credit card statement, and will for quite some time, the detail will be accessible at a key portal, personal start page or similarly conceived Web location—which simplifies inquiry.

It can be argued that the bill will be preempted as the recurring point of sale, which has been so important in telecommunications, and will be replaced by whatever browser-enabled e-place the user clicks to see billing information, product information, music choices, and so on. “The beauty of this market,” says EDS’ Landsman, “is that the provider gets to touch the customer every time they turn on the computer, not just once a month.”

In any event, the same lessons that have been so painstakingly learned in other communications segments can be applied to the ASP world, and the world of e-business: be concise, be clear, be communicative. Many of us have looked at enough telephon-ese, messy Web sites, and barely navigable applications to have heard the clarion call: either catch the wave and ride it to the beach, or get dunked.

Frank Slavick is a communications consultant based in Boulder, Colo., specializing in product development, new business development and business support systems. He can be reached at 303/554-0958, or at fslavick@earthlink.net