Why Java developers should learn Alfresco

I've got a heck of a recruiting assignment on my hands, one of my clients needs extremely bright JAVA developers to join their Enterprise Content Management solutions team. I'm talking about folks who have worked with Java 6 for the past few years, who get excited about design patterns, TreeMaps and maybe even Open Source. My client wants to train them to become Alfresco developers.

"What a great opportunity," those in the ECM space tell me.

"I'm interested," say the Documentum developers I speak to.

But my client isn't interested in most of them. "Documentum people don't know Java, they know Documentum JAVA," is what the say when I present them.

"Your client may be right," say some of the Documentum gurus I mention this to. "The API does a lot of the JAVA work for you."

So that leaves me recruiting well employed, well paid JAVA developers who have barely heard of  ECM, WCM, Alfresco, Documentum, Open Text, and explaining to them that there's an exciting future in the ECM/Alfresco space.

Now let me be clear, I'm not complaining and I'm not lazy. I get paid for identifying top talent and helping them see that my clients have better opportunities for them than their current employers. And I almost never work with a client companies who aren't growing rapidly, who don't offer attractive compensation packages, and who aren't doing exciting things.

My challenge is illustrating why a future with Alfresco  (which is an Open Source ECM technology)is brighter than sticking with just plain JAVA.

And sometimes the best way to make a point, is to do so graphically.

The folks at Indeed.com (an aggregator of job posts) have made this kind of easy. Where is there more growth? Plain JAVA or Open Source, Alfresco and ECM? And, oh, for those Documentum developers who are open to making a change, I've included a chart so you can see the job growth in your space.

Below, from left to right, here's the demand for JAVA, Enterprise Content Management, Alfresco, Open Source, and Documentum developers  from 2005 to present.

Comments

[shiningarts]

Java Design Patterns, TreeMaps, and Open Source are not new ways to develop applications. They have been around for quite a while and I have worked with them in the past. In some ways, these tools would be an impediment in adjusting to the new way of the computing. Ironically, although arcane, the old API is much more in line with the new Mashable and Cloud.

Philosophically, as a consuming developer not a software vendor these days, we don’t need to go out there in the field to gather animals and slaughter them to prepare the meal. We go to the grocery store buy the packaged meat to cook. It is the vendor’s tasks to prepare the animals. Java, in general, is an excellent tool to develop application, but working with some Open Source applications is like going out there on the prairie to catch a buffalo to prepare your dinner!

James Gosling, Java founder who now works for Oracle, said that it's not about generating Web pages, it's about building rich graphical user interfaces on the desktop. Someday maybe we'll find out what exactly it's really for, if it isn't stillborn! It appears that he is admitting the reality that Java is not a panecea for every application. But, Mashables that run as graphical user interfaces are going to be the future. The jury is still out as to whether the brand new Oracle Fusion framework will enable this in the future.

Besides, CMS architecture started from keeping the documents and metadata in database together. Some current architecture like SharePoint still keeps them all in the database. Other architecture, like Documentum, keeps the two in separate location: documents in filestore but metadata in database. In order to stay abreast with the new ways of computing, documents and metadata should not use a database at all. They need to be using objectstore (instead of filestore) together as metadata as a part of a document in some way without using database. Again, who will do this colossal shift in computing better: EMC or Alfresco?

[doQuent]

Such stereotyping (Documentum + Java = bad)could be applied to average developers with any skill-set. A bright developer (Java or not) does not lose his/her shine by also possessing Documentum knowledge. Those who create products/tools for any platform (including Documentum) need to deal with most of the same development concerns that they would elsewhere. Alfresco was created by a team with mostly Documentum background. I would prefer a good developer with any ECM experience (Documentum or otherwise) if I were in your client's place.

From my perspective, there are more similarities between Alfresco and Documentum than there are differences. I have been working with Documentum for about 7 years now and I started trying out Alfresco about 2 years ago. My ECM knowledge actually helped me pick up Alfresco quite comfortably and it also helps me anticipate issues/challenges because not all ECM concerns necessarily change with the implementation platform.

[Virginia]

Thanks to both of you for your comments. I'm not suggesting that Documentum + JAVA=BAD should be the rule when it comes to hiring Alfresco developers, I'm just surprised that three of my client managers perceive it to be so. From their POV Documentum developers aren't strong in JAVA.

I have, by the way, asked a number of decent Documentum developers the same JAVA technical questions I ask JAVA developers, and the answers I commonly get are "I don't use that." "The API does that, so I don't know."

Would this change if I were looking for architects or business analysts to work in Alfresco environments? I'll let you know soon.

All that being said, I'll be running a poll on Linkedin asking what skill sets an aspiring Alfresco professionals should have.

[Amanda Boyd]

I would pose the argument that you could make this argument about any specific technology that uses Java, not just Alfresco. It applies to the other CMS products, portal technologies, SAP, CRM, etc. Adding a vertical on top of being just a plain ole programmer will always increase your earning potential.

[Virginia]

Amanda,

I agree with you in theory, but my experience ,at this moment, is that plain Java developers are being hired for more than their Documentum/Java counterparts. This is a supply and demand issue and for IT professionals, being exceptionally qualified in an area where demand is diminished, is problematic if you want your earnings to keep growing. It is also a problem if, for example, you want to move to a technology such as Alfresco and you're not as strong in Java as a pure Java developer.

[Amanda Boyd]

Good to know. Guess I'll go sign up for that Sharepoint class after all!

Glad to have found your blog. Interesting to see things from your unique perspective.

[Moshe]

I've seen DFC programmers who didn't understand something as simple as inheritance. But I guess that's why there have interviews.

Also, the different scales on the some of the charts could lead to inaccurate conclusions.

[Ivo Costa]

Nice article, as an Alfresco developer my-self for 2 years I understand that it was a little hard to get into Alfresco's architecture (but I really didn't have any experience on ECM), good thing I had a great Java teacher at university.

As for the "API does that"... Samething can be applied to Alfresco... API does a lot of things... I guess that the fact of beeing "open-source" is what makes the difference.

Then there are all the technologies used by Alfresco, Spring, Hibernate, jPDL, Lucene, etc. ... and now iBatis too... I ended up learning more than just Alfresco.

But basicly half the code I produce I get the ideias from Alfresco's source it-self. There are a lot of things there that make you learn how to code. Other things... well... you get it (It could just be me... "not perfect" comes to mind).

Anyway... I think that whatever the product, you would always have specific details that only belong to that product.

And "we" as developers should not allow our-selves to get stuck on only a way of "coding" or technology and try to be has dynamic as possible... But I do understand that it can be dificult some times.