Question

I want to be a J2EE architect in future.

I started learning new technologies and covered some Frameworks like Spring, Struts and Hibernate. EJBs also I’ve worked in the past (way back in 2005).

Things, I did not work much are

• Front end technologies (AJAX, FLEX, FLASH etc)
• Performance improvement practices
• Recent changes in EJBs/JPA
• JCA
• JMS
• Web Services
• Best tools that can be used in SDLC..(ex: ANT/Hudson for build, JMeter for testing, PMD for code review etc.)

I was planning to come out with a plan to cover these technologies and some decent tools that can be handy while development.

My problem is that each of the technologies has got enough depth to engage me for a month (or more), because I need to work on my regular work along with learning these technologies.

I recently started with AJAX..spent 3-4 days going through different tool kits for AJAX like DOJO, JQuery etc. At the end of my study I got fair idea of how AJAX works, but I do not know if that knowledge completes my study? Then I looked in some tools for CI.. spent 3-4 days with Hudson and ANT..got decent idea about how it works, but again not sure of this knowledge is sufficient to complete my study. Each such things has got enough depth and If I go deeper in them .. it might take a month or even more. I have plan to complete SCEA in next 6 months, but without knowing these things I believe SCEA will not be of any benefit.

My question is,

1. Is there some problem with my approach or everybody face this challenge?
2. When I start knowing about a technology, at the end of it.. what should be my outcome? (Knowing about the technology is an obvious answer, but do you keep any list of points that you try to find out while working on the technologies?)

Thank you for reading,

Answer 1

One of the problems with becoming proficient in J2EE is that it’s a “moving target” – There are new technologies all the time, the APIs are constantly changing, and in addition to knowing the Sun APIs, you have to be aware of a lot of third-party tools that are now almost an integral part of the stack. Like Hibernate, Spring, Hadoop, and all those things.

A J2EE resume or job listing is often recognizable by the Buzzword Soup which often spans lines over lines over lines.

For novices, this brings three risks:
– Learning stale technologies.
– Learning specific vendor solutions without understanding the alternatives and the principles behind them.
– You can learn a lot of tools but never know how to mix them together.
– Never getting a chance to practice programming and developing a “programmer instinct”.

You didn’t mention much about your experience, so it is not clear how much core Java experience you have or how comfortable you are in non-architecting tasks.

I would personally encourage you to make sure you’re really good at these, and then start integrating newer J2EE technologies into your day-to-day coding, rather than merely studying a lot of tool descriptions without actually using them in context. IMHO, that’s the only way to build knowledge and to really have an architectural sense. Just make sure to keep current, and be willing to take risks and try new technologies if you can justify it to yourself over what you are currently using.

Let’s take AJAX for example or a messaging architecture. Try to write down a description of the differences between two vendors or frameworks. Now, try to use the low-level constructs like XmlRpc or GWT or servlets for a while, before you focus on mastering a supposed all-in-one-solution. Similarly, play with sockets or the JMS APIs before you rely on a messaging architecture, etc. Play a little with SQL before you hit hibernate or other ORMs. Now see if you can make a more compelling argument for the differences between frameworks.

I can’t tell you how many J2EE architects I know who failed job interviews because they couldn’t solve a simple FizzBuzz problem.