It turns out that I'm just the right age to have witnessed the rise, and perhaps the fall, of a software industry segment known as "Enterprise Software".
Enterprise Software, as a term, came to mean the notion of a business which created software which was, in turn, sold to other businesses which used that software for their own purposes: to design and build their own products; to manage their books; to control their inventory; to track their customers; to streamline their internal processes.
Back in the late 1960's and early 1970's, software existed, but it wasn't thought of as a "product", as something you could "sell".
Rather, if you bought a computer (that is, bought a computer from IBM, but perhaps possibly instead from Sperry or Burroughs or Honeywell or Control Data), you bought the hardware -- the actual computer that is -- and the software was generally considered to be thrown in, as an accessory or a sweetener to the deal.
The history of the computer industry is short, as histories go; even if, as this entertaining article on storage media notes, we can trace computing hardware ideas back for a hundred years, it's really amazing how short the history of computing is, and yet how much it covers.
I was thinking about this history recently, as I found myself (re-)reading an interesting paper from the Computer History Museum: RDBMS Workshop: Ingres and Sybase.
Obviously, the topic of the workshop was of great interest to me, having worked at both companies during the time period(s) in question, as well as because my manager of some two decades (Greg Batti) was one of the primary participants in the workshop.
It's interesting to remember what things were like, back in those days:
Butterworth: Well, that was kind of the beginning and, yes, we got the first products out so that was early in 1981. And at that point all the parts kind of worked. It wasn’t the world’s most robust software but it definitely got the job done. From that point forward, the big issue was trying to gear up the sales effort and gear up the technical effort to mature the product.
Recently, William Janeway wrote a wonderful article about the years when Enterpise Software came to prominence, and I found it fascinating reading: Enterprise Software: Death and Transfiguration.
Janeway notes that this relationship between hardware and software as commercial "products" changed due to the U.S. Government's anti-trust activity with IBM:
IBM had come under anti-trust assault from the U.S. Department of Justice and, in 1969, its response was to unbundle software from its hardware leasing contracts, thereby opening up commercial space for an independent software industry.
Out of this basic alteration of the way the world viewed hardware and software, there quickly arose a brand-new industry:
Venture capital was needed for the initial cost of developing the software, including the cost of buying development hardware and software, but once there was a "minimal viable product" (to use a modern term) to sell, license payments funded the build out of the sales, marketing and customer support functions essential to turning a venture into a sustainable business. Moreover, the enterprise software industry was the first product-centric business not to require the "manufacturer" to hold inventory: losses on the revaluation of inventory were eliminated by construction and working capital needs were limited to financing receivables.
It was a time of great change, and of great progress in the creation of huge new corporations based on this notion of a software industry: Ingres and Sybase, of course, but also Microsoft, and Oracle, and many others whose names are just foggy memories nowadays.
Janeway's story, though, does not end there, but rather moves on to the next great event:
Software as a Service ("SaaS") transformed the customer’s purchase decision from a capital investment to a recurring operating expense. A product sale now generated cash flow to be collected in the future, whether based on a simple calculation of number of users licensed per period or transactions executed or some other metric of value realized over time versus anticipated value paid for upfront.
It is, of course, a great difference to transform an entire industry from "pay me now" to "pay me later" (or "pay me as you go", if you prefer), but just as important is how that change (from perpetual licensing to service subscription) change the way that companies are built and operated, nowadays:
The enterprise "customer" is now fragmented into multiple customers: the disparate business units where the need and budget are to be found...but not the technical capacity to deploy or manage complex code.
And, as Janeway goes on to highlight, this change in the "enterprise customer" has caused a corresponding transformation of the enterprise software sales process:
The disappearance of the internal enterprise IT Department as the customer for software means, in the first instance, that attempting to sell a new general purpose "platform" to the enterprise -- emulating the enormous success of Oracle in database or BEA in app server -- is quixotic. There is nobody home when the salesman calls. Instead, the technology must be fashioned into a "solution" relevant for and appealing to the distinct business unit customer. Now the problem is that there are too many homes on whose doors to knock.
For a near-perfect example of this transformation, you could do no better than to look at last year's hottest software IPO: Atlassian. Atlassian have just finished their first full year as a public company; you can read their Shareholder Letter here, although more relevant for this discussion is the minutiae in the Atlassian annual report, where we read things like:
We offer and sell our products via both the cloud and on premises using the customer’s own infrastructure. Our cloud offering enables quick setup and subscription pricing, while our on-premises offering permits more customization, a perpetual or term license fee structure and complete application control. Historically, our products were developed in the context of the on-premises offering, and we have less operating experience offering and selling our products via our cloud offering.
our software is frequently purchased by first-time customers to solve specific problems and not as part of a strategic technology purchasing decision.
We do not have a direct salesforce and our sales model does not include traditional, quota-carrying sales personnel. Although we believe our business model can continue to scale without a large enterprise salesforce, our viral marketing model may not continue to be as successful as we anticipate and the absence of a direct sales function may impede our future growth. As we continue to scale our business, a sales infrastructure could assist in reaching larger enterprise customers and growing our revenue. Identifying and recruiting qualified sales personnel and training them would require significant time, expense and attention and would significantly impact our business model. In addition, adding sales personnel would considerably change our cost structure and results of operations, and we may have to reduce other expenses, such as our research and development expenses, in order to accommodate a corresponding increase in marketing and sales expenses and maintain our profitability. If our lack of a direct salesforce limits us from reaching larger enterprise customers and growing our revenue and we are unable to hire, develop and retain talented sales personnel in the future, our revenue growth and results of operations may be harmed.
Predictions are hard, especially about the future.
But yes, Mr. Janeway, the evidence from the Atlassian Annual Report (and from many, many, many other sources) is crystal-clear: the times, they are a'changing.
And so we must all change with them.