Rajan Choudhary wrote:
I hope you want to help English speakers as well -
well, I will try ...
SCEA Certification (OCMJEA), after a decade remains valid
Today I received the confirmation of my approval on Oracle Certified Master certification, Java EE 5 Enterprise Architect. This is the end of my search for the main certification in Java technology. I decided to take this opportunity to reflect on the value of professional certifications, especially SCEA, now called OCMJEA (bad acronym).
The search for the certifications was a great incentive to deepen my knowledge in each studied topic. Thus I was being prepared for various situations that were to come. For example, when I passed the SCBCD 5.0, there were no good books on the certification of EJB 3.0. I had to prepare myself with the JSRs. At the same time, in a real project, I had to use those same skills to support important decisions about the architecture of a system. Something similar happened in the SCWCD. I have always refused to study certain details of Servlets and JSP finding them totally useless. However, after the certification, I started to solve more complex problems and understand the internals of frameworks of which, earlier, I used to be a mere consumer.
But now talking about SCEA and its relevance, one criticism voiced about that certification is its focus on technical details to the detriment of other important skills of an architect. I disagree. The scope of SCEA is the architecture of enterprise solutions on the Java platform; in this context it fulfills its role well. Now, based on my experience, I will talk about some personal impressions about this certification.
First, SCEA (OCMJEA) has three phases:
1. An objective test about software architecture, design, and Java EE...
2. The documentation of an architectural solution based on the Java EE platform to a hypothetical problem.
3. An essay about the proposed architectural solution.
View of the problem
Phase 1 tests the fundamental knowledge and enables the candidate to the next steps. Phase 2, this is the show time. You receive the description of the problem without much detail, which creates some uncertainty at first. This situation is very common in real projects. Often, the initial view of a problem is not clear enough. In architectural analysis, much of the requirements are discovered, not just collected. Once we understood the problem, the solution arrives.
At this point, as well as in the real world, we are tempted to lose focus, sometimes thinking only about technology, or being excessively rigorous in relation to details such as UML notation. All these things have value only as far as they help us solve the customer problem. The customer is the guy who's paying you to solve a particular problem. Within enterprises we always have someone to remind us of deadlines. During certification, however, it is our that responsibility. I think many people give up on the phase 2 for this reason. For me it was important set up a schedule to monitor my own progress. This helped me focus on the solution of the problem and leave aside less important things.
Finally, another important point, because it gave me security in the end, was to maintain traceability between the needs of the company (fictitious), the architectural requirements, and proposed solutions. This approach ensures the coverage of the whole problem. As in the real world, each architectural decision should be associated with customer's needs, even if indirectly.
The listing of the major architectural risks was included in the latest version of the certification. In the real world, the critical architectural risks also should be monitored closely.
After this experience, I reinforce not only the SCEA relevance, but also the relevance of any professional certification. Especially when we know enjoy the preparation time, bringing real benefits to our daily lives.