The end of the Independent Software Vendor
From enterprise software to mobile devices, rarely, if ever, does one company deliver the whole product.
The evolution of computing, and specifically software, as an industry can be seen as having moved through three major phases: first, a period dominated by industry giants like IBM, Honeywell and Burroughs, providing fully-integrated products to fully captive customers; second, the personal computer revolution of the 1980s, a time when discreet layers, or stacks, of hardware and software emerged, available from different vendors, yet tightly coupled to create end products; and third and presently, the emergence of technology ecosystems, like those of Apple, LAMP or Microsoft—entire communities and constellations from which customers acquire solutions, in part or in whole, locally or in the cloud.
Past to present
Now, from enterprise software to software powering mobile devices, rarely, if ever, does one company deliver the whole product. Doing so has become a glaring sign of a monolithic, outmoded company. As a result, the long-standing industry term Independent Software Vendor (ISV) has become an oxymoron.
The venerable Association of Computing Machinery (ACM) offers the following as the objective of their upcoming Third International Workshop on Software Ecosystems:
Software vendors no longer function as independent units, where all customers are end-users, where there are no suppliers, and where all software is built in-house. Instead, software vendors have become networked, i.e., software vendors are depending on (communities of) service and software component suppliers, value-added-resellers, and pro-active customers who build and share customizations. Software vendors now have to consider their strategic role in the software ecosystem to survive…
Missed opportunity and competitive threats
As well as this may be understood, traditional software vendors often do too little to make the ecosystems in which they compete work to their advantage. While they wouldn’t dream of building their own operating system, they fail to scrutinize finer-grain decisions, such as an analytics or cloud backup capability. They haven’t internalized the question of ‘build, buy or ally?’ at the level of company and product strategy. This is a strategic error.
There are many reasons ISVs avoid the question altogether, from a “not invented here” culture that resists outside technology, to simply lacking a process by which to answer it. If you’re among them, rest assured your best competitors aren’t making the same mistake. They know it’s a question that must be answered and the importance of getting the answer right. Moreover, the current generation of SaaS application providers are software ecosystem natives. They build on and build their own platforms and APIs like breathing air. It’s their natural habitat.
The upshot
The benefits of full participation in an ecosystem are numerous, from reducing (and sometimes eliminating) the cost of development, to externalizing the risk of building a specific capability, to increasing speed of response to a rapidly evolving market. While these benefits are worthwhile in their own right, one of the most pronounced is the opportunity to capitalize on ecosystem partners’ marketing, sales and distribution resources; namely, their channels, money and people. From the multi-thousand person global field sales teams and multi-hundred million dollar marketing budgets of Microsoft and Oracle, to Apple’s ground-breaking App Store, aligning your success with your platform partners—where it makes strategic sense—can act as a massive force multiplier.
Having a clear ecosystem strategy also accelerates opportunities for partnerships with others built on the same platforms. Whether you’ve developed an application on Microsoft Sharepoint or a service in the Force.com cloud, having a well-defined set of product integration points and go-to-market programs makes for ready and effective alignment with potential partners who’ve done the same.
Making the shift
Of course, ecosystems are no panacea. As a new or established software vendor, deciding when and what to build versus where to partner is a measured process with significant ramifications for how you market, sell and deliver to existing and new customers. Establishing a decision-making framework is the first step. The following form a sound starting point:
Functionality—is it a core competency? Do customers expect you to deliver it?
Market-sizing—is a leadership position possible, and is the addressable market large enough to sustain you?
Time-to-market—is time-to-market important, and if so, can you achieve it on your own?
Resources—do you have the skill sets, time and budget to develop the functionality internally?
Addressing these questions fully and with real consensus, across product lines and feature sets, is the start of finding your place within a software ecosystem. We’ll look at a series of next steps in future posts.
