VMware offers training and certification to turbo-charge your progress.Learn more
You may remember the AMC Gremlin--a strong claimant for ugliest car ever. The Gremlin was produced back in the 70s, but there are still a few around, like this one, which I photographed last year in San Francisco.
The enterprise Java experience today reminds me of this piece of American motoring heritage. The Gremlin was a desperate response to the oil shock. AMC needed a “compact” car, so they took the smallest car they had and chopped it in half. The end result sold surprisingly well, but showed unmistakable signs of the fact that its front and rear were produced by different teams and hastily cobbled together. Needless to say, it was Japanese and European manufacturers who triumphed in the shift toward smaller cars.
A few parts of the picture are pretty much givens: like Spring and Hibernate, an Eclipse-based tool suite, and (increasingly) Apache Tomcat. But the whole relies both on developers making numerous choices for each project, and substantial in-house glue and supportâthe latter, another area in which we ignore or become resigned to the cost consequences.
Microsoft also provides a case in point. Microsoft considers everything from Visual Studio through to SQL Server (and even, with Azure, cloud) as part of a single vision, and, while not all the constituent parts are ideal, the result is a far more integrated experience than is provided by enterprise Java.
Of course, neither example is perfect. Ruby on Rails achieves productivity partly by sacrificing the ability to deal with complex scenarios, such as working with legacy databases. Microsoft's success is achieved through monopoly. It's easier to achieve an integrated result when one company controls all the parts.
Fortunately, open source provides the opportunity to achieve the same results, but in a far more open manner. While no individual open source project addresses the full application lifecycle, it is possible for a vendor to build an integrated experience drawing heavily on open source and hence minimize vendor lock in. Building on open source also allows a vendor to choose market-leading solutions in each area, rather than cobble together a product from its in-house parts bin (a la AMC).
Surprisingly, in the Java space, no vendor seems to have risen to the challenge, and few have even tried. Despite its control of the Java specifications, Sun has never been a strong enterprise Java vendor, and has never seemed to fully understand the productivity problem in Java. (Furthermore, productivity problems are typically solved by products rather than specifications. Only recently, and arguably too late, has Sun started to realize this in the Java space.) IBM does have solutions spanning the entire lifecycle, but in IBM's case, having a joined up vision does not make up for the poor productivity characteristics of most of the constituent parts. Any solution to the software lifecycle that starts with Rational Application Developer and has WebSphere at its core is unlikely to provide a modern productivity experience, or make Java competitive with competing platforms. Microsoft, for all its faults, understands the needs and desires of developers at a far deeper level than any traditional enterprise Java vendor.
The established vendors in enterprise Java are also responsible for creating the complexity that produced many of the productivity problems in the first place, and hence are not the likeliest candidates to resolve them. Plus, especially after the industry's recent consolidation, they are huge companies. Huge companies usually don't get simplicityâand, often, it's not in their interests to do so.
Spring, and SpringSource, has always been focused on eliminating enterprise Java complexity. Appropriately, “Eliminating Enterprise Java complexity” is now our company tagline. To this end, we've been working hard for over 6 years. While Spring began by minimizing enterprise Java API complexity through innovation, it has long since moved to address broader challenges--such as security, batch, integration and web servicesâwhile SpringSource as a company has become broader than Spring. With Spring, Grails, Spring Dynamic Modules and SpringSource dm Server and the simplification of OSGi, SpringSource has long set the agenda for enterprise Java productivity.
Eliminating enterprise Java complexity means considering every stage of the application lifecycle. It means more than just a server or application framework, no matter how good. It's hard to imagine any modern fully integrated solution that does not rely heavily on Spring, but Spring is only part of the picture.
This focus explains why we are now the company behind Grails--the most productive technology on the JVM; and why we built the SpringSource Tool Suite to help speed up enterprise Java development with Spring.
It explains why we have moved into other areas, such as the application server spaceâtaking a leading position in the industry's leading application server (Tomcat) and building SpringSource dm Server, a next-generation modular application server. It explains why SpringSource tc Server and SpringSource AMS (Application Management Suite) provide powerful management capabilities for applications deployed to the data center.
The Build/Run/Manage lifecycle is central to how we see the world. You will see major announcements in the next weeks and months about product and build initiatives to strengthen our story throughout the lifecycle. You will see us extend our technology in order to pursue it.
I'm confident that SpringSource will become a major middleware vendor as a result of solving these problems. However, the real winner is you. Enterprise Java can be (and needs to be) much more productive. SpringSource is focused on this goal, has the ability to deliver, and the community both underpins and stands to benefit greatly from our efforts.