Computer Finance Research

Web Impact On Software Pricing

Issue Date: 10/01/99
Issue Number: 10.05
Category: WEB PRICING

History is proving software licensing to be quite cyclical in nature. Almost three years ago, we studied client/server software pricing (see Computer Finance, January 1997) and found user-based pricing predominating over processor (usually MIPS-based) pricing that was traditionally prevalent in the mainframe field. Fast forward a few years, and it appears that we are going forward into the past. With client/server architecture costs of ownership proven expensive, and the emergence of the web, the IT world is re-embracing server-based applications.

On the surface, it appears that the software licensing pendulum is swinging back to processor-based pricing. In fact, the real picture is more nuanced.

In the client/server era, processor pricing wasn't dead. For instance, databases relied on hybrid processor/user-based pricing tiers. Some enterprise applications, such as PeopleSoft, relied on a form of 'enterprise tax,' where pricing was often based on the size or revenue stream of the organization.

In the emerging web world, CPU-based pricing is reemerging, but user-based pricing isn't necessarily dead. Making matters more interesting, with the web introducing new opportunities both for commerce and application hosting, software vendors are exploring new pricing options that could include rental, subscriptions, commissions, or in some cases, 'value' pricing where the vendor takes a cut of the supposed cost benefits of a rollout. With the web opening new business opportunities, prominent software giants such as SAP and Oracle are planning to morph into retailers or wholesalers. Additionally, the emergence of Application Service Providers (ASPs) is introducing the notion of application rentals or subscriptions. This report surveys a cross section of enterprise software providers, in areas ranging from databases to enterprise applications (e.g., ERP, CRM, supply chain management), business intelligence, and web commerce to gauge how the web was impacting their licensing practices. In a companion report in this issue, we also explore the ASP route.

THE MORE THINGS CHANGE

When it comes to software licensing, there's a lot to learn from the past. When we examined the issue in 1997, we found extreme volatility: debates over the merits of named vs. concurrent user pricing, questions on whether usage-based pricing was workable, and almost universal disdain for CPU-pricing.

And, being prior to a wave of consolidation in the software field, we found supply and demand patterns quite different from the present. At the time, in many sectors (e.g., database, development tools, systems management, etc.), the market was far more competitive. There was published list pricing which, in most cases, tended to be overshadowed by specially negotiated deals.

Table 1. Comparison of software vendor web licensing schemes
(Source: Computer Finance).

Category	Vendor	Product/Service	Web Licensing Criteria
Database	IBM	DB2 UDB/Enterprise Edition	CPU (unlimited connections)
	Microsoft	SQL Server 7.0	CPU (unlimited connections)
	Oracle	Oracle 8i	CPU (based on power units)
Enterprise Application	i2	RHYTHM Exchange Services	Depends on service
	SAP	MySAP.com Workplace	Named user (based on role)
	SAP	MySAP.com Marketplace	Depends on service
CRM	Clarify	E Front Office	CPU, Named user, Concurrent user (depending on module)
Business-to-Business	Ariba	ORMS	Transaction volume
Web Commerce	Ariba	Ariba Network	Per transaction (flat fee or % of transaction price)
	Extricity	Alliance	CPU (subscription financing also being introduced)
Business Intelligence	Cognos	PowerPlay, Impromptu	CPU, Named user, Concurrent user (depending on module)
	Microstrategy	DSS Web	CPU and named user

Today, negotiated deals are still the rule (some things never change), but the balance of power has changed. In some arenas (e.g., databases, platforms, office suites), the choices are fewer, thanks to ongoing market consolidations reducing the number of players. On the other hand, some sectors—such as ERP—have become buyer's markets because demand has dropped. Significantly, the ERP vendor community, after the heady years of the mid 1990s, are facing pressures to drop entry-level prices in order to attract business from the relatively untapped $50-$250 million revenue middle market.

How has time impacted the major factors impacting software value? In our previous report, we listed a number of determining factors, including usage, functionality, necessity, avoided costs, added business value, and the degree to which there is competition in a particular software market.

WHAT'S CHANGED?

Usage. Theoretically, usage-based pricing should be the fairest way to determine the fair market value of software-unless you actually do some activity-based accounting to look at the dollars generated for the customer (more about that later). Three years ago, the client/server wave was beginning to expand the end user population for applications, compared to legacy systems. In organizations where accounting systems had dozens of users, enterprise transaction systems broadened and integrated the functionality, expanding the user base to hundreds.

Most client/server software providers embraced user-based pricing by software module or functionality. That's exactly how SAP and i2 licensed their client/server packages. In SAP's case, it was a choice of named or concurrent users, weighted on how they accessed R/3's modules, which modules they accessed (some were bigger than others), and how many modules they accessed. For i2, which only offered named users (since its end user populations tended to be far smaller), the weighting was based on the quantity of models used and their respective size/complexity (number of variables or constraints).

Today, with intranet-based applications providing simplified front ends to reach less computer-literate users, the potential user base expands often to thousands. And that's only internal users. With organizations building extranet applications for business partners and Internet applications for the general public, the size of the potential user base is only limited by the imagination.

So how do you measure usage? In the mainframe era, it was typically measured in MIPS, with the idea that, the more powerful the processor, the greater the capacity for the platform to provide more processing of more application functions to more people. Obviously, MIPS had its shortcomings. For instance, it discounted the impact of connectivity and failed to account for memory/cache (which indirectly adds to overall processing capacity by reducing time-consuming I/O). And IT organizations were not always thrilled when a new machine upgrade suddenly bumped up their software license fees, often without warning.

In the client/server era, the operable notion was counting the number of users: either the number of named (registered) users, or the maximum number of concurrent users (the latter was a smaller number since few if any systems ever have 100% of all named users hitting the system at once). The obvious shortcoming was that, for named user schemes, not all users work with the system equally, and for concurrent users, that peak loads are not always representative of typical utilization.

So, if counting users wasn't fair, how about counting actual usage? Three years ago, there was little precedent for usage outside the time sharing world, and no consensus on how best to meter it.

Since then, IBM introduced ULC (Usage License Charge; formerly known as MULC) for CICS, DB2, IMS, and MQSeries as an alternative to PSLC (Parallel Sysplex License Charge) in single machine installations (see Computer Finance, June 1999). Our research revealed that users remain perplexed about usage-based pricing and have not adopted it widely. In most cases, it was viewed as an unpredictable quantity that could wreak havoc with budgeting.

Today, the web has forced software vendors and users to revisit the issue, because the idea of web deployment is to broaden the user-and usage-base. But how do you count activity on the web?

The number of hits can be deceptive because, for Internet applications, the unreliability of connections can easily skew the figures up or down. Schemes are being tested that are transaction-based; the difficulty here is that the definition of a transaction will be highly application-specific.

Business Benefits. In rare cases, client/server software vendors, such as i2, offered 'value' pricing, where, for a smaller upfront fee, customers cold license the software, while providing the software vendor a percentage of either the savings or the added revenues. We'll examine value pricing more closely in another report.

Functionality. One of the few constants in software licensing is, the more modules you use, the more you pay for. The emergence of enterprise portals, where the application becomes invisible, has challenged this notion, because a single query (e.g., inventory levels) of an enterprise could require the combined action of a number of modules (e.g., materials management, procurement, distribution, order management, etc.).

Competition. This has almost disappeared from the database market, where Informix and Sybase have retreated to becoming niche players. Microsoft has won the browser war and has further solidified its hold on the desktop, CA has swallowed Platinum, while BMC and CA have acquired several rivals in the systems management field. Not surprisingly, competition is strongest in less mature markets such as customer relationship management, were Oracle and Siebel are playing a grudge match. Conversely, as we noted previously, the ERP market has become more competitive because, even if there are fewer viable vendors, business has dropped.

ISV STRATEGIES

We sampled a variety of software vendors in varying markets and learned that the web impact of software licensing was far from uniform.

We spoke with enterprise application (e.g., ERP, supply chain management, CRM), database, business intelligence, and web commerce vendors.

Enterprise Application Vendor Strategies. Enterprise application vendors with established client/server bases are for the most part adding web options that are generally licensed a la carte.

Not surprisingly, the big ERP vendors, such as SAP (see sidebar later) and Oracle, which have announced web migration strategies, in the long run plan to have their web licenses replace the client/server versions. Oracle plans to have at least half of its sales conducted via the Oracle web store within three years.

The Internet is also driving one other change: ERP vendors for the first time will actually publish their prices. Oracle plans to do that soon with 11i, the long-delayed Internet version of its ERP suite (expected to ship in Q1 or Q2 next year), and we expect that SAP will do the same with MySAP.com.

Database Vendors. The trend is toward CPU pricing where user IDs aren't known. Examples include:

* Microsoft's new 'Internet Connector' option for SQL Server 7.0 costs $2999/processor, plus the cost of SQL Server, which can start as low as $1399 for Standard Edition, and $7999 for Enterprise Edition. (In many cases, these list prices may be discounted with volume Select Agreements.) The Internet connector option applies only where users are anonymous; Intranets (and extranet applications with known users IDs) require conventional CALS licenses. (Note: Internet Connector options are also available for Windows NT Server, Terminal Server Edition, and Site Server.)

* Oracle 8i relies on processor pricing that is based on 'power unit,' not CPU. Power units are based on the clock speed of the machine (1 MHz = 1 power unit). Prices for Oracle 8i Enterprise Edition are $200/power unit; for Standard Edition (for workgroups), $40/power unit. Note: According to Gartner Group, power unit pricing is, on average, about 30% higher than previous CPU rates. Furthermore, because Intel machines have higher MHz ratings than comparable RISC boxes, the result is a cost penalty for Intel units (see Table 2).

* IBM's DB2 UDB 6.1 Enterprise Edition (for UNIX and NT) costs $12,500/processor. (Note: IBM kept user pricing only for workgroup editions, where the user base is at most a dozen known users.) Unlike Oracle and Microsoft, IBM's pricing applies across the board, not only for Internet deployment.

Table 2. Oracle's RISC vs. Intel power unit pricing
(Source: Gartner Group).

	RISC	CISC
Manufacturer	HP	Intel
Processor	PA-RISC 8500	Pentium III Xeon
Clock Speed	440 MHz	550 MHz
Number of Processors	1	1
SPEC Int95 Benchmark	34	23.6
Fee based on Power Units	$105,600	$132,000 Note: According to the above data, Intel users pay 25% more for a system offering 30% less performance.

On-Line Trading Communities. For a growing number of application vendors, the web means more than simple HTML webtops, but full on-line trading communities. ERP vendors, such as Oracle and SAP, are looking to on-line trading as their primary post-Y2K recovery strategy. The goal: alongside software licenses, they would get an ongoing revenue stream from transactions conducted on their on-line sites.

However, many other players have had the same idea.

The roots of on-line trading communities can be viewed in business-to-business extranet applications such as Ariba ORMS and Extricity Alliance, which were initially hub and spoke systems, organized around a manufacturer and all of its suppliers. In the original hub and spoke model, the hub (manufacturer) would pay for the license, while the spokes only had to bear their own internal systems integration costs (they didn't have to buy licenses).

As on-line trading communities evolve in the future, notes Extricity marketing vice president David Cope, they are likely to adopt compound transaction (e.g., complete a specific process, such as a procurement and acknowledgement, that involves a string of transactions), line item, or commission models.

The Ariba system, ORMS, was a web-based procurement system that automated all the subprocesses (e.g., procurement approvals, availability inquiries, order placement, order confirmation, invoicing, decrement to general ledger). The Extricity system, Alliance, is used for trading partners to link their supply chain planning processes using the web (and can use Ariba ORMS as an embedded application).

Ariba and Extricity licensed their 'hub' customers based on differing criteria. Ariba ORMS license was based on the overall number of transactions completed during the year. Keep in mind that transaction is defined broadly as a process; therefore, a procurement 'transaction' would include a string of individual transactions to get the required purchase authorizations, availability inquiries, and delivery confirmations.

Extricity, on the other hand, licensed its system solely on the number of CPUs. Typical installations of the Extricity Alliance hub cost around $400,000 for about 10 trading partner conceptions. Extricity plans to introduce a subscription model designed to eliminate the high up front costs.

The hub sponsor model has been the prevalent model for private on-line trading communities, where a sponsoring company asks its suppliers to adopt its chosen technology, but doesn't burden them with license costs for software they haven't asked for. However, with public on-line trading communities, the costs are spread around.

For instance, Ariba is migrating it ORMS user base to the Ariba Network, a common, hosted on-line trading community. With Ariba Network, ORMS customers could migrate their application-and their supplier lists-to the Ariba Network host. Obviously, with such an aggregation, suppliers will have access to new customers, and vice versa. In those cases, Ariba would get a percentage of the transaction. Additionally, new Ariba customers who did not install ORMS would pay similar transaction fees.

i2's new RHYTHM Exchange Services will offer collaborative buying, selling, manufacturing, order fulfillment, and product design life cycle applications. Pricing will depend on the type of transaction. For instance, collaborative planning would still rely on user licensing because it is not as transaction-intensive as actual commerce (buying/selling), and because the end user population is fairly small and well-defined. Conversely, for the commerce transactions, i2 has yet to determine the licensing basis; possible options are transaction pricing, transaction sales commissions, and/or monthly subscription fees.

CRM. This sector has lagged in web deployment. For instance, Clarify's E Front Office has web-enabled its existing suite of sales, marketing, and service modules; it is not doing a wholesale web migration. Certain functions, such as call center-based help desks and customer self service, lend themselves to browser deployment. Conversely, road warrior applications without persistent network connections do not.

Not surprisingly, Clarify's licensing still reflects the client/server model, with a mix of server, concurrent, and named user pricing. For intranet deployment (e.g., to call centers), user-based licensing still applies. However, the vendor is still determining licensing strategy for customer self service-do you license by transactions or, if sales are conducted, a percentage of the proceeds?

Oracle has recently made noises about web-based CRM. So far, the only module offered through its Internet store is iStore, which includes web-based store management tools, priced (like 8i) at $200/power unit.

Business Intelligence. Cognos, whose BI applications have largely centered at workgroup level, offers a mix of client/server and web-enabled OLAP, reporting, and data visualization products. Its customer base is at the early stages of embracing the web for BI-and requiring more scalable capacity. Licensing continues to be a mix of server- and user-based pricing. (Since most installs still tend to be department or workgroup-based, Cognos has not yet instituted multi-processor pricing.) In cases where Windows and web clients are available, web client user licenses are generally slightly cheaper because HTML is not yet as versatile as Windows.

On the other hand, Microstrategy has embraced the web more energetically. It offers the web-enabled DSS Web client which offers a similar CPU-based license as its Windows counterpart, DSS Agent. Ironically, when DSS Web was first introduced, Microstrategy tried concurrent usage licensing. The problem, according to Adam Ruttenberg, vice president of contracts, was that deployments tended to go to extremes: either small 50-100 user pilots, or enterprise-scale implementations reaching thousands of concurrent users. Microstrategy has since introduced additional web and web-like products that are more like services than packaged software. They include:

* DSS Broadcaster, which provides alerts that are sent through pagers, fax machines, email, or cell phones. Named user licensing was applied here, since by definition, everyone who is sent an alert is registered with the system.

* InfoCenter: A new portal product, it provides access to reports and notifications when report contents change. Licensing is fairly rudimentary, based on concurrent application threading. However, the limits for the initial tier are so high (the company claims that 50,000 users could be supported) that the vast majority of users pay the same flat fee, if used for intranets. For Internet, where the user population could be extremely high, Microstrategy is willing to offer a risk sharing revenue percentage fee because the tool could be useful to web data aggregators.

* Telecaster: A new phone-based automatic alerting product which will initially be deployed with the company's Strategy.com portal (performing functions such as calling you when your stocks go above a certain price), the fee would be based on telecom costs (e.g., per minute from Microstrategy's automated call center).

* Strategy.com: Microstrategy's answer to push technology, it will consist of channels that will be far more granular than the PointCasts of the world used to be. Like most Internet portals, it is advertiser-supported; extra fees for ancillary services (e.g., Telecaster alerts) are charged to the end user.

NO SINGLE PRICING MODEL

The web has blurred the picture on software licensing, in large part because it dissolves the barrier between packaged software, news media, and retail commerce. In many cases, software vendors are using their core products to morph into mass merchants or new media. Ironically, while the web's scalability would on the surface force a backlash away from user-based pricing to mainframe-like processor models, the reality is far more complex. For instance, we saw a rising incidence of processor-based pricing, but with the exception of Oracle, processor power was not accounted for.

Other patterns included:

* First-generation intranet information sharing systems (e.g., employee phone directories, HR employee manuals) were generally licensed by the number of CPUs in the server.

* Intranet applications usually, but not always, relied on user-based licensing because they were essentially thin browser client versions of client/server systems, which served well-defined populations of end users. This was especially true of web-enabled versions of client/server applications. In some cases, CPU pricing was also applied.

* Extranets were a mixed bag; where user populations were well-defined, user-based pricing was still used; where user populations were more amorphous (e.g., the identities of business partners were known, but end user IDs were either not defined or not individually managed), anything from CPU to transaction pricing, subscription fees, and sales commissions were under consideration.

* On-Line Trading Communities fit either of two categories. For privately-maintained communities, the hub (customer) pays for the software license. For externally-hosted extranets that are more public, the fees are shared by supplier and customer, and may take the form of sales commissions, rather than software licenses.

* Internet applications were question marks. While databases often relied on CPU, concurrent user, or some form of transaction pricing, enterprise applications suppliers have not yet fashioned their strategies, for reasons primarily centering around the fact that most consumers would not likely directly use sophisticated back office systems such as R/3 when logging onto self-service websites. Early strategies (e.g., SAP's web self-service applications) have centered around transaction-based concurrent usage models.

Obviously, web licensing is still a work in progress, and we'll return to the topic periodically to see what emerges.

SAP's MySAP.com licensing

The rollout of MySAP.com dominated this year's SAPPHIRE (SAP user conference) event. More than just an HTML front end to its ERP site, MySAP.com includes a wide range of elements, ranging from:

* MySAP.com Workplace. An enterprise portal providing HTML access to all R/3 functions, based on the role that is defined for the end user (e.g., read/write access, functions, etc.). It's an HTML interface that is layered atop R/3 that is module-independent.
* MySAP.com Marketplace. A SAP-maintained industry-specific portal that will provide a variety of inter-enterprise e commerce services ranging from chat rooms to on-line trading communities
.* MySAP.com Business Scenarios. New business process solutions (e.g., e procurement) that, like the workplace portal, span multiple R/3 functional modules. This will include generic processes (e.g., treasury management) and vertical industry sector-specific processes.
* MySAP.com Application Hosting. A new service that allows prospective R/3 customers to test drive R/3 before buying it, by setting up a testbed on a site hosted by SAP. In the future, this will allow prospective customers to preconfigure R/3 before buying, and then transfer that configuration, either to their own servers or to an SAP-authorized ASP partner. (SAP itself does not plan to get into the ASP business.)Because MySAP.com is more than just an HTML thin client front end, web licensing is function-dependent. For instance, licensing for the Workplace will of necessity require different criteria than placing procurements through the on-line trading communities hosted via Marketplace.SAP's first stab at web licensing came with the rollout of web-based self-service applications in 1996. Licensing was based on concurrent connections since end users themselves were not always identifiable (and since a user could easily consume more than one connection); it ranged from $40,000 (for a handful of concurrent user sessions) to $800,000 for thousands of concurrent connections. According to Eric Rubino, SAP executive legal counsel, who manages licensing policy, there was little demand for this option, partially because the idea of web self-service was quite new at the time, and because most SAP users saw little benefit in web-enabling small portions of R/3.With MySAP.com, SAP overhauled its licensing. While SAP won't publish pricing until the end of the year, it has started to describe how web licensing will work.Client/server module licensing will remain the same. There are a couple of likely deployment scenarios. Initially, MySAP.com functionality is likely to be implemented by users atop their existing client/server installations; in these cases, costs for MySAP.com will be additive to existing client/server licenses. In the long run, if customers fully migrate from client/server to MySAP.com, the MySAP.com licensing would replace their current client/server licensing.The bottom line is that MySAP.com licensing will be simpler than client/server versions, because it replaces per module and transaction pricing with simplified role-based user pricing. For smaller customers (roughly below $200 million revenues), it will be one flat fee. For larger customers, it would be based on the following three role levels:
* Professionals: Users with access to many different R/3 applications, who have strategic management roles (e.g., creating, managing, and approving processes such as purchase orders).
* Managers: Users who can create, but not necessarily approve transactions. The license cost would be about half that of the "professional" level.
* Employees: Users who require access only to specific applications pertaining to their jobs, plus horizontal HR applications such as entering their time and attendance.Although SAP has not yet published MySAP.com pricing, it states that overall costs will be 'slightly' higher compared to client/.server licensing. Although difficult to make blanket comparisons between client/server and web pricing, for smaller companies (where there's only one user role), MySAP.com is economical only if most of the workforce uses it.Note: There will be a few vertical industry exceptions for MySAP.com, in sectors (e.g., utilities) where user-based pricing has never been accepted.For external applications, where user IDs cannot easily be tracked, different licensing models come into play. For instance, Marketplace will include a grab bag of functions, some of which will be free (e.g., chat rooms), while others may involve transaction charges or sales commissions that are either charged to the vendor or customer. (Vendors signing up for the marketplace will likely pay an enrollment fee, based on their new ability to reach new customers.) In effect, this changes SAP's role from a software to a commerce provider (SAP is hardly unique in taking this approach).As for application hosting, the testbed portion of MySAP.com will be a free service to prospective customers. Once customers have bought the software, they would buy the traditional perpetual license (client/server and/or MySAP.com-based licenses, depending on what they implement). At this point, SAP does not currently plan to offer R/3 on a rental or subscription process to customers using an ASP.