Your comments are reflections of your thoughts. They are your opinions, but I'm afraid they are not facts. Here are my rebuttals to your points.
1) SCEA has no experience requirements. This according to me is very bad. The converse is not necessarily true either. PMP has very stringent experience requirements however, I have come across project managers who cannot even write a single document without spelling errors. Adding experience requirements does not always result in a better quality of certification. Unlike PMP where experience is required to be grouped into functional( and well accepted) PM areas, the nature of a typical J2EE Architect role and the breadth of activities he/she performs makes it harder to enumerate the experience in temrs of a finite set of functions performed. Although experience is not an explicit requirement, solution to Part II often reflects upon the individual's exposure to real architecture. It is here that many come to realize that they ended up in the wrong place.
Part 1 is not tough. If one mugs up all questions in various mock exams, part 1 is a cake walk. Very few people admit that part I is difficult, but many feel it is not easy. I have participated and organized SCEA study groups in the past and the breadth of objectives covered in part I is often intimidating to many people. Since the test comes in three parts, Part I is like a qualifying round. Easy/hard is very subjective, but Sun thinks that if you cannot crack it, then you are not ready to move on to the next levels. Sure one can memorize every single mock test out there and pass the test fairly easily, but many a such later get stuck with the assignment since it requires more skills - real skills that one can draw only from their experience.
3) Part 2 Assignment is open secret. I hate to say this, but it is a truth that *we* are all responsible for making it an open secret. Every test taker has an obligation to ensure that the details are not revealed. But in practice, it is hard to enforce. Sun made SCJP tougher by randomly selecting questions from a larger pool so that test administered to each individual is unique. Two years later, we now know that every single question in the pool has been shared in public by test takers. Its a cat and mouse race.
4) Dont try to build a quick critical mass Training and certification are avenues of revenue generation for Sun. It is how they make money. Its all about bottom line and they like it when more people take the test because they get more money. It is that simple. Have you seen how many *new* certifications came out of Sun in the last 3-4years?
5) "Frog-in-the-well" view of technology : Encourage the architects choose solutions that will challenge the known facts. Let them use any platform, not J2EE alone. Let them conceptualize light weight architectures, J2EE, .Net, SOA, Web Servcies, OR Mapping ...etc etc. That list never ends. I have always told folks that certification is a piece of paper. It does not and should not limit your skills to ones that were validated during the process. As an architect, you are required to understand the broader aspects , and the newer technologies. You are an architect first, and then a certified architect later. Since it is a
Sun certified test, they would like you to apply, use and promote technologies advocated and sold by Sun. That's why they don't test your .NET skills. In fact, your solution is required to be based on open standards and Java technology. It is explicitly written in the assignment document. And lets not forget that the best and elegant solutions to a problem are often the simplest solutions. The flight reservation system is a moderately complex assignment. However, the solution can be built using several simple, but collaborating components. Many agree with me that it is rather hard to achive simplicity and it is very easy to come up with a bloated design. With all the
patterns, frameworks, tools and technologies out there, we tend to stereotype the solution to every single problem and start with an extremely complicated design. Although you are not graded on the simplicity of your assignment, but it becomes a point of realization for many test takers half way through the assignment. They realize that their design is complex, often unnecessarily complex, but they find it hard to make it simpler. In real life, if you are an architect building real systems, balancing the priorities, making tradeoffs and striving for a lean and mean architecture( in terms of cost, time to market, application footprint, hardware requirements etc) is your overarching mission. To do that, you need to learn to think creatively. Solving the assignment will help you measure your own maturity. Sun is not interested in that, but
you should be.
6) Part III exam is routine. I agree, to a certain extent. There are two objectives to part III. One is nonrepudiation - they would like to verify that *you* actually did the assignment. They do that by asking you to write narrative answers and correlating your narrations with the assignemnts you submitted. The second goal of part III ( IMHO ) is to test your written skills. Sure you can write a three inch thick architecture document, but can you explain specific aspects of your architecture with precision and brevity? Unlike *any* other Sun tests that I am aware of, part III of SCEA requires you to write narrative answers. Although the assessment can be subjective, I believe the evaluator can reduce the grades based on your Part III answers. This is one of the reasons why we see a few folks who fail the test, despite submitting a functionally valid solution to the assignment. My recommendation is not to take part III lightly. It is the icing on the cake, small but very important.
In summary, it is very hard for Sun to test every single aspect of being an architect. They verify the minimals and assume that the candidate understands the importance of other *required* skills and invests his/her own time to groom those skills. A successful architect is not only technically well versed with the broad range of topics, but knows how to present them. He/she should be a good writer, a good speaker, applies moderation, understands the tradeoffs, invests time to understand the business domain, acts as a patient diplomat, safeguards the stakeholder's charter, helps achive ROI, increases bottomline, helps the company maintain a competitive advantage, defines strategy, plans for growth and at the time of need, rolls up his sleeve, pulls up the
IDE and debugs the code. This is not an exhaustive list, but it should give you an idea how comprehensive the test need to be to evaluate and accredit each of these skills. Every test taker should introspect their abilities during and even beyond the process of certification to measure their level of ability to actually perfrom these activities in real life. Just like every person on the road who passes the driving test isn't a good driver, every certified SCEA is not a good architect.
