Aug
9
2010
Fragmentation or Diversity?
Author: Jeremy Smyth
In conversation with a client recently, we discussed the issue of fragmentation in the Java EE space, and how it impacts large organisations. Java EE (previously J2EE) is a set of specifications and standards, with no definitive IDE or application platform. This is by design, and is in contrast with .NET development, which (almost) invariably takes place in Microsoft’s Visual Studio IDE, and deployed to Microsoft’s Internet Information Server application platform runnning on Windows. Java EE systems may, on the other hand, be developed in Oracle’s JDeveloper, IBM’s Rational Application Developer for Websphere, IntelliJ, Eclipse, or NetBeans. Applications may be deployed to Tomcat, BEA Weblogic, IBM Websphere, JBoss, Glassfish, Oracle’s Application Server, and so on.
As an example, consider a large organisation with several development projects on the go at any time, each one started by a different owner/business unit, and potentially hiring individual contractors to get started on the bones of the project, from a spec they’ve created together. The contractor often chooses the framework based on their own experience, and so begins the tie-in for that particular project. As projects mature, their internal development staff take over maintenance of the project, and discover that they have to learn another framework, platform, or even IDE as they transfer between offices.
One solution employed may involve hiring the same large consultancy firm for many of their projects. This ensures consistency — a large consultancy firm will have internal development guidelines and standards — but is quite expensive, so far from ideal. Many organisations hire individuals to provide the expertise required to kickstart a project, and then add their own developers once the maintenance phase arrives. This is where the fun begins.
A modern Java EE application might use JSF or even Visual JSF. Or maybe Struts 2. Or perhaps Spring MVC. Each of these relies on a proper build process, so maybe we’ll use the IDE to build it. Netbeans. Or perhaps Eclipse. Or maybe an IDE-independent build tool, like Ant. Or perhaps Maven. Then we’ll deploy it to a suitable application platform. Glassfish, maybe. Or JBoss. It’s no longer enough just to learn the language; one must also learn the multivarious frameworks, tools, platforms to get one’s work done. One client told me that of the ten developers they had working in their Java EE team, each one had a distinct setup on their workstation. And this was on the same application, all using the same tools and the same platform. So why not just stick with one framework?
Consider Struts. Well, actually, we can’t, and that’s sorta the point. Struts (1) and Struts 2 are significantly different from each other, to the point that migration from Struts to Struts 2 is quite tricky. The developer’s website links to a three-hour tutorial, a three-part guide, and in the Migration Strategies, suggests (as its first option) running Struts 1 and Struts 2 in parallel. So, I think it’s fair to say they are sufficiently different platforms as to be considered separate.
Having said all that, I still think it’s a good thing that this diversity exists. Yup, what I called fragmentation earlier is now diversity. Look at the open source world: the Linux kernel has had thousands of developers working on it, yet is as enterprise-ready (if not more so) than many more monolithic systems. There is no single Linux distribution; Red Hat, Ubuntu, SuSE — all have carved their own very large niches in the industry, and each with a large degree of success. Sure, a project may start and then flounder as another, similar project dominates the niche. Perhaps one or two major players succeed at the expense of others, and we end up with competition in the space, with quality improving on both sides; KDE vs. Gnome, Eclipse vs. NetBeans, .NET vs. Java EE. Evolution is needed to get to that point, and that’s where diversity is a good thing.
Therein lies the challenge for large organisations. The results of such evolution are good for the industry, but the process of evolution is painful. Your modern large organisation is not the instrument of change and improvement; you are not in the business of helping the world decide which framework is the next big thing. You need to make the decision: either reap the benefits of the last generation’s evolution, and back the previous winner, or pick one of the current generation of technologies and stick with it. This is the challenge of conservatism vs. early adoption, but it’s a nettle that must be grasped.
Photo “Diversity Clucks” by chrisjfry
