Middleware Management pitfalls 8. Application immaturity

This is number 8, the third article in a top10 of middleware management pitfalls. The previous article dealt with infrastructure. This time I´ll discuss the application itself.
There has been much cool stuff lately about devops and devs and ops working together in one team, like at sky.com. The uncool reality for a lot of companies is that dev and ops are separated in different departments and don´t communicate well. Immature applications, at least from a middleware perspective, are what you get.

One of the aims of middleware is to provide standard components to application programmers. Two of the nicest and widespread examples of this are JDBC and the datasource. JDBC, being an industry standard, is a powerful abstraction delivered by software vendors to enable communication to their database product. The datasource is another abstraction, delivered by application server administrators, to enable communication to the database that their company uses. The latter hides features like connection pooling, statement caching and database specific properties. In the early days of J2EE, though, you were likely to find applications that did not use these features. Instead the application programmers had decided to build them from scratch. A lot of Xebians have in the past removed these homegrown “frameworks” and replaced custom constructs with datasources and the like. These days are over by now….or, so it seems.
It is no longer the homegrown datasources that should worry us. Application reinvents platform, again. Why? Because developers don´t know the platform their applications run on. The reason: middleware products have become vastly complicated, their range expanded into remote galaxies, their depth unknown as the depths of the ocean. Am I exaggerating?
Architects can no longer focus on the mere coding part of an application. The days of just servlets and EJB´s are over. We are confronted with ESB´s, BPM, J2EE, CMS´s and growing integration needs with all kinds of back-ends. An immature application would be one that reinvents an ESB. Or consider the company in which the middleware department has bought a BPM platform (like Oracle SOA suite, or Websphere process server) but at the same time is implementing web services choreography using plain java, because no architectural guidelines (that dictate the use of BPM) have yet been presented to them. The term “immature” is relative to the “maturity” of the middleware stack at hand.

I´m not saying that you are obliged to use the middleware vendor solution for any given problem. Take web services. There are plenty mature open source stacks that will enable you to build them and not use the (outdated) vendor solution. It’s up to the architect to make such decisions. (What is the fundamental difference between a library and middleware? Both should make your coding life easier).
All enterprisy applications need a minimum level of quality regarding deployability and maintainability:

Developers should know and use these rules. Administrators should know and enforce them.
All companies that want to use their middleware effectively need someone who can act as a stakeholder for the administrative department. He, she, or they must actively spread the middleware knowledge among development teams, architects, designers and administrators. Analysis must result in the identification of generic services that can and will be reused. The architecture and the working software should be implemented accordingly. If necessary, a set of criteria must be issued that serves as a barrier against immaturity. Envision a tool that inspects developers deliverables (EAR files) and generates a report that clearly states if an application passes or not (AFAIK there is no such thing).