These two platforms have been fiercely competing for the lucrative “Enterprise” business customers since the .NET Framework made it’s Beta debut in late 2001. Since that time the debate has raged on in organizations of every size and in Internet forums of every description: Which platform is the best platform?

Pundits from all sectors of the computing and business sectors chose a side early on and began to incite one of largest technological debates in the history of computing. Proponents for each side have argued their case both for their chosen platform, and against the other. The arguments which have been put forth supporting both the Java/J2EE platform and the C#/.NET platform have been very strong. Conversely, the arguments against each platform are often steeped in half-truths, myths and hearsay.

Whitepapers on the subject are almost exclusively published from a source which has a vested interest in the success of one technology or the other. “Evidence” from both Sun and Microsoft has abounded over the years, though in recent times has died off significantly. Both companies have moved to promoting their individual platforms as pieces of a larger technological and customer-centric model. The reason? The interoperability of the two technologies has grown in such away that today’s service-oriented architectures now focus on what information needs to be exchanged, and not how either end of a transaction exchanges its information. That being said, each platform has its strengths and there is often a choice that can be made to use one or the other depending on the project at hand.

In an age of technological homogenization it is critical that a business spend its time finding the fastest way of solving its problems in the most sustainable fashion for the individual solution. At this point in time, both Java’s J2EE platform, and Microsoft’s .NET 2.0 platform are more than capable of supporting and sustaining enterprise-class applications in almost any business environment. Both technologies have been successfully implemented in almost every tier of the business environment, and each has also failed miserably in these same tiers. So if technological platform is not the determining factor in what makes a business successful what is?

One of the most basic and fundamental concepts in computing deals with the input and output of information from a user, or other source. It tells of a fundamental truth which carries over to the development side of the computing world: Garbage In, Garbage Out. Just as erroneous or unexpected input into a program can produce undesirable results, lack of structure or care in implementing an application will eventually produce sub-standard and unsustainable results. The kicker? It doesn’t matter which technology you choose. Bad code and substandard applications will fail just as disastrously in a J2EE environment as they will in a .NET environment (or ColdFusion, or PHP, or Python, or Perl or…)

No matter which technology is chosen, for any type of application it’s critical that the appropriate amount of thought and planning be put into place. If the application is a quick band-aid and only needs to be around for a couple of months then it probably doesn’t pay to spend weeks designing it (not to mention that you probably need to implement it immediately). But if the project is being undertaken as a large-scale project which will have hundreds or thousands of users it will be a critical piece of business infrastructure for several years. In this case it’s important to make sure that it will last for the time required and it won’t be a constant source of maintenance and frustration for the enterprise.

So what are the strengths of the two platforms?

Java has been regarded for several years as one of the best Enterprise-class development platforms for many reasons. The mechanisms exist, and were built-in from its earliest days to allow for robust n-tier development models. The large number of open-source Java projects in the development community has provided low-cost (or no-cost) tools for producing Java applications, and the continued support of vendors like Sun, BEA, IBM and others has provided robust infrastructure capabilities upon which these Java solutions can be deployed. The cost? Secure robust applications take more time to plan, design and develop.

The Microsoft.NET platfom was put forward initially to be the epitome of Rapid Application Development engines. The Visual Studio IDE that Microsoft sells along with its freely available framework provides an intuitive IDE with tools designed specifically for quickly designing and deploying applications. Most of the supported environments are Windows (though some Linux support does exist). The downside? Building and deploying quickly often leads to sustainment problems over the long term because of a lack of time spent on planning and design.

In an effort to make this article a bit more useful, let’s see if we can come to a determination of when it might be appropriate to choose one particular technology over another. There are several scenarios in which both the Java/J2EE platform and the C#/.NET platforms would each have their particular strengths. Obviously not ever scenario in the business world will fit into the cases outlined below, but these should serve as a pretty good guide as to what would work best under particular scenarios.

First off, let’s make some assumptions:

1. You have a team of 60 people who can work in either platform, some are Java experts, most are comfortable with C#.
2. Both Visual Studio, and a comparable set of Java development tools are available to the team.
3. The corporate standard for Enterprise-class development is Java, and has been since 2000 (prior to the advent of .NET)

Scenario #1

A department within the company is going to be inundated with customer orders because one of the company’s largest customers is giving up relations witha competitor, and moving their accounts to your company. Over the course of the next 2 months, the group will face about 3000 new orders, all of which will be virtually identical. The group normally processes about 2000 orders a month, so this is a major increase. The first of the orders will begin arriving in about 3 weeks.

Because the solution must be delivered in a very short time period, .NET would seem to be an obvious choice. Get the application designed and deployed to help with these incoming applications. But what about the long-term supportability of the application? Since it’s only going to be around for the next 12 weeks, that’s not long enough to be a major concern. Platform recommendation: .NET.

Scenario #2

A group has approached your team about creating a new knowledge-management solution for their team. They are having trouble ensuring that the information their employees have in their heads gets transferred to new people when they leave the company. The requested solution is a web-based encyclopedia of knowledge for the sales teams. They don’t know of anyone leaving in the next couple of months and they expect the solution to last for the next 2-3 years.

This is a long-term project and needs to be worked into the longer term strategy of the organization. Working in concert with the company’s planning and architecture specialists, the application can be worked into the company’s existing Java infrastructure. Maintenance of the application would be handled by the company’s regular development and support teams.

Scenario #3

A group has requested an application that the sales people can use to enter information about a customer sale to help them create the accounts, or enter the customers orders. The catch is that the system needs to work on their laptops whether or not they are connected to the network. The application is expected to be around for a while, if it is successful. In addition a web-portal will be available for the inside sales teams to enter their customer orders.

In this case there is a clear requirement to have a client application, which is something the .NET framework is well suited to. Having the client constructed using Visual Studio is a logical first step. The web portal could be integrated into the sales peoples’ existing tools and would most likely be built in the Java Framework. Finally, since both the application and the web portal would share similar functions, the bulk of the business logic can be extracted into a proper service-layer. Since the application would be around for a fairly long time, all of the components should go through proper design and build processes to ensure their robustness and stability. Combining the two platforms ensures the best use of time and energy, but still provides an effective long-term solution.

At the end of the day, business requirements and not technical prejudices should dictate the type of technology used to develop an applications.  There is no silver bullet.  Anyone who thinks that any one technology can effectively solve all their technical problems will find themselves with projects running over time, over budget or just plain failing.

Businesses who can put aside their egos and political agendas will be far more successful than those who continue to live in the business climate of the 1980s.