Thursday, November 23, 2006

Job Statistics - Product and Technology Choices for the Future

As a result of looking at Rick Hightower's blog on jobs for Spring and Hibernate - - it seemed like playing with Indeed Jobs could almost be as entertaining as a video game (for about 5 minutes!).

It has some practical bearing on IT professionals because if you are working with a technology or product where jobs are rapidly going to zero and you have a family to feed or rent/mortgage to pay, it is good to think ahead. It is also a way to identify up and comers as Rick did with Spring.

One problem I had with Indeed engine was how easy it was to come out with misleading results - using "Spring" brought back jobs in places named Spring versus "Spring Java" which brought back jobs more relevant to Spring developers. "Oracle AS" brought back jobs using Oracle in places named or abbreviated "AS". You yourself may have an opinion or two on whether my take here is valid :-)

Trying to get something that seemed to bring back meaningful jobs by product, framework and open source, I have several possibly interesting graphs to share. I have my particular bias, like Rick did in his survey, of seeing how healthy the technologies and products I work on are from a job creation perspective.

The first is "Oracle Application Server", "WebLogic", "WebSphere", "Tomcat", "JBoss" and "Geronimo". I also wanted to transpose the size of the developer market that these server infrastructures represent against the job requirements for some of the commonly used frameworks and technologies so I added in "Spring Java", "Hibernate", "TopLink", "ADF", "BC4J". Here is what I got:

and inline:

I was happy to see that Oracle Application Server came out on top, followed by WebSphere, WebLogic and Tomcat. JBoss was next and Geronimo at the bottom. Admittedly this is somewhat problematic for all products - e.g. WebSphere is a huge brand encompassing more than the application server and the jobs showed this - calling out WebSphere Application Server like here:

makes Oracle Application Server and WebLogic the two dominant application server job generators out there. Correspondingly, I could see a slight DBA bias in the Oracle jobs though in general they were pretty reasonably reflective of middleware jobs, frequently being Oracle Application Server Administrators or developers.

The large size of Oracle Application Server users did match what I also have seen at our own events, as skewed as our own event obviously will be. The data point I compare to is unlike 4 years ago, at OpenWorld where we would have 100 people per room on Oracle Application Server sessions, now, this year depending on the topic you could see 300-400 people sometimes many more, particularly if the topic was SOA oriented. While this may have been an unusual event - it was an almost overwhelming event in terms of attendance (I believe about 40,000 people!) literally shutting down streets in San Francisco - it was pretty clear there is a huge community of folks asking about and working with Oracle middleware and naturally there is a matching set of jobs out there backed up by this graphic. An Oracle middleware economy so to speak!

One reason I did the breakout above is to show in terms of job opportunity, it appears the bulk of the jobs still fall into knowing the overall product offering versus just the technology. It is one thing to know JSF or EJB, it is another to be successful on a specific application server. Clearly you will be miles ahead knowing the technology, particularly standards based or defacto standards (ala Spring) but employers will frequently hire you on your specific product domain experience (e.g. I know how to cluster Oracle Application Server in a highly available infrastructure, versus I know how to build a servlet that does state replication - two related but different tasks).

Let's dig down in the mess of technologies at the bottom of the above graphic, hidden by the jobs in the server space, so like Rick, we have a better sense of job requirements in the underlying technologies that the upper level application servers support. Here the same thing can be illustrated but I added in JSP, JMS, servlet and EJB to see where these old stalwarts live in the minds of job recruiters:

The interesting thing here is those old fashion baseline technologies of Java EE - JSP (the top orange line -- by far above all others), EJB (purple) and JMS (yellow)- still are the largest job requirements out there beyond these emerging frameworks - they are, so to speak, the meat and potatoes you need as a developer (the SQL of middleware).

Going one level deeper into Rick's analysis, there is absolutely no doubt that Spring, Hiberate and JSF, while the next level down, seem to be emerging into baseline requirements for developers to know for technology jobs. I think it is reasonable to conclude they are the meat and potatoes of the future:

The next one I thought I would check out as EJB 3.0, JPA, OpenJPA, TopLink Essentials (the reference implementation for JPA persistence in the Java EE 5.0 Sun reference implementation as well as the JPA persistence provider in Oracle Application Server). They were hidden in the noise in the above graphic, possibly indicating they are still battling it out for mindshare and job requirements:

The numbers are substantially smaller but it is pretty clear since EJB 3.0 finalized several months ago and JPA has become a recognized term for persistence, there is a clear upswing. I suspect in 6 months to a year - particularly if I judge by the volume of e-mail and customers I get around EJB 3.0/JPA, we will see EJB3.0/JPA merge with the other three technologies - Hibernate, JSF, Spring.

It wouldn't be fair if we didn't do the old fashion .NET versus Java survey so here it is. I never know what is more valid in terms of comparing because recruiters lump languages with runtimes but for reference I did .NET, J2EE, Java, C# and PHP.

My personal conclusion based on reading the job descriptions from this query is that they tend to ask for "Java" when they mean "J2EE" or "Java EE" and it appears ".NET" is a great big catchall for all things Microsoft and perhaps not representative of the equivalent in Java/J2EE. You can make up your own mind and decide what the heck recuiters think when writing job descriptions by looking here ...

To me the reality of .NET versus Java/J2EE is developers have to know both rather than one or the other. Our recent Microsoft Office Interoperability documentation book which focuses on how Oracle Application Server components integrate with and interoperate with Microsoft, I think more closely represents most developers' reality, though clearly many organizations still like to strategically align with one community or the other.

Interested in Hibernate on Oracle Application Server? Check out some of these articles:

Interested in JSF on Oracle Application Server? Check out some of these articles:

Interested in EJB 3.0 and JPA on Oracle Application Server? Check out some of these articles:

Interested in Spring on Oracle Application Server? Check out - many of these articles and how-tos recently arrived also on

No comments: