5.1 Value Chains

There are two value chains in software, in which participants in one chain add value sequentially to the others. The supply value chain applies to the execution phase, starts with the software vendor, and ends by providing valuable functionality and capability to the user. The requirements value chain applies to the software implementation phase, starts with business and application ideas, gathers and adds functional and performance objectives from users, and finally ends with a detailed set of requirements for implementation. Many innovations start with software developers, who can better appreciate the technical possibilities but nevertheless require end-user involvement for their validation and refinement (see section 4.2).

The interrelation of these chains is shown in figure 5.1, where infrastructure and application software are separated into distinct supply chains. The requirements chain starts with analysis of user needs and requirements, and design of the concrete approaches for realizing those needs and requirements, the results of which define the detailed requirements for implementation of application software. The needs and requirements of application developers similarly must be analyzed to define the requirements for the implementation of infrastructure software. For most application software and virtually all infrastructure software, the analysis takes into account the needs of many users or developers, not a single user or organization. At the other end of the supply chain, the use of the application software is supported by the operation stage, where everything required to keep the software running and give users appropriate access to it is performed. Similarly, the operation of the application is supported by the operation of the infrastructure, which includes both infrastructure software and equipment (like networks and processors). Between implementation and operation is provisioning, which includes all steps necessary to plan, install, and test the software and required infrastructure to prepare it for operation.

click to expand
Figure 5.1: Value chains in the software industry.

The requirements chain was discussed at some length in section 4.2, so here we focus on the supply chain. The supply chain has four primary stages (see table 5.1): implementation, provisioning, operation, and use. There are, of course, other standard business functions like sales, not specifically discussed here.

Table 5.1: Stages of the Software Supply Value Chain and Their Generic Tasks
Stage	Planning	Deployment	Facilitation	Maintenance	Evolution

Implementation	Architecture; performance and scalability objectives	Build systems	Software tools support	Repair defects, performance tuning	Service and upgrade releases
Provisioning	Organizational design; performance and scalability requirements	Installation, integration, configuration, and testing	Procurement, finance		Installation, integration, configuration, and testing
Operation	Adjustment to changing security threats	Facilities growth to accommodate increasing throughput	System administration	Patching, configuration to counter security threats
Use	End-user organization	Organizational adjustments, user training	Help and trouble desk	Reorganization and user retraining
Note: The table cells are examples not meant to be comprehensive.

The implementation stage includes detailed requirements, architecture, and programming, as described in chapter 4. In addition, it includes testing of the software in a laboratory environment and with actual end-users. An outcome is a working software product that can be sold, distributed, and used. Responsibility does not end there, however. All software that is still used requires ongoing maintenance and in most cases upgrades and extensions over time.

In the provisioning stage, the facilities (network, servers, desktop computers) are procured and deployed, depending in large part on the unique performance requirements of the organization, and the software is installed, integrated, and tested in this environment. Frequently, an important role is the integration (installation and testing) of software from different suppliers. An outcome is an application that is ready for use. But provisioning is not just about software and technology. The organizational and business process changes necessary to accommodate the application in the organizational context must also be planned and implemented, including training of workers. Neither does provisioning end when the application becomes operational. System throughput and growth needs must be forecast, and facilities and accompanying software installations must be added to maintain performance attributes in spite of (for example) a growing user population.

In the operation stage, an application and its supporting infrastructure are kept running reliably and securely. In addition, users are supported, and problems arising from defects or changing needs are reported back to suppliers. Note that the operation and the use of a software application and supporting infrastructure are separate roles, usually involving different people. Many of us are accustomed to combining these roles in our everyday experience with desktop computers, but outside this environment, there are invariably operators (often not also users) taking responsibility.

At the use stage, the application functionality provides direct value to users and end-user organizations (see chapter 3). Just as the implementation stage overlaps provisioning and operation in time, provisioning overlaps operation, and operation overlaps use.

This summary of supply chain stages should make clear that there are many roles and management issues. Organizations taking responsibility for their own provisioning and operation as well as development require a range of skills. This can be problematic for small organizations, and as a result the outsourcing of provisioning or operation is common (see chapter 6).

The stages in the supply and requirements value chains are now discussed in greater detail.

5.1.1 Analysis and Design

Analysis and design are closely linked phases of the software chain. Analysis decides what is to be accomplished in the software context and how, and design takes the results of analysis as a starting point and turns them into a concrete plan and organization for the software.

Analysis starts with a conceptualization of what is to be accomplished, and considers in depth the features and capabilities of the software as they relate to the context of its uses. It is important to involve representative users through focus groups or interviews. For organizational or e-commerce applications, significant issues of business processes and organizational structures assumed by the application must also be addressed. In the spirit of modularity, the analysis and design phases interface through specifications and requirements (typically formalized as documents), which provide specific and detailed guidance to designers as to what the software is to ultimately accomplish. Requirements include capabilities and functionality, as well as the many characteristics listed in section 3.2, such as performance, reliability, security, and privacy.

The design phase seeks a concrete and detailed plan that can be followed through implementation. Elements of the design phase include determining aesthetic and human use characteristics (such as the user interface, including interaction, industrial, and graphics design; see section 4.2.6) as well as the internal details of the software itself (software design).

Analysis and implementation are not actually sequential (see section 4.2), but are ideally integrated through the development process (like iterative development). From a managerial perspective, it is useful to separate them in the value chain, as we have done in figure 5.1, because the core skills and orientation of the two activities are quite different, and it is increasingly common for them to be separated organizationally (at least in part). For example, the analysis may be assigned to a product marketing organization distinct from the software development organization, or employ outside industry consultants (see chapter 6). Of course, even separate organizations must maintain an ongoing and close collaboration.

5.1.2 Implementation

The creation of software was discussed at some length in chapter 4. Software design is often considered a part of implementation and includes the definition of architecture and a plan and requirements for individual modules. Thus, software design realizes a recursive application of the analysis design process, often at different granularities of architectural decomposition and over time (as in the spiral model). At each stage of analysis, design, and implementation, organizational issues and budgets must be worked out and approved. The processes discussed in chapter 4 ideally lead to software that meets its requirements with acceptable performance and with an acceptable level of defects within the user environment.

Before implementation is complete, the software must be extensively tested. This testing occurs at all phases—on individual modules, during the integration of modules, and in simulated and real user environments. Normally the developer solicits the assistance of cooperative end-users to try out the software during the later phases of testing. The first operational test, called an alpha trial, is the first trial in a real operational environment, usually at a limited number of customer sites. Depending on circumstances, these alpha sites may receive compensation in various forms, such as influence on the product features, free support, or outright payments. A later operational test, the beta trial, occurs at multiple customer sites. In some cases, anybody may download and try a beta version free, with structured feedback mechanisms. Depending on the company and its processes, additional test versions may be tried in the market before the software is finalized for sale. For custom software, there are factory acceptance tests (FAT, typically most demanding with customer representatives present) and site acceptance tests (SAT) to check the system in its operational environment. These testing vehicles are all included in the normal development investment.

The responsibilities of a development organization continue throughout the software's life cycle, that is, as long as the software is used and supported. The next stages of the value chain, provisioning and operation, require customer support from the software supplier. The supplier must assist in the configuration, installation, and testing of the software in the end-user environment, respond to inquiries, and assist in overcoming problems that arise in the operational phase. As part of this, the software supplier has an ongoing maintenance role, a function closely tied to customer support and feedback.

A software release is a collection of software code that is ready for deployment and installation on customers' hosts. A release follows a cycle of development and testing, and requires a number of coordinated actions, such as training of customer support personnel, priming appropriate distribution channels, and (in some cases) a marketing campaign. There are distinct types of releases, depending on the reasons for releasing the new code to customers, which illustrate logistical and business issues software suppliers face (see table 5.2).

The term version is used somewhat differently in software engineering and economics. In the parlance of economics, different versions are offered for sale simultaneously, offering different cost/capability points for a buyer to choose (see chapter 9). In software, only a single version is offered for sale at any time (although older versions may continue to be supported). Thus, a variant in table 5.2 is called a version in economics. The software industry commonly uses a numbering scheme of the form Version x.y.z, where x.y. identifies the version (major and minor revision) and z the service release.^[1] Patches may be identified by more complicated numbering extensions.

Table 5.2: Generic Types of Software Releases
Type	Description	Purpose

Patch	Replacement code that repairs a defect or shortcoming, usually in a small portion of the deployed code.	The supplier wants to correct defects that may affect the stability or security of the software as quickly as practical.
Service	A cohesive, synchronized release of a whole collection of patches, many of which were never made available separately.	The supplier not only wants to correct defects but also to ensure that all customers have deployed the same set of patches, simplifying customer service. This is also an opportunity to deploy patches that interact with one another. Often, patches require prior installation of the most recent service release.
Version	A replacement of all or most of the code embodying new features and capabilities or removing or modifying undesirable characteristics of the previous version.	The latest version release (incorporating also the most recent service release) is sold to new customers. Charging existing customers for a new version release (usually voluntarily and at a price discounted relative to new sales) as well as new sales provides a revenue stream to pay for the ongoing development cost of keeping the software competitive.
Variant	A variation on the same software differing in features or capabilities that is offered to the customer as an alternative.	Offering variant releases that differ in features or capabilities is one basis for price discrimination, allowing customers to self-select the price they are willing to pay. Thus, all variants are offered for sale at the same time.

Release types differ in terms of some important characteristics (see table 5.3). As defects in the software are reported during both provisioning and operation, repairs are undertaken and revised code is distributed to all the operators in subsequent service releases. These support and service functions are a cost to the supplier, which may be recovered through explicit support and maintenance contracts, or considered a normal cost of business recovered in licensing the software. These functions may be motivated by the desire for general customer satisfaction and repeat business, or laid out in specific warranty terms and conditions, or both.

Table 5.3: Characteristics Ascribed to Different Types of Releases
Characteristic	Possibilities	Considerations

Coverage	A release may replace a single module (typical of a patch), many or most modules (typical of a version), or everything.	Replacing more modules is an opportunity to make changes that affect the interaction among modules but also increases development and testing.
Frequency	Typically patches are made available daily or weekly, service releases every few months, and versions every couple of years.	The primary consideration in patches is making crucial changes, for example, correcting a security flaw that may be exploited by crackers. Other releases involve considerable development effort and testing and thus take time. Operators are encouraged to install patches and service releases as soon as they are available, whereas installation of a version release is optional.
Architecture	A release may change the modularity or simply replace existing modules.	A change in modularity has widespread consequences, so is typically undertaken only in a major version release and only for compelling reasons (for example, major new features).
Features	A release may add new features and capabilities, simply correct defects, or make existing features work more smoothly.	Changes from a user perspective are generally avoided in patches and service releases because user training and experience is disrupted and there is no revenue to compensate for development costs. Version releases are sold primarily on the basis of user value derived from new features and capabilities or improvements to existing ones.
Installation	A release may involve an upgrade or overlay (replacing portions of the installed code), or it may be clean (removing the existing installation and starting from scratch).	Patches and service releases do not replace all the code and thus are installed as an overlay. This removes a source of piracy (because the release is not self-contained) and reduces download and installation time. A clean installation ensures that possible corruption in an existing installation will not propagate to the new installation, and is often employed for version releases. Existing user configuration options can still be preserved if they are kept separate.
Coexistence	Different releases may or may not coexist in customer installations.	The coexistence of different releases complicates customer support. To minimize this, the first step in problem solving is typically to install the latest service release and all subsequent patches. The supplier may terminate support of older versions, reducing costs and providing incentives to customers to adopt the latest version. Variants are explicitly designed to coexist in different customer installations, and the resulting support costs must be balanced against added revenue.

As discussed in section 3.2.2, a typical application serves users with differing and changing requirements, so new versions to match changing requirements are necessary as long as there is a viable user base. Although software does not wear out like material goods, without upgrade it does inevitably deteriorate over time in the sense that changing user requirements and changes to complementary products render it less suitable. A new version entails some risks: it may prompt discontinued support for older data representations (alienating some customers), or suddenly fail to interoperate with complementary software or require new training. Operators are cautious where these are possibilities, and for this reason they are normally granted discretion as to whether or when to adopt a new version, which necessitates continuing customer support for at least one older version. In some business models for selling software, a primary source of ongoing revenue to support a development organization is from the sale of maintenance contracts or of new versions to existing customers. These business relationships and pricing issues are discussed further in chapters 6 and 9.

An important issue for software suppliers is how long to officially support older versions no longer being sold. Since adopting a new version is optional for the customer (without specific contractual terms to the contrary), different customers may operate and use different versions at the same time. The unseemliness of abandoning support and maintenance of older versions has to be balanced against the added maintenance and support costs. Suppliers have various ways to encourage customers to move to (and pay for) the latest version, including terminating support and maintenance of older versions (perhaps a couple of generations older). Another incentive to upgrade is maintaining compatibility with complementary software assets or compatibility across user communities.

Example When users who are making independent version decisions need to share files, or interoperate with the same application or other users across the network, or compose the software with other software (e.g., the composition of application with infrastructure), the issue of incompatible versions arises. Software suppliers usually attempt to maintain some level of compatibility across different versions, often with some loss of functionality (e.g., features in the newest version) and some loss of usability (e.g., forcing users to perform explicit conversions). Eventually abandoning this interversion compatibility can help to straighten out functionality and usability and is another way that suppliers can provide incentives for users to upgrade. Shapiro and Varian (1999b) discuss strategies surrounding this at some length.

5.1.3 Provisioning

Before software can be used, a number of steps must be taken to acquire the necessary infrastructure equipment and software, and install, integrate, and test it. The value added at the provisioning stage includes capabilities arising from emergence in integration (see section 4.3.5), the expectation that the application will meet performance, availability, and security goals during operation, and that the application can be smoothly administered.

The first step in provisioning is planning and designing the facilities and the software configuration. At this step, both the characteristics of the equipment and software and the end-user needs must be taken into account. In planning, several issues must be addressed in depth:

Performance. What use patterns are expected? The ultimate performance depends on both the software itself and on the configuration and sizing of the processing, storage, and communication facilities. Performance must be addressed at both the development and provisioning stages. Developers focus on ensuring a range of performance through the appropriate sizing of facilities (scalability). At the provisioning stage, the focus is on minimizing the facilities and costs needed to meet end-user requirements within the range anticipated by the developers. A maximum credible user and usage base must be established, and a plan must be in place to incrementally add facilities as use increases.
Availability. Objectives must be established for the availability of the application, which means the fraction of time it is operational and ready to be used. Nonoperational time, often called downtime, can be due to software defects or equipment failure, or to administrative procedures that require bringing the application to a halt (like maintenance or installation of patches or upgrades). Detailed characteristics of downtime, such as when it occurs, its frequency, and its duration, are important. Like performance, availability must be addressed at both the creation and provisioning stages. Tighter availability requirements require more extreme planning and measures like redundant equipment and software.
Administration. The provisioning stage is the time to put an operational administration plan in place. The goal is to minimize administrative burdens and costs while achieving adequate availability and support for end-users. Processes need to be defined, personnel and job requirements established, and personnel hired or reassigned.
Security. Potential security threats must be identified and characterized insofar as possible (see section 5.3.1). Procedures, processes, and policies must be designed for preventing or dealing with these threats as they become reality. The types of operational vigilance necessary to identify unanticipated threats also have to be established, as do plans for dealing with these in a timely fashion.
Privacy. Privacy policies for an application must be designed, and procedures and processes planned for enforcement of those policies (see section 5.3.2).

All these elements must be addressed in both development and provisioning. Typically, developers try to anticipate general end-user needs while allowing flexibility to meet the specific needs of a particular user in the provisioning phase. Thus, developers emphasize meeting the range of needs across different user groups, whereas provisioners focus on the needs of a specific user group. The developers want to provide sufficient configurability so that the provisioners can adjust to specific requirements while minimizing capital and recurring costs. In provisioning, concrete decisions must be made, usually involving trade-offs between cost and performance, availability, and support, and between security and usability, and so forth.

Provisioners must make concrete decisions on equipment, software vendors, and versioning options. Often the marketplace offers opportunities to mix and match different vendors and options. Considerations include not only the features, performance, and cost of the options but also their composability. The latter is a particularly difficult issue that rests on the credibility of suppliers' representations and evaluation of their support services and on the willingness of different suppliers to work together to resolve interoperability problems that arise. The greatest comfort is achieved when concrete demonstrations of composability can be identified, either in the laboratory or (most credibly) in similar customer environments. Typically, suppliers identify existing or previous satisfied customers as references that can be contacted and questioned as to their experience and outcomes.

Once planning is complete, the necessary equipment and software must be procured, installed, integrated, and tested. The integration of equipment and software procured from different vendors is the most difficult phase, not too different from module integration in development that sometimes requires maintenance actions on the part of suppliers as problems arise. The installation and testing of the resulting equipment and software usually have acceptance criteria based on functionality, performance, and composability criteria, and those criteria may be specified in procurement contracts.

Departmental and enterprise applications require coordinated redesign of organization and business processes to match the assumptions of application creators. Configuration options provide some flexibility but certainly never complete flexibility to address these issues independently. If an end-user organization is dogmatic about how it wants to organize itself, it may have to develop all or part of the application itself in accordance with local requirements. There are two schools of thought on this. One says that acquiring an application and its associated business processes is a way to spread best practice and avoid the time and expense of designing processes from scratch. The other says that internal development minimizes the disruption of process and organizational changes, and that customization allows differentiation and competitive advantage. The best answer depends on the objectives and constraints of the specific context.

Detailed transition planning is also required. How will the transition from the old processes and organization to the new processes and organization be managed? When and how will users be trained to use the new application? If problems or flaws arise, how will the organization retrench to the old system, or what backup procedures are in place?

It is common for an end-user firm to engage the services of outside firms—consultants and system integrators—in the procurement stage (see chapter 6). Consultants bring direct experience with the configuration and process issues for similar applications in other end-user organizations, and system integrators bring knowledge of equipment and software options, experience in integration (which has some commonality with development), and an ongoing working relationship with suppliers.

The provisioning stage does not end when an application becomes operational. As use grows or use patterns change, commensurate reconfiguration, and equipment and software upgrades, must be planned and executed. This phase of provisioning overlapping operations is called systems management.

5.1.4 Operation

The daily operation of most software systems requires human attention. For example, with organizational and personnel changes, authorization levels need to be adjusted. Security is another issue that requires vigilant attention: security breaches must be identified, and patches fixing security holes or flaws must be installed. Together, these functions are called system administration. System administration and systems management together strongly influence how well an application meets user and organizational needs.

One major administrative responsibility is the installation of new software releases (see table 5.2): Who must install them and ensure compatibility with complementary software and user training? To ease the burden somewhat, the installation of releases is increasingly automated.

In the operation phase, user support (commonly called a helpdesk) assists users with difficulties they may encounter and sometimes identifies defects in the software or its configuration, which are reported to system administrators and perhaps to software suppliers. The operational organization is thus typically split into two groups: one focused on end-users and one focused on the technology and suppliers. The skills and orientations of these groups are distinct, mirroring a similar division in software development (see section 4.2).

^[1]The version is split into major version x and minor version y, with the informal intention that minor versions are largely backward-compatible, whereas major versions require adjustment when deployed to replace an older major version.