Do you really think this is correct? If so, you’re prepared to start next generation software development 
.
When I started my career as consultant and software architect in the mid nineties everything we missed was widely accepted standards to create something stable in the architecture layers. Layers! Not the components that were part of the layers. Heterogeneity meant to develop interfaces between every two products communicating with each other. Then we got CORBA.
CORBA was the golden calf for years. But, the idea to get standardization in the components arena showed, that we need a lot more than CORBA ever delivered. The missing services for security, transactions, … let us do integration work again. Here the Object Request Broker (ORB), and there the security solution, and in the end the integration work for the legacy system and/or the ORB. Meanwhile the Web came up and everything changed. Languages, platforms, communication protocols, presentation logic, user demands.
The world became even more complex and CORBA still couldn’t give us the right tools. Then the first upcoming Standard: virtual machines, beginning with Java. Platform-independent development, one implementation for all and a better object-oriented language than C++, but without the “communication restrictions” of Smalltalk. Web-ready, network-ready, elegant, easy to learn. Fantastic.
When Sun started with the J2EE concept the sun began to shine. Security, transactions, persistence, legacy integration, all the elaborate stuff from the past seemed to get a solution soon. Well, it was clear that this would be a dream, and sometimes still a nightmare, but it was addressed. A cool standard was arising. Well, at a first glance.
When I started with my first Enterprise Java Beans I was a bit shocked of this kind of complexity. Simplicity was and is still one of my most important credos. Simple user interfaces, simple architectures and simple implementations. After years of development I’ve to add: especially simple database schemas. It’s still a strange behavior of projects to start with the database schema and forget to think about the coding that has to use all this shit later. Mostly, a migration to a better schema is too expensive, because it’ already in productive use. What a waste of time!
My unpleasant feeling stayed for years. Well, seems to me that I was right with it. Rod, Jürgen and the other guys from the Spring Framework team prove that it is possible to do it better, do it simpler, do it more elegant. Well, time will tell us, if this will be true for years. But, one thing is clear: the Spring Framework is the core of modern enterprise development and it’s ready to rock.
When the architect in me looks back on this development, I’ve to say, I had to lean to have a better look at the quality of a standard, to question everything that seems commodity and sometimes to skip it to get better results. This finding is a bitter one. J2EE was a rock-solid standard, the Java Community Process (JCP) the surety to get best-of-bread and the guide into a better future. But, all this failed. EJB 2.x is a disaster in development costs, needs code generators to get acceptable results (sih!) and is unacceptable dependent from the deployment platform. Why could such a huge community fail?
I read about the ivory tower design of the Sun architects, when they created J2EE, somewhere some time ago. Maybe there’s a little bit of truth in it. But, maybe we all thought that a standard is something good and shouldn’t be changed – we would get chaos and uncertainty. Well, that’s what we have today because of it.
So, what’s in it for all of us? Question what’s commodity today, ask what “standard” really means to your project (if you’ve refactoring in mind), and don’t ignore your unpleasant feelings .
Today, my search for a better solution is stronger.
