« What will the culture of the 2000s be remembered for? | Main | Video on demand: perspectives and opportunities »
September 01, 2006
Is platform heterogeneity in the enterprise inevitable?
Many small to midsize enterprises tend to be pragmatic about their choice of technology platform. Such enterprises would see no harm in operating on a single platform, such as Linux or Windows, so long as all its components work. Such an enterprise is willing to tolerate less than "best of breed" components so long as they all blend into a cohesive technology solution that satisfies its needs.Then there are other enterprises who are determined to use only those components, which, by some measure of goodness, have surpassed all others in their class. These enterprises are willing to stitch a platform together from these components themselves, even if it means that it will be heterogeneous and more complex to manage. Platform heterogeneity is unavoidable given the present enterprise software environment, so long as such enterprises exist. We will identify a few factors, which, when resolved, might enable one platform to claim the entire enterprise market for itself. We will also see why vibrant open-source communities are key to reducing the complexities associated with platform heterogeneity.
The second kind of enterprises identified above (let's call them "best-of-breed-only"--BOBO, for short) seem to accept platform heterogeneity as a fact of life. Unsurprisingly, these enterprises have significant technology investments and large internal development teams to support their internal IT operations. Year after year, major technology stack providers vie for their hearts and minds by commissioning industry analyst firms to conduct ROI/TCO studies that case their own offering in a better light.
Typically, one finds that BOBO enterprises choose Java on the server side and Windows/Microsoft .NET on the client side. Java, having been around twice as long as Microsoft .NET, offers a compelling server platform with a flourishing open source community around it. In many cases, the open source community brings to the table significant design experience and maturity arising from language traditions that predate Java. This development heritage has led to a superior set of administration and management tools that can be combined in new and interesting ways to provide the data administrators need. Moreover, a significant number of infrastructure and middleware players have thrown in their lot with Java, resulting in, for instance, multiple viable implementations of the Java virtual machine standard.
Microsoft .NET may not have as vibrant an open source community around it as Java, but it has a stranglehold on the client that is only cemented by vendors like Infragistics Inc., who produce professional-looking user interface controls around the basic windowing toolkit. The narrowly defined user interface standards of the Windows platform ultimately lead to a more predictable look-and-feel for end-users, thus making Microsoft .NET the best-of-breed client platform. The Windows/Microsoft .NET platform is also preferred by end-users because it can best emulate the look and feel of familiar Microsoft Office applications. Java rich client applications, in contrast, continue to look out of place amid other applications that share the desktop with them. However, because user expectations for Web interfaces are more flexible, Java continues to show considerable promise as a Web-based client platform. A definitive victory for Java Web client frameworks like Seam is not in sight though, because Microsoft .NET's ASP.NET Web development platform also offers a compelling platform on which software developers can be highly productive.
Java has arguably less of an uphill task than Microsoft .NET in taking over the entire enterprise segment. Its major areas of improvement are clearly seen to lie on the client side. Because of early positioning and quality control mistakes from Sun, Java has acquired a reputation of awkwardness on the client that has become hard to shake off. However, open source initiatives like the Apache Foundation have captured the talent, the momentum and the mindshare to produce a compelling, pure-Java client side solution if they only look beyond producing the next application server framework that conforms to some more JSRs. In other words, just because new projects keep satisfying some Java community-defined notion of cool doesn't mean they are always appropriate in an enterprise setting. This sort of "server-is-king" attitude is a holdover from an ancient mentality that treats the client and presentation layer as an afterthought once the core engine has been built. This attitude is outdated today, in an environment where it is necessary to access server-side business logic from disparate kinds of clients, including rich client and mobile profiles. Java's insistence on write-once-run-everywhere to the fullest extent possible might well prove to be its undoing in this regard, because writing versatile client frameworks requires a flexibility server-only engineers can afford not to have.
If Microsoft .NET's aim is to have the enterprise segment in its back pocket, there needs to be a much better sense of community and ownership around the platform. Microsoft is doing nothing to prevent the death of major open-source .NET projects like NDoc. If anything, it releases products that supplant these projects, such as Sandcastle in the case of NDoc. However, the blame for this state of affairs does not lie solely with Microsoft. Once Microsoft releases a competing implementation, community members consider their efforts necessarily nullified, a practice that does not bode well for the health of the platform. Open source projects on the Microsoft .NET platform must have a life of their own, independent of Microsoft's efforts, rather than being stop-gap efforts until an officially sanctioned product that supplants them comes along. Understandably, developers are wary of the Microsoft juggernaut's track record of entering a domain and instantly quenching all its competition. However, if the records of major .NET open source projects like Mono are to be believed, Microsoft's Developer Division, the division behind Microsoft .NET, has been remarkably open about and supportive of Microsoft .NET development originating outside Microsoft. It is, at least to some extent, the responsibility of the .NET open source community to consider accepting this hand of friendship, even if cautiously at first.
Then again, there may be those in the open-source community that won't have anything to do with Microsoft because "strong-arming is in Microsoft's DNA". For those incorrigible developers, there is the flourishing Mono project, which brings Microsoft .NET bindings to Linux. Currently, its focus is to provide a broad set of development stacks centered around the Common Language Runtime standard. As such, it is concentrating more on breadth of functionality rather than aggressive performance optimizations. If an aggressive corporate backer throws in its lot with Mono, as IBM once did with Java, it can work wonders for the entire Microsoft .NET development community. Microsoft would be forced to fine tune its own runtime, which is not aggressively optimized in all cases. The momentum gained from such aggressive optimization could infect the rest of the open-source community, thus spurring it on to developing a compelling administrative and management toolset itself, rather than relying on Microsoft to do so.
Platform heterogeneity may have its benefits, chiefly of not having to put all of one's eggs in one basket. However, it racks up significant technology and human costs and is necessarily more complex to manage. The custom platforms of many BOBO enterprises, for most of whom IT is not a core line of business, prevent them from simply outsourcing their IT function to completely managed hosting providers. The key to reducing platform heterogeneity lies in creating vibrant open-source communities around existing enterprise platforms, each with an objective to fix that platform's shortcomings. These open-source communities would no doubt compete for mindshare, but would also learn from each other and ultimately render platform heterogeneity less inevitable and technology costs more manageable.
[Update: For the sake of completeness, I should mention another category of firms, who, being afflicted with NIH syndrome, conclude that nothing out there is good enough and simply develop their entire technology stack from scratch. This harks back to the days when firms would write their own database systems and have programmers code up queries for each kind of report they wanted. Thankfully, due to the maturity of both commercial and open source software, not too many companies think this way anymore. Today even business analysts with a decent knowledge of SQL can define queries for reports. The firms in this category are mostly ISVs and other technology-heavy outfits that already have a significant investment in technology. It is difficult to call their platforms homogenuous or heterogenous, but it does add complexity simply because very few people know their proprietary systems.]
Posted by Vishy at September 1, 2006 07:48 PM