Do platform choices really matter?

Cross roads horizon

Does it matter what software platform choices companies make? This question came to mind recently after I had read some articles about Oracle’s woes with security flaws in its Java platform. I realised that any company that had chosen this platform was massively affected.

At the mercy of others

First some history…Sun Microsystems created the Java programming language. Many years later Oracle bought Sun and inherited Java. Java is used by many companies to build enterprise applications. In the early days of Java, Sun thought it might be a useful way of running complex applications inside a user’s browser. Applets were born. Developers could now write Java code that would run inside a Java runtime environment in a browser.

In April 2012, Oracle apparently learnt of some security flaws in Java for desktop browsers. They decided to sit on this information since a Java update was only due in October. By August, hackers had become aware of the flaw and were actively exploiting it to gain full control over users’ computers. At the end of August, Oracle quickly published an unscheduled update to fix the holes. Unfortunately, that’s not where the story ends. Within hours, security researchers claimed to have discovered new vulnerabilities in this latest version of Java. So, for most of August anyone running Java in their browser was vulnerable to having their machine compromised by hackers and criminals. Even now, their machines are still at risk as soon as those hackers and criminals figure out how to exploit the new flaws.

Thankfully, applets never took off. But some companies had already chosen Java applets as their development platform. One such company is Standard Bank. Standard Bank’s business banking system is called Business Online and it runs entirely using Java applets on the front-end. Standard Bank’s decision to use Java applets is therefore having a direct impact on all of their enterprise clients. We’d love to switch off Java in all our users’ browsers but we can’t. Some of them need to do online banking. How many IT departments are now nagging their Finance departments about the vulnerabilities in their chosen bank’s system? Would this push any of those Finance departments to move to a new bank? Probably not, since switching costs are prohibitively high in these situations. But if this wasn’t the case, Standard Bank would be haemorrhaging business clients, I think. All because it had chosen a platform to invest in that was now unpalatable for reasons outside Standard Bank’s control.

Out with the old, in with the new

Some other examples of platform choice disasters come to mind. If the year was 2001 and you were an IT Manager or CIO deciding what platform to use to build your company’s major new web application on, chances are that Active Server Pages (ASP) was on your list of candidate platforms with VBScript as the programming language. If you were a Microsoft shop, then it was probably your preferred platform. Say you built the web app and your company started using it. Bang, in January 2002, ASP.NET is released with no backwards support (language-wise) for the old ASP code. You could still run your old ASP code in IIS but the language and platform were dead. All new enhancements would be happening on the newly created .NET platform instead.

Luckily, Microsoft have maintained ASP support in IIS. ASP/VBscript doesn’t work out-of-the-box but you can easily enable it. But VBscript is an obsolete language and ASP is an obsolete technology, so finding skills to maintain the applications is difficult. And if you want to take advantage of new libraries or do a major enhancement of functionality you have to start over from scratch with a new ASP.NET application. Many companies find themselves in this boat. They are stuck with legacy ASP apps that are a nightmare to maintain. We should know. We help many of them transition to the new ASP.NET platform.

Beware the latest and greatest

A more recent example is the Ruby programming language. Ruby was (and is) all the rage in many parts of the world, especially in Silicon Valley. After the Ruby on Rails framework was published a few years ago, web developers flocked to using this to build their web applications. BaseCamp, Twitter, Groupon, SCribd and GitHub are all Rails applications. Based on this international success, some South African web development companies started offering Ruby on Rails development for their clients. The platform allowed for quicker development time. Sadly, many in South Africa who chose this platform are probably regretting their choice. Skills are in short supply so maintaining your app becomes quite expensive.

What to do?

How to avoid these headaches? When making a platform choice, look for platforms that offer future-proofing. Some of the indicators I think you should look for are:

  • For commercial platforms, a provider with deep pockets
  • For open source platform, a large community of contributors
  • Large numbers of developers skilled in the platform and its programming language
  • Many universities and training providers offering courses based on the platform
  • Security is a big concern for the platform and holes are patched quickly

Together with this go all the other criteria for choosing a good platform (flexibility, scalability and extensibility).

In summary, platform choices DO matter. Try finding platforms that appear to be relatively future-proof. To do otherwise might be a costly decision.