Future of Business Computing

The IT landscape is dotted with plethora of technologies from myriad of vendors that are evolving at an accelerated pace. This variety and pace is a constant source of concern to an enterprise, software product vendor and software developer (this trio will be hereinafter referred to as the community). However, the fundamental software technological infrastructure is typically from two main camps - Microsoft and the rest. 

This bifurcation is worse than the cold war era. It has been the cause of sleepless nights to an enterprise CIO. It has made an independent software vendor (ISV) spend tons of money in trying to reach maximum customers. It has lead to religious wars in the software community, the energy spend in which could have been used to accelerate the pace of innovation. 
This paper seeks to introduce a realistic and practical approach to the community which if embraced will lead to the abolition of software cold war era. It will lead to production of better and highly affordable software that can be used by everyone no matter what kind of hardware or operating systems one uses. Enterprise can then truly focus on business issues rather than on IT issues. ISVs can focus on needs of its customers rather than on system issues like optimization for various hardware, operating systems and technology platforms. 

Software developers can focus on writing domain specific code rather than worrying on issues like, which platform to choose (J2EE or COM+ - please note J2EE vs .NET is not an appropriate comparison - read below), how to leverage software assets like components and frameworks constructed using diverse technologies, etc. Let us now look at some of the concerns of each of the aforesaid stakeholders. 

Enterprise 

• First of all an enterprise wants to focus on its business needs and not get distracted by technological concerns arising out of platform diversity. 
• It does not want to get tied-up by a single vendor. 
• It wants to future proof its investment in technology. By future proof I mean leveraging the strengths of future systems without reengineering existing enterprise application. 
• Wants to integrate and leverage diverse systems that it has with minimum effort and cost. 
• Goes without saying, it wants the mission critical systems supporting its business to run on the fastest and the most robust platform. 
• Should we choose product/application based on J2EE platform or Microsoft technologies like COM+, .NET, etc. 
• Do we require specialized skill (only Java developer or can be a C, C++, C#, VB, Python, Ada, etc. developer too) to maintain this application? 
• Can we truly be technology agnostic!! 

Independent Software Vendor

• How do we make our product leverage components and frameworks written using any technologies? Modern applications use large number of third party components. Should the choice be limited to a component written in a particular language? 
• How can we make our system run at native system speed? 
  How do we make our system take advantage of sophisticated hardware like symmetric multiprocessing systems? Do we write a separate version for an 8-CPU Intel machine and another one for Solaris running on Sparc hardware? How do we take advantage of the optimizations on Itanium chip? Should we maintain multiple versions for different platforms (and by platform I mean operating system and hardware combined and not just the former) 
• Granted some of these concerns might not directly affect a business product vendor or a custom enterprise application, it definitely will affect it indirectly. For e.g. imagine an ERP system written on top of J2EE application server. Your product performance will be as good as the application server. If the latter is like a one thing fits all kind of system and is not written to take advantage of sophisticated hardware systems then your ERP loses out on performance aspect compared to a natively optimized ERP.
• How can we provide easy hook into our system (so that it is extensible) and that too by any other developer using any language? 
• How do we attract maximum numbers developers having preferences for any technology? Do I publish my API only in C++ or just in Java or can I target everyone be that C, C++, Java, VB, Pascal? What will be the cost of doing so?

Software Developer

• What platform should I work on, J2EE or Microsoft? 
• Do I have to learn a new language for using the aforesaid platform? 
• How easily can I integrate components written in any other language than the one used for constructing the application? 
• Can I embed a visual browser component (like Internet Explorer) and embed that into my Java application? 
• Will my code have the speed equivalent to an application written in C? 
• Can I directly call another components interface written in a different language from my component? For e.g. while writing an FTP GUI application written in Java, can I use a C ftp component? 
• Will my code take advantage of superior hardware even on systems running the same operating systems? For example will my code written for Windows OS running on Xeon processor but constructed (compiled) on Pentium II will take advantage of Xeon's enhanced instruction set. 
• These are amongst host of thoughts that cross the mind of a business entity, software product vendor and a software application developer. 
• The economic implication for this existing scenario is the huge cost that the society has to bear. Some of them are:
  Millions of dollars of porting between competing technology platforms like J2EE, MS COM+, CORBA, etc. The same money could be used to enhance the business. 
• Software vendors like BEA and IBM spend billions of dollars in ensuring that their product is available and optimized for myriads of hardware and operating system combinations. Obviously the cost is passed on to the customer. 
• The enormous waste of effort and resources in leveraging diverse systems as well as integrating across various platforms. Sometimes integration of simple systems across technologies either takes a lot of effort or practically is infeasible. In essence a large number of IT projects in the enterprise is not geared towards solving business problems but rather towards artificially created needs. It is like, instead of focusing on customer relationship management (CRM), you focus on CRM using J2EE or .NET or CORBA or some custom product and migrating between these systems. 
• The developer community waste time and energy on reinventing similar functionality across various platforms. For e.g. a rich mail component written in Object Pascal or Visual Basic cannot readily be used in C or Java and therefore one has to develop or search only for C/Java mail component. 
  Unproductive discussions on competing technologies instead of exchange of thoughts in design, etc. that is more end user solution focused. 
• The open source community has shown that code developed collaboratively is more robust and less expensive due to cost of development being shared by several entities. Fragmentation of the platform technologies has lead to production of systems that cannot be certified as 100% foolproof. Further being proprietary these systems are many a times exorbitant.

Having looked at the concerns and cost to the society because of the technology swell, can we expect a world that will address all the aforesaid concerns. The answer is yes. The next question would be, is the solution a futuristic one or is there something that exists now. The answer to the latter question is also affirmative! Yes we are close to a harmonious information technology world that will solve all the above problems and this is not a wishful statement. So let us now explore how we can realize the dream solution. I must warn that from this point onwards the discussion would be little technical. My aim would be to keep it as simple as possible. It would be advisable to have the corporate architect besides those amongst you who are not very concerned with low-level technology details. First of all I would like the readers and especially the product vendors like IBM, BEA and the likes as well as individual software developers to keep their prejudices in cold storage till the end of this article. The realistic scenario that is introduced here is evolutionary and not revolutionary and therefore does not cause any economic disadvantage to an entity. In fact after vendors like IBM, BEA, etc. embrace the approach delineated, they will save huge amount of money in developing their product lines and at the same time produce products whose performance is quantum shift over the same ones produced using current traditional technological platform. Further, customers of software technology vendor can leverage their existing investments on the new technological platform without paradigm shift (i.e. they can develop the same way they used to except that everything now becomes more easier and much faster to develop as also at the minimum multiple times superior in performance, almost like gaining speed for free).

All right, so what is this platform that we are talking about. Actually, this is collection of platforms and not a single platform. To the curious and impatient it is Java 2 Enterprise Edition (J2EE) running over Common Language Runtime (CLR) a.k.a. .NET or Mono (in Unix world) or Rotor and who knows how many more marketing names that will be invented. Now J2EE over .NET sounds funny isn't it. 

Before we get into the nitty-gritty let me provide a simplistic view of what we mean by platform in this paper. The platform consist of the following layers. We will limit our discussion to J2EE and Microsoft technologies in this paper. Let us start with the cross-platform and vendor independent Java/J2EE technology. Java was an important milestone in the computing history for a host of reasons like:

• It is a robust environment (sophisticated memory management and security environment). 
• It is very elegant and abstracted away lots of system level issues thereby leading to a simplified, productive and rapid development environment. 
• It is cross-platform. 
• It is vendor independent. 
• The basic Java development environment was free!

It was a boon for business entities having diverse systems. They could now create write once and run anywhere (WORA) applications thereby reducing their cost. The same applied to software product vendor who could now have single investment model for reaching customers having any kind of systems.
However, Java had some real bottlenecks that prevented majority of vendors from creating highly performing and very responsive client side programs. Even today at Java version 1.4+ (after so many years), client applications built using Java Swing technology are patchy and do not provide native GUI application speed. Further, a Java developer likes to or would like to see Java only world. This totally invalidates the concept of right language for the right job. Some of the bottlenecks are as below:

• Java applications are slow since the executables are in intermediate format (called byte code) that has to be interpreted into native executable format. 
• Even with performance boosting mechanisms like Just-in-Time (JIT) compilation, execution speed increased but the overheads of the JIT mechanism (which happens at execution time) made the application run slower than native programs. 
• Java developers cannot readily use components written in any other language. They have to look for an equivalent in Java. Can a Java developer instantiate a component written in Object Pascal or VB inside his Java program and treat it like a first grade Java object? Definitely not! 
• Integrating components written in non-Java technologies involves expending massive resources.
• Technologies like EJB, JSP, etc. are Java only though it is feasible to use it from any language. There is a very subtle however important difference between language and technology. For instance Servlets and Enterprise (Java) beans (EJB) are technologies. They are an abstraction for web application computing and distributed object computing. They are specifications and not a concrete product. Can a C++ developer write an EJB code? No way. But in reality it is highly possible to use EJB technology easily from any object-oriented language.
• The scenario is further exacerbated by some vendors implementing the J2EE specification (i.e. creating a J2EE app-server) in Java itself which as mentioned above is not inherently a high performance environment.
• Java execution environment is usually optimized only for an operating system (OS). It is not optimized for a hardware platform. For example JVM is available for an OS like Windows, Solaris, Linux, etc. You don't get a JVM for Windows optimized for an Itanium, for a symmetric multi-CPU setup, for a P4, for an AMD chip! All these platforms provide so many enhancements which if desired would require writing proprietary code.

So for all the elegance and the benefits mentioned above why do we Java guys (and yes I have been that till recent times and long after MS launched .NET) have to suffer the ignominy of:

• below native code performance. 
• suffering to integrate, like a glove, native executable of any type written in any other technology. 
• losing out on cross-language component centric development. 
  Now, at this point don't get upset (for the passionate Java guy). In the next edition, we will see the various suggestions and reasons put forward by the author.

The author of this article is Arjun Mukherjee and he works with Vitusa as Chief Software Architect.