Hiring the phantom Java architect

Do you need a Java architect or a senior developer?

What's the difference between a senior Java developer and a Java architect? One can walk on water and the other can run. Put their resumes side by side, and their skill sets pretty much read the same: J2EE, Struts, Spring, Hibernate, <insert buzz word here>, <insert buzz word here>, etc. Is the difference in the way they code? Or in their years of experience? While at times walking on water may be easier to accomplish than many of the Java tasks we're faced with, the difference between an architect and a developer is breadth of knowledge verses depth of knowledge.

Over the past few months, I can't tell you how many times I have gone into an interview thinking the company, as it had advertised, was looking for an architect, only to arrive and find it really wanted a disciplined developer that followed good programming practices. Nevertheless, I'd cordially sit through the draconian interview—as, more often than not, a developer grilled me— knowing the interview was a waste of my time and theirs. And I'm sure the developer on the other side of the table was thinking, "How can this guy be an architect and not know all of the Spring, Hibernate, and Struts exceptions?"

What many hiring managers fail to realize is that an architect's goal isn't to master the details of existing implementations. Rather, the goal is to glean the workings of various technologies to solve problems, or better yet, find ways to create entirely new implementations. In essence, architecting embodies the core of object-oriented programming: to maximize component reuse.

The discipline of clearly delineating job functions

Aren't the terms architect and developer simply variations of a title? That is to say, shouldn't an architect be willing to get his hands dirty to fill the role of a developer? No!

Architects are often idealized as Java gurus. The reality is they are not gurus. Rather, they are the creative visionaries of an organization's Java future. Think of it like this: A publisher wouldn't hire writers expecting them to fill the role of editors simply because they can write. Construction companies wouldn't employ architects expecting them to lay cement simply because they know how to read blueprints. Well, why should Java architects be expected to traverse the role of a developer simply because they know how to write code?

Sun has clearly differentiated architects from developers by providing two separate exams, the Sun Certified Developers Exam and the Sun Certified Enterprise Architects Exam. How well would you do if you studied all year long for the Architects Exam, honing your skills in object-oriented analysis, object-oriented development, Unified Modeling Language (UML), etc., only to show up and be asked to take the Developers Exam? The only difference would be the exam title, right?

However, let's face the hiring reality of IT. To get more bang for their buck, companies often want to hire a 50-50 architect—in other words, someone who is a 50-percent developer and a 50-percent architect. Undoubtedly, to be a good developer, one must have a solid understanding of the Java architecture. Conversely, to be a good architect, one must also be a skilled developer. Yet when the 50-50 approach is used to select a Java technologist, you end up with a generalist—not a specialist. In the end, this lack of decisiveness ultimately creates a lack of focus within your project.

Compared to other industries, when it comes to the discipline of clearly delineating job functions, software development is relatively immature.

Advantages to clearly defined roles

As we all know, in the software development lifecycle, the more perspectives you have of the problem domain, the more comprehensive and reliable your solution. The advantage to clearly defined roles between developers and architects within an organization is the way they will be able to view, and ultimately, solve problems based on their respective perspective.

To illustrate this point, imagine staring at a tree 50 yards away. When asked to focus on a single leaf on the tree, a developer would innately focus on the leaf's fine-grained details: its shape, color, texture, etc. An architect, on the other hand, would look at the same leaf, but not lose sight of the entire tree. Hence, when it comes to developing software, architects view components as leaves held together by guidelines and best practices, thereby freeing up developers to focus solely on developing the best components possible. In short, a developer's strength is in the ability to dive in and fine tune an existing implementation, such as Java, Enterprise JavaBeans, Hibernate, or C++, to solve a given problem. An architect's strength lies in the ability to develop an implementation to solve a problem's context.

Knowing how to solve a problem's context verses solving the problem itself distinguishes architects from developers. Thus an architect must be adept in object-oriented methodologies, design patterns, and UML, and, more importantly, have the discipline to enforce standardized guidelines while following best practices.

With all of that said, the intent of this article isn't to imply that an architect is more valuable than a developer, or vice versa. On the contrary, they complement one another. The goal is to push the IT industry forward by taking the time to learn the differences between the emerging Java roles. And hopefully now, whether you are a Java technologist or an IT manager seeking to hire one, you will have a better understanding of how and where a Java architect can be utilized within your organization, thereby saving you time and money.

Al Smith Jr. is a Sun-certified Java programmer and architect. He began his career in computers 11 years ago at IBM Global as an implementation consultant. Utilizing his object-oriented analysis and object-oriented development experience, he went on to become the founder of TheJavaArchitect.com. He specializes in the inception and elaboration of J2EE applications. In addition to consulting, Smith teaches Java programming to junior developers and provides mentoring during large-scale Java migrations. He currently resides in Southern California.

Learn more about this topic

This story, "Hiring the phantom Java architect" was originally published by JavaWorld.


Copyright © 2005 IDG Communications, Inc.