6.3 Business Relationships in the Software Value Chain

Whatever the decomposition of the software value chain, there are a number of business relationships among the participating firms. A discussion of some important issues follows.

6.3.1 Types of Customers

Today, virtually every organization and most individuals are customers of software suppliers. It is important to recognize that the primary customer is whoever does provisioning and operation, which may or may not be the same entity as the end-user. Customers come in five distinct categories. First, individuals license applications for their own purposes, such as personal productivity, collaboration, information access, and entertainment. Second, organizations acquire (license, purchase, or develop internally) applications that support their internal business and external business relationships.^[3] Third, service providers acquire software that they embed and bundle into services provided over the network. Fourth, equipment manufacturers embed and bundle software into equipment that they manufacture and sell. (The last two are similar in many ways.) Fifth, the "customer" of a piece of software can be another software application.

Example When one entity exports a service over the wide-area network, other software may be constructed to specifically invoke that service. An example is the meta-search engine (Ixquick and SurfWax are two of many), which consolidates the results of a query it presented to a number of other search engines on the Web. A more general example is the portal, a Web site that allows a user to customize her view into a number of other Web sites. One economic driver for meta-search engines and portals is to attract and retain the user's attention, deriving revenue from advertisers. Higher-quality portals and aggregation services require subscription revenue. These are instances of the general concept of Web services (see chapter 7), which emphasizes servers' making use of data and application logic services derived elsewhere.

The primary distinctions are in the related areas of customer sophistication, support, and value. Individuals normally install, administer, and use the software and may be relatively unsophisticated in technology, requiring more automation of installation and upgrade and a strong customer support operation. While the ultimate value of software is in what it does for users, a customer who is not the end-user may be more sensitive to the technical features, configuration options, and operational support and tools.

6.3.2 Software Distribution

There are several ways to get software to a customer. Software is normally distributed as object code represented by data and distributed on magnetic or optical media or downloaded over a network (see section 4.4). The object code may be native code for a target processor or intermediate code intended to be executed by an interpreter or just-in-time compiler.

The technical means of distribution has considerable influence on the business model for selling software. Physical media require traditional inventory, warehousing, and transportation, functions avoided by network distribution. Distribution is complicated by multiple platforms, although software portability may eliminate this while introducing execution overhead and dependence on an interpreter or virtual machine infrastructure.

A consideration in distribution is digital rights management to protect against further distribution without payment (see chapter 8). The security of physical media is greater, so it is common to distribute on a physical medium but allow upgrades (which depend on prior installation of the original) over the network. Network distribution is also impractical with slow Internet access rates (such as voiceband modems), so an optional physical medium is usually offered.

Network distribution is less expensive and timelier. These properties make it valuable for the frequent distribution of service releases and upgrade versions, giving more freedom to change with less fear of incompatibilities. Many modern applications check for a network connection, automatically notify the operator of service releases, and automate downloading and installation, reducing the total cost of ownership (see section 5.1.4). This capability should be contrasted with hardware, which can be updated after deployment only with difficulty.

Example With partitioning of application functionality between server and client (see section 4.5.3) the server can be upgraded more freely knowing that timely upgrade of clients can follow. For example, with RealAudio (an audio streaming application) the server capabilities can be upgraded with relative impunity (even in ways that make it incompatible with the client) knowing that the client can be easily and quickly upgraded. A similar example is Adobe Acrobat Reader (downloadable free) and the matching Acrobat Distiller authoring application. Version 5 added new encryption technology to Distiller knowing that Readers would have to be upgraded. Downloading is especially powerful for peer-to-peer architectures because network effects place a premium on rapid adoption. Arguably, peer-to-peer applications such as Napster and Groove Networks could not be successful without simple downloading and installation.

Although network distribution eliminates some intermediaries, intermediary functions remain useful where there are alternative suppliers to consider, or where integration and bundling of different products are needed.

Example Many organizations (especially universities) have a fragmented administrative structure for computers but also want site licenses for commonly used applications. They typically make the licensed applications available for network download and installation internally to the organization, using access control (see section 5.4.2) to enforce licensing terms and conditions.

What has to happen before a customer can execute software? There are at least four possibilities. First, the software may be embedded in a piece of equipment distributed through conventional material distribution channels.

Example Many common products such as microwave ovens and automobiles use embedded software to control the complex features and a user interface. For example, software allows the microwave oven to be programmed by the user, and controls the cooking time and microwave power level.

Such equipment, when sold to an end-user, is called an appliance. When predominately based on information technology (processing, storage, and communication), it is an information appliance.

Example The personal video recorder (vendors include Microsoft, ReplayTV, and TiVo) allows users to easily schedule the recording of television programs and play them back at their convenience. They download TV schedules over the network, and provide a user interface on the TV screen to program the information appliance using a remote control. Internally, the PVR includes custom hardware, a processor, operating system, database management system, and large disk drive for storing video.

A variation on embedded software relies on preinstalled software. This model is commonly used to make generic hardware, such as desktop computers or personal digital assistants (PDAs), ready to use "out of the box." Preinstalled software always includes an operating system and typically also a set of applications and even demos for products that could be ordered separately.

Second, the customer may have to install the software herself, which requires conspicuous action. This user self-provisioning is typical of desktop applications.

Third, mobile code may be automatically downloaded over the network and executed without an explicit installation (see section 4.4.3).

Example Many Web-based applications download ECMAScript or Java code to the Web browser for local execution. This code requires no installation, is deleted once the user finishes the application, and can provide much less delay for animations and interaction than server implementation, particularly for slow Internet access connections. Further, it can implement user interface features not intrinsic to the browser.

Fourth, the user may utilize software executing remotely, which is operated by an application service provider (see section 6.2.2). This is often combined with mobile code that realizes user presentation and interface functions in the client. From the user perspective, all these options differ primarily in terms of performance.

Example Mobile code may incur a noticeable delay while the code is downloaded, especially on slow connections. Remote execution suffers from round-trip network delay, precluding some capabilities like immediate rotation and redisplay of a manipulated complex graphical object, but it may offer more processing power. Local installation or mobile code offers scalability, as the processing resources grow in proportion to users.

For user-installed or mobile software, a traditional business model of production and marketing is appropriate. For embedded and service provider-operated software, the original equipment manufacturer or service provider acquires, provisions, and operates the software. Embedded software executes in a controlled and static environment, and hence operational support can be minimized or eliminated; where problems arise, they are handled through customer support. The key difference from the perspective of the supplier is one of scale and sophistication: Do the customers comprise a small number of technically sophisticated manufacturers or service providers, or a large number of relatively unsophisticated end-users? The decision process is also different. With a manufacturer or service provider or mobile code, a third party makes decisions to install an upgrade version or move to a competitive offering. With user self-provisioning, the user consciously initiates such actions, although the software itself may inform the user of the availability of service releases or an upgrade.

Mixtures of these distribution models are common. Appliances may fetch and automatically install upgrades from the network. An application service provider may use mobile code to move a portion of the execution closer to the end-user and improve interactivity. Mobile code may leverage desktop processing power, reducing server capacity and improving scalability, or a service provider may require complementary user-installed client software.

6.3.3 Software Pricing

There are many alternatives and issues in designing pricing models (see chapter 9). However, there are also standard practices observed in the industry today, often tied to a specific distribution model and recovering creation, maintenance, and upgrading costs. Software that is not maintained wears out fairly quickly (see section 3.2).

User-installed software is typically sold for a fixed price with unlimited use, as are many other information and material products. Upgrade versions are also offered at a fixed price, creating a revenue stream. This places a premium on selling upgrade versions to support ongoing maintenance and upgrading costs, although sales to new adopters also provide ongoing revenue. The biggest competition for upgrades is the installed base of older versions, unless customers are under contractual obligation to upgrade. To best this competition, suppliers offer new or enhanced features and often a favorable upgrade price. Some have asserted that this revenue model results in "feature bloat," with a negative effect on usability. Other strategies include upgrading complementary products in a way that encourages users to upgrade.

Example Suppliers of an operating system are pleased when applications exploit capabilities and features from the latest operating system version, and encourage this by offering advance technical information and assistance. Customers attracted by the latest application upgrade may want to upgrade the operating system.

Embedded and service provider distribution mechanisms place an intermediary in the supply chain, the supplier of an information appliance or a service provider. (In some cases, these entities may internally develop the software.) This requires two pricing strategies (software supplier to intermediary, and intermediary to end-user). From the supplier perspective, a common approach is to approximate the user-installed pricing model by basing price on the rate of end-user adoption (such as a fixed royalty per appliance sold or end-user served).^[4] Another option is direct usage metrics, such as the total number of transactions completed. A third approach is to base pricing on the number and speed of servers on which the software is installed rather than on usage or users.

An information appliance bundles the hardware with embedded software for an all-inclusive price. Since the customer (especially an individual consumer) has little awareness that the appliance includes substantial software, pricing models typical of material goods are common. A fixed price is common, with no possibility of later upgrade and an established warranty period during which product defects or failures will be repaired. Whatever pricing model is adopted, the embedded software is sold under the same terms and conditions.

Historically suppliers of appliances considered the embedded software a cost of implementation, necessary to sell the product, rather than a separate source of value and revenue. As the software content of appliances has increased, most suppliers have come to realize that the embedded software is a source of substantial development costs as well as value. The flexibility to replace software in the customer's hands is not only a maintenance opportunity but also an opportunity to derive additional revenue by adding features and capabilities. The business model sometimes unbundles embedded software from hardware to maximize revenue. The supplier may even create a platform and application programming interfaces (APIs) that allow other suppliers to add application software, enhancing the value of the appliance but forgoing some possible revenue.

Example Suppliers of telephone switches (such as Lucent, Nortel Networks, Erickson, and Siemens) traditionally bundled call-processing software. As software development costs grew, they sold and upgraded the software separately, realizing significant revenues from upgrades. However, this highlighted to the customers the lack of competitive suppliers for this embedded software; they were locked into a software supplier with their original equipment purchase. The suppliers were eventually prodded into open APIs, allowing other software vendors to add application feature packages (this was called the "intelligent network").

Increasingly, information appliance suppliers are adopting an unbundled software pricing model, although this cannot be considered conventional as yet.

Example TiVo developed a personal video recorder but, rather than manufacturing this equipment, licensed the design to consumer electronics manufacturers Philips and Sony. Each customer purchasing a TiVo must separately purchase an embedded software license. TiVo derives revenue from both equipment royalties and a subscription to periodic TV scheduling information and software upgrades. This gives TiVo more opportunities to offer pricing and service variants (see chapter 9). This pricing is an interesting hybrid between what is typical of material goods and software. Competitor ReplayTV adopted a bundle including both software upgrades and schedule information in the original appliance price.

Like embedded software, the application service provider model adds an intermediary between software supplier and user. The service provider pricing to its customer (the end-user) often uses models commonly found in traditional service (rather than product) industries, such as subscription, pay-per-use, and cross-subsidy. A subscription offers the service for capacity-limited or unlimited use over a contracted time period with recurring payments. Pay-per-use requires metering and billing on a per-use basis, requiring (depending on the approach taken) significant infrastructure. For example, to support irregular uses (similar to Web browsing) at a fine granularity, an effective micropayment system may accommodate very low prices with acceptably low transaction costs. Cross-subsidy recovers the cost by attaching a technically unrelated service, such as advertising, or bundling it with another paid service.

Software's unique characteristics lend themselves to innovative pricing mechanisms. One of these is self-awareness, the ability of an executing software module to monitor its own use and communicate with a payment service.

Example The superdistribution model (Cox 1996) encourages operators and users to further distribute software modules to others (with the permission and blessing of the software supplier). The supplier can enforce a software license with payments by including within the module the awareness that it is executing and the functionality to convey a payment for use, again assuming a payment infrastructure. The model is transitive in that a module incorporating or using a module from a third-party supplier causes an indirect payment to compensate that third party. Superdistribution can be viewed as bundling of viral marketing (Ward 2000) with distribution and sale.

Superdistribution illustrates one important characteristic of software. It is unique among goods in its flexibility to decouple pricing from the distribution model and from the industrial organization. The difference between selling software for user installation and operation and selling it as a service is the responsibility for provisioning and operation, not pricing, and all pricing options are technically feasible for both organizational models. An application service provider can offer a product-like pricing model, such as single upfront payment. It can even simultaneously offer variants of the software at different prices, and offer different versions with the option for a paid upgrade. Similarly, software distributed to a user for self-provisioning can be priced based on use, as in superdistribution. This is more cumbersome for material goods, where the customer takes physical possession and the supplier must gain physical access to a meter that monitors use (unless, of course, that material good has embedded software and network access). It is not feasible for information goods (unless accompanied by software), which lack the dynamic behavior necessary for monitoring and billing.^[5]

6.3.4 Acquiring Industry-Specific Applications

The business of selling generic and widely used software applications or infrastructure to a mass market is quite different from selling applications that meet specialized organizational needs. In the former, the large creation costs can be recovered through volume sales at moderate prices. In the latter, the price must be higher, commensurate with the smaller sales volume, and this will invoke considerable competitive evaluation and case-by-case negotiation by the customer. The customer will often consider internal development of the software, so the application software supplier competes directly with an internal information systems organization. These challenges are offset by the opportunity to substantially differentiate the application and derive significant revenue on the basis of unique and identifiable value to the user, assuming that pricing can be based in part on this value (see chapter 9).

An end-user organization acquiring software for specific internal purposes has several options: make, buy, license, and subscribe. Each has its advantages and disadvantages. In the make option, all four stages in the software value chain (creation through use) are kept in-house (see section 6.2.2). This offers the greatest potential to differentiate from competitors but also may foreclose or at least make difficult future interoperability with competitors (who may turn into partners through alliance, merger, or acquisition). It cannot spread the high development costs over multiple uses and has considerable risk of delay, budget overruns, or even failure. Budgeting must take into account not only creation costs but also ongoing maintenance and upgrade costs and their burden for years to come. These costs, too, will not be spread over multiple uses. Operational costs may be higher because of the reduced economies of scale and the inability to hire existing expertise. A "make" decision entails considerable opportunity costs, given the shortage of skilled software developers (see chapter 8); allocating development resources to one project denies resources to other projects.

The buy option is to outsource development to a firm specializing in contract software development. In this case, the source code will likely be owned by the end-user, and ongoing maintenance and upgrade may be the responsibility of developer or user. Like the make option, buying offers the opportunity to mold business processes, organizations, and software as a unit, gaining efficiency and competitive advantage but also incurring higher costs of development, maintenance, and operation. Negotiations (and associated transaction costs) with contracted software developers are often protracted and difficult because of the complexity of the issues involved. A developer will seek ownership or joint ownership of the software in order to be free to reuse modules in other projects or to use the code base as the starting point for future projects. The buyer will seek at least joint ownership so as to be free to take over future maintenance and upgrade and to avoid lock-in to the developer. If the buyer cedes ownership, the buyer will want a lower price in return or possibly royalties in return for use of the code in other projects. The buyer may seek to exclude direct competitors as future customers of the developer, preserving competitive advantage.

In the license option, an end-user licenses an off-the-shelf software product from a software supplier. Finally, in the subscription option, the application services are purchased directly from an application service provider. In practical terms, the subscription option offers less opportunity than the license option to deeply integrate the software with other applications in the organization (although Web services technology have a significant impact).

In choosing a software application and a supplier, many considerations come into play (see table 6.1). Usually applications are sold as a monolith, and the internal architecture is of little concern. External architecture assumptions, like which information formats are exported and which APIs are provided for extension or composition, are important considerations. Some acquirers value an internal architecture that includes open APIs because this enables internal or outsourced developers to add capability or more easily compose with other applications.

Table 6.1: Considerations in Choosing an Application and Its Supplier
Property	Description

Capability and functionality	What does the application do, and how well does that meet needs?
Quality, usability, performance	How well does the application do what it does?
Reengineering	What organizational or process changes, worker training, and so on, will be necessary?
Architecture	What interfaces are assumed to the infrastructure or to other applications? What APIs are provided, and what information formats are supported? How easy will it be to integrate the application into the end-user environment, and what flexibility is there for application composition in the future?
Customer service	How good are user and technical support and maintenance?
Road map	Can the supplier provide visibility into future plans for evolution of capabilities and functionality?
Viability	Is the supplier financially sound and will it be in business to support the application? Does the application itself have sufficient market acceptance and momentums so that future upgrades and support can be expected?

6.3.5 Acquiring Infrastructure

Acquiring a new application may also entail new infrastructure equipment and software to support that application. Usually the application supplier will specify a specific platform that is needed to run the application, but sometimes there is more than one option.

Example An application created for a Windows platform will usually not run on a UNIX platform, and there are several similar but not identical UNIX platforms, including HP-UX, IBM AIX, Sun Solaris, and Linux. A supplier of an application for one of these platforms may choose to port the applications to other UNIX platforms or not; this is a trade-off between development cost and market opportunity.

Where new infrastructure must be acquired to run an application, there are significant administrative costs in acquiring the expertise or training workers, adding acquisition or switching cost. This frequently makes infrastructure as a service more attractive than self-provisioning. Wide-area networking and communication in particular are often obtained from a service provider, because it is largely impractical for end-user organizations to provision wide-area communication links and because a public network offers rich connectivity. There are indications that infrastructure service offerings will grow in both features and popularity.

Example Caching improves the performance of information distribution by locating temporary information storage nearer to consumers of that information. Providers offering this service illustrate alternative business models. Inktomi targets Internet service providers, providing all their customers with enhanced information access. Akamai, in contrast, sells to information suppliers, offering them a global caching infrastructure that offers better performance to their customers.

Although infrastructure is rarely developed by an end-user organization, there are exceptions. One important role of infrastructure is to enable the composability of applications (see section 3.2.12).

Example Operating systems and their networking services offer standard mechanisms for applications to communicate, on the same or different host. One factor in the success of the Internet was allowing applications on different platforms to share data, although this is only the first step; it falls far short of composability (see section 4.3.6), which requires interoperability through application-level protocols and complementarity of function.

A need for custom infrastructure arises because many organizations find it impractical to replace legacy applications because of time, cost, and risk constraints, especially if they can be successfully composed with other applications. This issue arises in assembling enterprise applications by composing legacy departmental applications, and often requires significant development effort in creating a custom infrastructure. In this area, the boundary between application and infrastructure is hazy, as this infrastructure is actually an extension of the existing applications.

6.3.6 Accounting Issues

Investments in acquiring or developing software are substantially influenced by accounting standards and rules, which determine how investments affect income and the balance sheet. Financial and accounting practices for software have been a contentious issue for some time, again because of the distinctive nature of software. In particular, accountants have traditionally viewed software as an intangible asset, in contrast to, for example, tangible assets like a building, machinery, or equipment. Because tangible assets provide future ongoing returns, they can usually be capitalized, that is, their first cost is treated as an asset depreciated over time as their benefits accrue. One view of software development costs is simply as a labor expense, which flows directly to the income statement as that expense is incurred. The ability to capitalize software encourages greater investment in development, since the depreciation affects income over time rather than immediately. The argument (Munter 1999) in favor of capitalization is that software development is not essentially different from the development of tangible goods in that the benefits of the software do accrue over time as the software is operational, and indeed embedded software is integral to many tangible goods. The argument against capitalization is that software development is risky and that future benefits are difficult to estimate. Accounting standards have gradually relaxed the circumstances under which software development costs can be capitalized.

Example Recent U.S. accounting standards identify three stages in the acquisition of internal-use software:^[6] the preliminary project stage, the application development stage, and the postimplementation operational stage. Using our terminology, costs incurred during the preliminary project stage and the provisioning and operation phases (including preparing data, testing, training, maintenance, and administration) should be expensed. Costs associated with development of application software may be capitalized. Where software is acquired rather than developed, the amount paid should be apportioned over these same categories and treated similarly for accounting purposes.

Another issue is the rate of depreciation, which assumes a lifetime for the software. Contrary to clear evidence (see section 3.2.11), many view software as something that doesn't deteriorate and that has an indefinite lifetime. This view can lead to catastrophic management decisions that defer or seek to avoid investment into new software development, placing excessive reliance on large past investments. Assuming a realistic rate of deprecation brings software investments appropriately in line with investments in tangible goods with a finite lifetime and distinguishes software from both pure intellectual property and real property.

^[3]Software suppliers are themselves major customers for software. They may license modules to be incorporated into their own products, or they certainly purchase development tools (such as build systems or compilers). They also incorporate many standard business functions like sales and accounting that are supported by applications acquired from other firms.

^[4]If a software supplier targets original equipment manufacturers or service providers as exclusive customers, there is an opportunity to reduce development and support costs because the number of customers is smaller and the execution environment is much better controlled.

^[5]In the case of both material and information goods, suppliers have found ways to approximate use-based pricing without direct usage reporting. A common approach is to lease rather than sell, and base the rental charges on the time of possession. An automobile logs its distance traveled (today using software), and that log can be captured when the car is returned. Utility meters are often read by sending a worker to the physical premises.

^[6]This example is based on the American Institute of Certified Public Accountants Statement of Position (SOP) No. 98-1 (Luecke, Meeting, and Klingshirn 1999).