Has anybody noticed that the application platform market is melting down? Service-oriented architecture principles are dissolving the underpinnings of yesterday’s computing environments, making concepts such as “platform,” “application” and “language” irrelevant in the world of Web services.
But SOA and Web services are just one part of the platform-meltdown equation. The platform vendors are also flailing about, not able to achieve the momentum to place their environment -— be it Windows, Java 2 Platform Enterprise Edition (J2EE), or Linux/Apache/MySQL/PPP (LAMP) — head and shoulders above the rest. All these platforms are dissolving into a pool of fear, uncertainty and doubt (FUD) that has enterprise customers scratching their heads, seeing no clear, slam-dunk platform for their current and evolving needs.
Look at Microsoft Corp.’s tortuous path from .Net to Longhorn and beyond. The software giant has decomposed the new generation into a bunch of incremental releases with various release dates, many of them indefinite, strung out over several years, with the strong likelihood of unanticipated delays. Nobody has any confidence that Microsoft will ship any piece of its Longhorn road map on time — that is, within Software Assurance time frames that would entitle customers to an upgrade (for which many have prepaid, with no guarantee of delivery). And nobody has any confidence that the resulting Longhorn-generation platform components, apps or tools will enable tight security.
The rival J2EE camp is slogging through its own field of FUD. One of the biggest issues is whether the J2EE “standard” — actually, an evolving assemblage of standards and specifications developed by Java vendors under the Java Community Process — will survive in the face of “rebel” Java-based frameworks that offer simpler development/runtime approaches than the full J2EE 1.3 or 1.4 stacks.
The fundamental fault line in the Java community is between those who favor development of POJO (plain old Java objects) vs. those who stress what I call “MOJO” (massive obnoxious J2EE overhead). That’s a spectrum from simplicity to complexity, from lightweight to heavyweight, from loosey-goosey to strict-constructionist Java programming. Though J2EE 1.4 is out and J2EE 1.5 is in the works, nobody has any confidence that most J2EE app platforms vendors will support the full evolving “standard” in future releases. Companies that have committed to J2EE are sweating profusely, wondering whether the fabled cross-platform framework is a thing of the past.
The LAMP platform vendor community is still in its heyday — in other words, vendors such as Red Hat Inc., Novell Inc. and JBoss Inc. still can claim considerable momentum in new customer wins. LAMP isn’t a platform in the single-vendor governance model or single-community governance model. Rather, LAMP refers loosely to application environments built on Linux and other open source components (including but not limited to the “AMP” components in its name).
One of the biggest FUD issues with LAMP is vendors’ inability to assure customer indemnification against damages that might result from IP infringements associated with various open source components. Investing in a LAMP-based solution is a bit like buying a house without title insurance: You pay hundreds of thousands of dollars without any assurance that a long-lost titleholder won’t someday be able to evict you from your property.
Another FUD issue is the potential for nasty technical fingerpointing when the inevitable security issues strike LAMP platforms. No two vendors’ LAMP platforms are alike. Each vendor (indeed, each user) can and does assemble an environment from a diverse collection of open source components from diverse open source communities. Any security issue or interoperability glitch will be a nightmare to fix. All these platforms — Windows, J2EE and LAMP — will survive. All will continue to evolve. But none of them will overcome the flood of FUD that cramps their respective futures.
Kobielus is an independent IT consultant and analyst in Alexandria, Va. He can be reached at (703) 924-6224 or [email protected].
