<$BlogRSDUrl$>
 
Cloud, Digital, SaaS, Enterprise 2.0, Enterprise Software, CIO, Social Media, Mobility, Trends, Markets, Thoughts, Technologies, Outsourcing

Contact

Contact Me:
sadagopan@gmail.com

Linkedin Facebook Twitter Google Profile

Search


wwwThis Blog
Google Book Search

Resources

Labels

  • Creative Commons License
  • This page is powered by Blogger. Isn't yours?
Enter your email address below to subscribe to this Blog !


powered by Bloglet
online

Archives

Saturday, November 20, 2004

The Natural History Of Software Platforms

Synthesist writes about the history of platforms in a very interesting and provides an insightful perspective about the future of software platforms. Excerpts:

The article starts with a discussion about Ray Ozzie's article titled 640KB ought to be enough for anyone , discussing about software integration, interoperability, and standards might be reconciled with my own beliefs about the inexorable commoditization of successful packaged software and the long, slow, decline of the packaged shrinkwrap software industry.Clay Christensen recently devoted a large part of a long lecture to his theory of "the conservation of attractive profits" (a phenomenon that he also calls "the conservation of modularity"). To me, this theory bears directly upon Ray's assertions about the business impact of software architecture, and more generally upon several "truths" that I've observed during my career in the software industry, but have never been able to explain succinctly.

Clay Christensen recently devoted a large part of a long lecture to his theory of "the conservation of attractive profits" (a phenomenon that he also calls "the conservation of modularity"). This theory bears directly upon Ray's assertions about the business impact of software architecture, and more generally upon several "truths" observed in the software industry, but have never been able to explain succinctly. In Chrsitensen’s own words,:- "Products are most profitable when they are not "good enough" to satisfy customers' needs. This is because to make them performance competitive, engineers must use proprietary, dependent architectures. Use of such architectures makes product differentiation straightforward, because each company pieces its parts together in a unique way. Once a product's performance is good enough, companies must change the way that they compete. The innovations for which customers will pay premium prices become speed to market and the ability responsively and conveniently to give customers exactly what they need, when they need it. To compete in this way, companies are forced to employ modular architectures for products. Modularity causes the products to become undifferentiable and commoditized. Attractive profits don't evaporate, however...
They move elsewhere in the value chain, often to subsystems from which the modular product is assembled. This is because it is improvements in the subsystems, rather than the modular product's architecture, that drives the assembler's ability to move upmarket towards more attractive profit margins. Hence, the subsystems become decommoditized and attractively profitable"
.

It can be said that every "pure software" company that has had large-scale success first offered their customers enhanced productivity in the form of packaged proprietary software, followed later by a redefinition of that software as a platform to be used by customers for rapid customization and their extensibility needs. (Such platforms, besides solving customer problems, also have the salutary effect of ensnaring those same customers and extenders within their "ecosystems," slowly raising switching costs over time. Think of customers and small-scale participants in these ecosystems as boiled frogs...) Platforms exist at many layers of a software system, and slowly come and go as their usefulness waxes and wanes over many product cycles. Programs like Ozzie's Groove and Notes, Microsoft Office, or even Nullsoft's Winamp are application-level platforms. The Java API, coupled with a Java virtual machine, is a middleware platform, as is Microsoft's Common Language Runtime and its managed libraries. Windows and Linux, of course, are operating system platforms. Even low-level device subsystems can be platforms; stackable filesystems, "miniport drivers," and constellations of hardware devices that depend upon standardized interconnects such as IEEE 1394 or USB all rely upon platform-like dynamics to sustain their obscure (if not lively) ecosystems.

Platform Gravity - Component marketplaces and integrated solutions built on the shifting sands of not-yet-commoditized software are seldom profitable, and always fraught with maintenance problems. Despite their flaws, software platforms such as application executables, virtual machines, operating systems, and driver subsystems, represent very real value to those who build and maintain them. Their impossible-to-reproduce code has almost always accreted over time into monolithic and monumental hairballs, crisscrossed with compromises and architectural peculiarities that reflect the history of adaptations to ship schedules, underlying infrastructure, bugfixes and patches, and changing customer requirements. Such vendors who build them invariably place themselves at risk of commoditization through cloning. Christensen refers to "modularity" as the necessary ingredient for customization, which ultimately leads to non-differentiability. Because of the monolithic nature of platforms, the emergence of modularity in software is not typically accomplished through retrofitting or platform rework. Instead, it occurs through a hardening of the external shell presented by the platform over time. As a platform succeeds in the marketplace, its APIs, UI, feature-set, file formats, and customization interfaces ossify and become more and more difficult to change.

The process of ossification makes successful platforms easy targets for cloners, and cloning is what spells the beginning of the end for platform profit margins.
Value Waves - Printer drivers were once commoditized by word processors, Microsoft Office is currently being commoditized by OpenOffice, Internet Explorer will eventually be commoditized by Mozilla, Opera, Safari, and other browsers, and the Unix API has nearly been completely commoditized by Linux. New platforms emerge above and below freshly commoditized layers, exploiting the standardized interfaces and newly "free" infrastructure. Attractive profits are conserved, not destroyed. Butler Lampson's presentation on components evolution,provides an excellent insight into how components can be built. Microsoft's heavily touted WinFS storage subsystem, represents an interesting new platform, useful and therefore support a large ecosystem. In the absence of commodity (replaceable) implementations, however, its schema-based extensibility will fail to become universal in the same way that Microsoft component models have failed to become drivers of commodity value. Microsoft is very unlikely to seek to erode their margins by "premature standardization."

Profiting from Platforms -ossification, followed by cloning - is how Christensen-style modularity comes to exist in the software industry. What begins as a value-laden proprietary platform becomes a replaceable component over time, and the most successful of these components finally define the units of exchange that power commodity networks. There is huge value to be captured from commodity networks, but it is not to be found in the production of the underlying software resources. Instead, this value can be found in the distribution of platform-standardized information, and also in the form of political power. Microsoft, for example, recognizes that it is likely to accrue huge profits in the future by controlling distribution networks for digital media and web-published content; their pursuit of the search engine business and of DRM are both strategic moves in this direction that go beyond media players and productivity apps. In general, the owners and maintainers of mature software platforms should augment the production of packaged software with strategies that exploit distribution of the commodity by-products of their platforms. By doing this, they are likely to avoid the terminal side-effects of commoditization, while continuing to derive benefits from their platform assets. An excellent, must read article.
|
ThinkExist.com Quotes
Sadagopan's Weblog on Emerging Technologies, Trends,Thoughts, Ideas & Cyberworld
"All views expressed are my personal views are not related in any way to my employer"