The Cross-Platform Enterprise Lore

It’s a known assertion that software applications (desktop or distributed) are not truly platform agnostic. Even if a software application is developed as a cross-platform solution, it is very difficult to make it look and work identically across all platforms (operating systems). Hence, lately I’ve been thinking about the quest of cross-platform software applications in the enterprise landscape.

Brian Clapper recently wrote why C# is now a better programming language than Java, and yet, why he still prefers the JVM to CLR:

Sun and the Java community have allowed Java, the language, to stagnate to the point where, compared to C# and Scala, it is almost painful to use.

Brian’s viewpoint is a sign of the times. A lot of Java programmers consider(ed) C# to be an inferior replica of Java, and hiked Java to be enterprise-centric and cross-platform as opposed to C#. In fact, C# (like Java, and other object-oriented languages) is based on C++. For the past 8 years, I’ve been programming exclusively in C#. I’ve consulted in Java solutions before, but sooner than later I realized that C# is abundant and flexible enough. Back then, many Java developers sighted it as sheer marketing by Microsoft to lure developers. I agreed, it was, more so because Microsoft did a better job at designing a modern OO language and a decent IDE to go with it.

Behind the C# versus Java debate, also lies a ludicrous assumption for a programming language to serve enterprise application software in a cross-platform environment. It has to be the most common notion I’ve heard time and again from Java developers and evangelists. However, the lore in reality is quite different.

Enterprise Software

Let me ask you, have you ever developed a business application with the purpose of it being deployed in a multi-platform environment? How often do you think an enterprise application software is required to be implemented across platforms? Rarely, maybe less than 1% of the times, unless it’s a niche system for disparate platforms or legacy components. In context of an average enterprise application software, the fact is that cross-platform support is not a requisite. In a very large organization, the stakeholders don’t really care about the cross-platform aspect of an average software solution. With a few hundred or thousand seats in their dispersed infrastructure, enterprises formulate strict guidelines for their base software installations across the globe. Workstations and servers in these giant corporations run a rigid set of base software (including OS, database, Web etc.), so they already know their target platform. And, if you have a single base platform to support, whether it’s Windows or Linux, enterprise application software gets a bit easier. It’s a perplexed undertaking to build a cross-platform enterprise application, due to the complex nature of technical disparity across systems, and issues associated with cost, maintainability, testing, training, and of-course time.

Google released its new Chrome Web browser, but only for the Windows platform. For the past few months, they have been working on an “identical” version for Mac and Linux, but it hasn’t been a straight-forward approach. It’s just a Web browser. Think about a much more intricate supply-chain management system that must deal with external hardware interfaces, system API’s etc. In 99% of the cases, it’s just not feasible to build a cross-platform software solution in the enterprise. So, when cross-platform support is not an issue for enterprise developers, the architecture choices are suddenly simplified. For everything else, Web applications and SaaS model have already opened doors for business solutions to be ‘hosted once and run everywhere’.

Java is a mature language. Enterprise solutions in the yesteryear’s relied largely on Java and J2EE. Enterprise solutions today are increasingly being built on C# and the .NET Framework (or Mono). The whole idea of interoperability in enterprise apps is irrelevant in my opinion. What really matters in a programming language or technology stack is not its feature set, but its ability to produce results with minimum efforts.