Sander Hautvast 12 May, 2010
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.
Immature security will pose security risks. Immature applications have more bugs An immature application costs more than necessary and will undo the cost reduction promised by middleware vendors. Immature applications have a higher TCO because of the ongoing administrative burden after going live. 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: Adequate logging A simple and standardized way of providing environment specifics (properties) Repeatable (automated) build process Release and deployment notes (guidelines for the deployer) Performance tests included No delivery of single jar files or jsp’s (never) security guidelines policy on use of open source libraries (which and which not, and whether and when to upgrade them...) 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). The use of middleware affects the risk and the number of story points of individual user stories. So the middleware architect should be in the planning meetings. At least until the developers know the drill. A middleware competence center is a way of bundling knowledge and practices. It comprises a team of professionals from different backgrounds, architects, developers, deployers, administrators, dba´s etcetera. They serve to contain and spread the middleware knowledge. Lean thinking and kanban is a way of organizing and optimizing the middleware center team. There is a small number of interesting blogs (thanks @nistude) on this subject. I´ll blog on my own experiences in the near future.