A lot of developers end up in the Java “enterprise” world at some point in their careers. I know the term alone conjures up all kinds of reactions, and rightly so. Often environments where lots of interesting technical challenges exist end up being those that nobody wants to work on because they are brittle, difficult to work on and just no fun. Often the problems that crop up in big projects are due to management, but I’ve seen developers make lots of bad decisions that lead to awful pieces of software, all in the name of “enterprise”.
What is Enterprise?
You could argue that the term can mean just about anything, and that’s true, but for the sake of this article I’m going to define it in a way that I think lines up with the common usage. The average enterprise project has these attributes:
- typically in a large corporate environment
- multiple layers of management/direction involved
- preference for solutions from large vendors like Oracle, Microsoft, IBM
- preference for well-known, established (though sometimes deficient) products and standards
- concerns about scaling and performance
Now that I’ve defined what type of project we are talking about, let’s see what they usually end up looking like.
The Typical Enterprise Java Project
Most of us have seen the hallmarks of enterprise projects. It would help if we had an example, so let’s pretend it’s an e-commerce platform with some B2B capabilities. Here’s what it might look like:
- EJB3 plus JPA and JSF – these fit a “standard” and everyone use them, so it’s safe choice.
- SOAP – it’s standard and defines how things like security should work, so there’s less to worry about.
- JMS Message-Driven Beans – it fits into the platform and offers reliability and load-balancing.
- Quartz for job scheduling – a “safe” choice (better the enemy you know than the devil you don’t).
- Deployed on JBoss – it has the backing of a large company and paid support channels.
Now, the problem with a project like this isn’t necessarily the individual pieces of technology selected. I definitely have issues with some of the ones in my example, but the real issue is how the choices are made and what the motivations are for using certain technologies.
The stack of software above is notoriously more difficult to manage and work with compared to other choices. Development will take longer to get off the ground, changes will be more difficult to make as requirements evolve, and the project will ultimately end up more complicated than other possible solutions.
The goals that enterprise projects usually fixate on when making choices are:
- Low-risk technology – make a “safe” choice that won’t result in blow-back, even if it is known to have serious drawbacks.
- Standards obsession – worrying more about having well-defined specifications like EJB3 or SOAP than offering the simplest solution that does the job effectively.
- Need for paid support with an SLA, often without concern to the quality or timeliness of responses.
- Designing out of fear of unknown future requirements.
These goals aren’t bad ones, with the exception of the last one, but they tend to overshadow the real goals of every software project. The primary objective of all software projects is to deliver a project that:
- is on-time;
- meets requirements;
- is reliable;
- performs well; and
- is easy to maintain and extend.
These should be what decision-makers focus on in software projects, whether small or large. It’s obvious that sometimes special organizational needs factor into the choices that are made, but fundamentally good choices generally apply in all types of organizations.
So what if we were to reimagine our project with those goals in mind instead?
A Reimagined Enterprise Project
First, a little disclaimer: there are many ways one can go in any project, and I won’t claim that the technologies below are better that the ones mentioned previously. Tools need to be evaluated according to your needs, and everyone’s are different.
What I will try to do is demonstrate an example technology stack along with the reasoning for each choice. This will show how well designed systems can be built which survive in the enterprise world without succumbing to the bad choices that are often made.
Here’s the suggested stack:
- Spring MVC using Thymeleaf – stable history, lots of development resources, quick development and flexibility. Don’t be afraid of using platforms or libraries, but try to avoid too much “buy-in” to their stack that you might regret.
- Simple database layer using jOOQ for persistence where useful. This lets us manage performance in a more fine-grained way, while still getting easy database interaction and avoiding ORM pitfalls.
- REST using Jackson JSON processor – REST and JSON are both popular because they are easy-to-use and understand, cheap to develop, use simple standards and are familiar to developers. Lock-in isn’t much of a problem either – we could easily switch to another JSON processor without much difficulty, unlike SOAP. This can be easily secured with SSL and basic authentication.
- JMS messaging using JSON-encoded messages on ActiveMQ – loose coupling, reliability and load-balancing, without the nastiness of being stuck with Message-Driven Beans.
- Obsidian Scheduler – simple-to-use, offers excellent monitoring and reduces burden on developers. Once again, the goal is to simplify and reduce costs where possible.
- Deployed on Tomcat – no proprietary features used. This helps us follow standards, avoid upgrade issues and keep things working in the future. Who needs support with SLAs when things aren’t inexplicably breaking all the time?
I think the stack and corresponding explanations above help give an idea to what an enterprise project can be if it’s approached from the right angle. The idea is to show that even enterprise projects can be simple and be nimbly built – bloated frameworks and platforms aren’t a necessary part, and rarely offer any significant tangible benefit.
Recent trends in development to technologies like REST have been very encouraging and inroads are being made into the enterprise world. Development groups are realizing that simplicity leads to reliability and cost-effective solutions long as the underlying technology choices meets the performance, security, etc. needs of the project.
The software world moves quickly, and is showing promising signs that it’s moving in the right direction. I can only hope that one day the memories of bloated enterprise platforms fade into obscurity.
5 thoughts on “Java Enterprise Software Versus What it Should Be”
This is brilliant! I’ve been working in a Java Enterprise environment for about 3 years, but haven’t been able to properly explain to anyone exactly why the way things are done is wrong or at the very least not good. You do a fantastic job, and I can’t help but feel like this has come from a bit of experience in bad enterprise environments. Thanks for the write-up!
The information given here on Java Enterprise is really useful, especially on the typical Enterprise Java Project. If you want to know more about training courses in Java, you can visit this link.
Thank you for this article. I purposely changed my career track to work with Java enterprise to shore-up experience with large-scale, back-end issues. Your succinctly summarized my own experience. In short, no fun. I’m sure there are companies that do it right and flourish. But for the most part, “Java enterprise-level” on a job advertisement has come to be code for “maintain legacy-code.”
I purposely changed my career track to work with Java enterprise to shore-up experience with large-scale, back-end issues. You succinctly summarized my own experience. In short, no fun. I’m sure there are companies that do it right and flourish. But for the most part, “Java enterprise-level” on a job advertisement has come to be code for “maintain legacy-code.”
Spot on! Except for the plug for your scheduler – but I don’t know enough about both quartz and your scheduler to choose among them.
Comments are closed.