More than two years ago, I volunteered as a beta tester for the Sun Microsystems Certified Enterprise Architect for J2EE (Java 2 Platform, Enterprise Edition) Technology exam. I looked at the planned syllabus and saw the value in the certification, so I decided to go for it. Four months and a lot of hard work later, I received my certificate and badge in the mail, almost as if I had joined a very select fan club! Was it worth it? In a word, yes. My straightforward goal was certification, but I was pleasantly surprised that the certification process opened my eyes to ideas and approaches I simply hadn't had time to investigate in the hustle and bustle of my day job. I continue to engage with Sun on the exam's content and structure and am currently an examiner for the test. In this article, I share my experiences and also pick the brain of Mark Cade, lead developer of Sun's J2EE architect exam. If you want to become a Sun-certified J2EE architect, read on.
Why get certified?
Simply put, any certification is only as good as the awarding body. In our case, the awarding body is Sun, the company behind J2EE. That makes the certification cast iron in my book. Many other certifications are available from various Java vendors, but Sun wants to certify and approve architects for the J2EE platform, not for application server X, Y, or Z.
In general, however, the value of certification—whether from a university or a company—is often debated in our industry. I don't need a certificate to become a practicing software engineer either in the US or in Europe, unlike most other professions. Great, say some. Our unique hacker culture is changing the way the world works. We live or die by our coding skills, not by some dried-up institution's opinion of us. Boo, say others. Fly-by-night coders produce nonstandard code and undocumented, inflexible systems that are often not robust enough.
Both camps have valid arguments. But my opinion is clear: I see the value in industry-sponsored certifications. And all other things being equal, I rate a certified J2EE architect more highly than an uncertified architect. There are far more weak uncertified architects than weak Sun-certified architects.
What the exam is
Let's be blunt: The J2EE architect certification exam is a very good way to differentiate your resume. Candidates who continually ensure they are up to speed on the latest technologies and hold pivotal certifications in their chosen technologies are well-motivated people who add value to their companies, both as individuals and as team players. As Sun's Cade says, "Certification allows you to get your foot in the door. For example, if recruiters look at two candidates for an architect position, and one has the certification and the other does not, who do you think they are going to consider first?"
It can actually be fun working towards certification. Have you ever wanted to investigate a particular section of Unified Modeling Language (UML) or the Enterprise JavaBeans (EJB) specification, or wanted to refresh on a design pattern you haven't used in a while? I used my certification revision time to make myself a better architect. For example, Part 2 let me evaluate UML modeling tools I had been itching to try, while Part 1 gave me the opportunity to bone up on enterprise integration aspects I hadn't used before, like screen scraping and legacy integration. J2EE certification definitely isn't easy—it's hard work. But if you like being a J2EE architect, you will enjoy the certification process. There is a real feeling of achievement when you successfully pass the exam.
What the exam isn't
I asked Cade what the certification couldn't test. His reply in a nutshell: "Certification is not a replacement for experience." As Yoda might say, "one exam does not an architect make." Don't try and bootstrap yourself into a J2EE architect certification if you don't have the skill set to back it up. First, you will struggle to pass the exam, and second, being a J2EE architect is an applied skill; if you don't have the know-how, you will be quickly exposed.
Another point is that the architect exam is subtly different from Sun's other Java certifications. "The architect exam is more abstract, just as architecture is. The programmer exams test whether a person understands the language. The developer exam tests whether a person can apply the language to solve a problem. And the architect exam tests whether a person can use his knowledge to architect a solution that a developer could implement," Cade explains.
Typical candidate profile
The typical successful candidate falls into two main groups: strong senior engineers who are already architects in all but name and well-established architects, possibly from other technology disciplines, who use the architect certification to cross-train to J2EE, or simply brush up on their J2EE expertise.
Java skills will not be an issue for a successful candidate. Rather, the challenge is to show you can devise and communicate a robust and correct J2EE software design for a given problem. Other important skills include the ability to understand that there isn't always a perfect answer for every given problem, and to coherently and cogently defend your proposed design to an examiner.
The exam is split into three sections, each designed to test a different aspect of your skills. Figure 1 illustrates the required steps to become a Sun-certified J2EE architect.
Part 1 consists of 48 multiple-choice questions, covering all aspects of enterprise application design with a strong focus on the EJB specification and architecture. Part 1 tests you on topics from design patterns to the EJB specification's core interfaces. You need to know EJB inside and out—the different types, their lifecycles. You must understand EJB containers and potential EJB pitfalls. You also need a strong grasp of other constituent J2EE technologies, such as JavaServer Pages (JSP), servlets, Java Database Connectivity (JDBC), and XML support. Learn the main design patterns and their groupings; recognize them from their UML "signatures." Business-to-business (B2B) architecture questions might also figure prominently.
You must pass Part 1 before moving to Part 2.
Part 2 is the heart of the exam. In this section, candidates must submit their J2EE-based solutions for a given business scenario. For obvious reasons, I cannot disclose the actual business scenarios used, suffice it to say they contain both B2C (business-to-consumer) and B2B aspects. There isn't much prep work that can be done here; you must simply use your practical skills to devise a J2EE-based solution. Clear communication is crucial; you must convince the examiner you know what you're doing. Don't assume anything. All delivered diagrams must be UML compliant.
In Part 3, candidates must answer a series of questions about their Part 2 submissions. These questions examine your ability to analyze your design objectively and also ensure that you have in-depth knowledge of your proposed system's key aspects, including maintainability, performance, and scalability. Your responses to these questions will be available to the same examiner who corrects your Part 2 submission, and he will cross-reference supplied answers with the submitted solution to evaluate your essay answers.
Let's get down to the brass tacks. What advice can I offer to prospective candidates? Here are the top mistakes I've seen in Part 2 and Part 3 submissions. I do not focus on Part 1, as it is a straightforward multiple-choice section; you either know the correct answers or you don't. Figure 2 captures the key aspects of both successful and unsuccessful exam submissions, based on direct examiner feedback since the J2EE architect exam launched.
Top submission mistakes
- Completely missing the exam's point. The exam is designed to test your skills as a J2EE architect. All your effort should focus on solving the given business problem and not be mired in the nuts and bolts of esoteric J2EE issues. Sure, feel free to address these points too, but don't allow your business solution to suffer as a result.
- Sloppy submissions. Sun expects people to spend between 30 to 40 hours working on the exam. With that amount of time, your submissions should not contain typos, unclear UML diagrams, incomplete arguments/justifications, and missing deliverables. Take pride in your solution and make sure it's your best effort.
- Overly complex submissions. Some candidates go into overdrive and turn a well-gated enterprise system into the next Amazon.com. Step back and ensure your submission is as detailed as possible, but not overly so. Superfluous content detracts from the overall standard and makes it harder for your examiner to award marks.
- Incomplete/inadequate answers for Part 3. Many candidates simply don't put enough effort into Part 3 (the essay questions). Make sure you provide complete answers and back them up with references to specific parts of your proposed architecture. And please note, stating your application is great because it is J2EE-based does not constitute an adequate defense of standard system characteristics, such as scalability, maintainability, and performance.
Finally, if you fail the exam, learn from your mistakes. If you believe you have the right profile and that you failed because of bad exam technique or preparation, put it behind you and regroup. All submissions receive a breakdown of where marks have been awarded and deducted. Use this to identify your submission's weaknesses. Once you address these weaknesses, then resubmit.
On the flipside, let's look at the common characteristics of successful submissions.
Successful submission characteristics
- Correct preparation and adequate time spent on submissions. Successful candidates understand what they are asked to provide and then do it. It's that simple. A good technique for Part 2 is to continually ask yourself if you're working on what you should be. Remain disciplined. Understand the questions and stay on track.
- Clear, succinct submissions. Successful submissions can vary in length, but the content determines if you pass or fail. A useful tip is to play devil's advocate with each section of your submission. Where are the weak points? If you hadn't written it would you understand it? Ask a colleague to review your solution before submitting it. It's amazing what a second pair of eyes can catch.
With regard to Part 2, don't get hung up on what modeling tool you use to generate the specified UML deliverables. Clarity and correctness should be your main goals. Any tool of choice is fine as long as you stick with the specified deliverables (e.g., providing a main index.html page).
Reflecting the progress J2EE and its constituent technologies continue to make, the architect exam itself is also under revision. The updated exam will cover J2EE 1.4, J2EE design patterns, the Java Connector Architecture (JCA), and design methodologies such as the Rational Unified Process (RUP) and extreme programming (XP). Other planned extensions to the current format include a feedback mechanism to allow examiners to query candidates about specific points of their architecture.
The revamped exam will not involve face-to-face interviews with prospective candidates. As Cade says, "Much of being an architect is being able to communicate your ideas written and verbally. We can capture the written part of the communication, but we cannot assess candidates on their verbal capabilities. This is why employers must have a thorough interview process."
An interesting phenomenon is that solutions submitted for Part 2 over the last year have changed even though the exam itself has not. The advent of Web services and a move towards a more modular, services-driven approach to architecture in general reflects in the types of solutions candidates submit. That represents to me one of the architect exam's real values. It continues to remain relevant even as the preferred techniques and underlying technologies morph and mature.
Have your say
Hopefully, you now have a clearer sense of Sun's J2EE architect certification and understand why I believe it is well worth pursuing. It's hard work, but the reward is that upon successful completion, you will be a better architect. The architect exam is currently being revised to keep pace with the J2EE platform, and Sun welcomes your input on the exam's content and structure.
If you have any ideas about how to improve the exam, I'd love to hear them. Use the JavaWorld feedback form (see Resources) to send us your thoughts. It's a great way to help influence the next phase of the architect certification process.
The Resources section below contains useful links to get you started. The exam is no substitute for hands-on architectural experience, but it's a great complement to that experience, especially if you embrace the certification work as an opportunity to fill gaps in your knowledge. If you're currently working towards the exam, good luck! If you're not, why aren't you?
Learn more about this topic
- The Sun training Webpage, the best place to find information about Sun's certification initiatives
- Mark Cade's co-written book on the J2EE architect exam, "Sun Certified Enterprise Architect for J2EE Technology Study Guide," (Prentice Hall PTR, 2002; ISBN0130449164) is required reading for anyone contemplating taking the exam
- Yahoo user group about the SCEA J2EE architect exam
- Let us know what you think about the Sun J2EE architect certification via the JavaWorld feedback form
- Get to know the EJB specification thoroughly
- Sun's J2EE homepage provides an entry point for locating information on all constituent J2EE technologies
- The infamous Gang of Four design patterns
- Check out Humphrey Sheil's Weblog for more technology musings and details about his other JavaWorld articles
- Browse the Java 2 Platform, Enterprise Edition (J2EE) section of JavaWorld's Topical Index
- Visit the Certification and Training section of JavaWorld's Topical Index
- Chat about J2EE in JavaWorld's Enterprise Java discussion
- Sign up for JavaWorld's free weekly Enterprise Java email newsletter
- You'll find a wealth of IT-related articles from our sister publications at IDG.net