Sun Certified Enterprise Architect

I recently completed Sun's "Sun Certified Enterprise Architect for Java 2 platform, Enterprise Edition Technology" certification. There are lots of online resources for this certification, so I am not going to provide an in-depth description of what is involved. However I did learn a few things along the way which might be of interest.

The certification is in three parts where Part I is a multi choice exam, Part II is a project and Part III is an essay exam. Part III is essentially just a confirmation that you are the person who did the project. Part I is a bit of a pick and mix across various enterprise architecture topics. By and large it takes a wide and shallow approach rather than a narrow but deep approach. Thus you really need superficial knowledge of the topics in the syllabus rather than in-depth hands-on knowledge.

The project in part II requires you to create an architecture and high-level design for an enterprise application. Some requirements are provided for the application, and obviously the architecture needs to be J2EE-based (more of this below) but otherwise you have pretty much free reign over how the application should be structured.

One of the good things about the project is that the requirements are deliberately vague, inconsistent and misleading. I say this is good, because in my experience it is an accurate reflection of reality. Of course normally such issues would be resolved by talking to the requirements team etc but for the project you just need to provide an overall interpretation of the requirements that makes sense.

Even though I have worked as an architect for several years now, the thing that really dawned on me while doing the project, was something that has also become apparent for me in my current day job: an architecture is a function of the underlying requirements and the design decisions made along the way. Without either of these it becomes very difficult to assess the quality of the architecture or even maintain the architecture. While it is usual to have the requirements documented in some way (either as a formal requirements document or in the form of use cases) it is less usual to include a complete list of the design decisions made. And yet, without them, any architecture expressed as say a UML model has very limited value. Architectural models are intended for communication (the "what" of the system) but without the "why" how can you say that the "what" makes any sense at all?

Since this is a Sun certification, the architecture has to be J2EE based. But what does this actually mean? I took a fairly conservative approach using the model 2 design pattern with various kinds of EJB. Would I have done that for a real application? Probably not; I would most likely use Spring and Hibernate, or even a JDO persistence layer. I could of course have tried that in my project, but I was more interested in getting the certificate than having an argument with an assessor about the validity of my solution. Does that observation devalue the certification? I don't think so; there are situations where the heavyweight canonical Java blueprints approach is appropriate so there is certainly value to be gained in understanding how to apply this approach.

Now that I have completed this, I am going to go over to the dark side and start looking at .Net...