Aaron Griffin's team is just starting to recover from a bad case of Enterprise Fever. Up until a few months ago, they were responsible for maintaining an ASP/ASP.NET web application. No, their system wasn't the greatest, but it was fairly documented, easy to work with, and, most importantly, did the job. But one thing it lacked, so said upper management, was "enterprise." And that is something that no system should be with out.

Unfortunately, Aaron's team also lacked enterprise; if they had it, they sure wouldn't have built a system without any enterprise in it. Thankfully, management knew that there are plenty of consultants with plenty of enterprise. They went and hired a company that was so enterprise, it even had enterprise in its name! Finally, the system would be flowing with enterprise and, therefore, be a much better value to its users.

The first thing that had to go with the system was its platform. But why?!?, begged Aaron, we're all .NET developers! The consultants scoffed, answering that Java is an enterprise platform. Obviously, Aaron didn't know what the first "E" in J2EE stands for.

The next thing to go was the architecture. Before, their application used a simple, three-tier approach: the UI called a business objects which in turn called a stored procedure. The enterprise way to do things was much better, as the following example demonstrates ... 

//Loading an ApprovalRequest object
HashMap objectQuery = new HashMap();
objectQuery.put("ApprovalRequest","*");
objectQuery.put("ApprovalRequest.RequestId","11799");

String[] unused = new String[1];
unused[0] = ""; //note this is only used for updates

GenericObject myRequest = ApprovalRequestInterface.Query(objectQuery, unused);

Aaron questioned why it had to be so much more code to load a simple request. The consultants explained: In our experience, enterprise applications require significantly more code as non-enterprise.

What's true about enterprise code is also true about enterprise database schemas. The old database had a paltry thirty-one tables; not even enough for the enterprise user authentication subsystem. Not only that, the old names had tables with names longer than three characters. Not a good strategy if you want to use certain enterprise tools ...

It was a rough transition, but it worked out for everyone pretty well in the end. As it turns out, Aaron's team didn't really need to learn too much Java; the consultants brought their own framework (the "Enterprise Foundation"), built on top of Java's, that they all had to learn instead. And although the system has a lot more bugs, is difficult to maintain, and has a much poorer user interface, all that really matters is that now it's enterprise.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!