Virtually every modern organization uses software to some extent. Small business and non-profits may just use a bookkeeping or member-tracking software package, supplemented with an office suite and perhaps some cloud-based documents and services like Google Docs and DropBox. A large enterprise will likely have millions of dollars of installed software, including ERP systems, databases, desktop applications and customized intranet applications, to name a few.
How should organizations think about acquiring, owning and maintaining software? One view is a capital-asset model. In this model, software is like factory equipment. A piece of equipment is purchased, and goes on the balance sheet as an asset. It’s depreciated over time. The purchase may also be accompanied by a maintenance agreement of some kind (which, from an accounting perspective, would be treated as an expense).
The capital-asset model is well-entrenched, especially in large organizations. Most procurement and budgeting approaches still revolve around this model. These approaches then influence approaches to planning and strategy.
The persistence of the capital-asset model makes very good sense. Capital purchases are an essential part of large-organization procurement, and the accounting and purchasing strategies for such purchases are well-established and well-understood.
Is a capital-asset model the best fit for an organization’s software strategy?
In some cases, the answer is certainly yes. Traditional purchasing models assume that goods can be assigned a fixed price in advance of the purchase. This is certainly true for pencils, staplers, and typical capital goods such as vehicles, factory equipment and physical plant in general. It’s also true for shrink-wrap software such as office suite and productivity software. Determining the price of 1000 licenses of a word processing program is a straightforward negotiation, ending with a fixed price. Once the software is purchased, it’s used in the form in which it was purchased, slowly “losing value” over time until it’s replaced with a newer version, much like a truck or a bottling machine.
Not all software is shrink-wrapped, though. Some software is customized to the needs of an organization, often extensively. Some software, in fact, is customized to the point of being written entirely from scratch. Unlike purely shrink-wrap software, such software is modifiable, and is indeed frequently modified as business rules and practices changes. The pace and extent of this modification from vary, from infrequent modification and customization through a spectrum up to and including significant software modification on a daily or weekly basis.
Software that is built to order does not much resemble the kinds of fixed goods for which the capital-asset model is best used. Most custom software development involves some amount of up-front requirements gathering and design. In general, though, it’s widely acknowledged that such up-front design rarely captures 100% of the desired features and requirements. As a result, the software that is built generally differs to some degree from the software that was specified initially. It’s important to understand that this is not necessarily a flaw, or indicative of a lack of maturity in the software engineering industry; many types of software benefit from an incremental development approach, with the opportunity to change and refine the plan and scope along the way. This iterative approach to development is often termed “agile”, and has become widely accepted as an important and valuable approach to software delivery. The alternative approach, in which an effort is made to capture 100% of requirements and do 100% of system design before beginning to construct the software, is often called a “waterfall” approach. Though a waterfall approach is appropriate for high-criticality software such as life-critical or embedded systems, it’s unnecessarily constricting and expensive for much of modern organizational software.
Modern organizational software is less like a set of fixed, immutable machines with certain specific connections among them. It often consists of multiple, highly interrelated programs that can be accessed in multiple ways. Not infrequently, the boundaries between systems are fluid, and difficult to delineate precisely. Often the investment in maintaining and evolving a software system over its lifetime is many multiples of the system’s original cost of acquisition.
In all of these ways, modern software systems behave less like discrete, effectively unchanging machines, and more like an ecosystem with multiple, complex interrelationships. Such software is not purchased once and then depreciated. Rather, it is brought into being and then continually evolved, requiring a steady influx of thought and effort to keep the software systems in sync with the surrounding business. Rather than depreciating, i.e. losing value over time, many software systems increase in value over time, as the software undergoes additional evolution and refinement .
For these reasons, the acquire-maintain-depreciate model characteristic of a capital-asset model often doesn’t fit modern enterprise software systems very well. Modern software systems require ongoing investment to maintain and evolve, like an ecosystem that requires a constant influx of energy, and then transforms that energy into continued growth and evolution.
The “ecological” nature of custom software in organizations shouldn’t necessarily be seen as a flaw. Software is intimately and integrally bound up with business process. Not infrequently, the speed at which an organization can evolve its software represents an effective limit to the speed at which an organization can evolve its business processes. Organizations that can change their software rapidly will have a competitive edge over those that can only evolve their software more gradually.
From a procurement perspective, software development is arguably best thought of as an essential service, rather than as a product. A capital-asset model proceeds from the view that the features and price of a good can be completely fixed in advance. In software, this is rarely the case. A better-fitted model might be called a “capital-services” model. Investment in internal systems is certainly likely to be a capital expenditure in the strict accounting sense, in that it adds to the life and value of internal systems, and ideally provides value that lasts longer than a year. But since the best application of that investment often cannot be determined very far in advance, it seems wise for organizations to treat their custom software expenditures as a services budget. Set aside a budget for internal software development, and structure the development process to derive the maximum business value from that budget and abandon the attempt to specify (as much as a year) in advance exactly how that money will be spent.
That’s rlealy shrewd! Good to see the logic set out so well.