Recebi hoje a confirmacao da minha aprovacao na certificacao Oracle Certified Master, Java EE 5 Enterprise Architect. Com isso termino minha busca pelas principais certificacoes profissionais na tecnologia Java. Resolvi aproveitar a ocasiao para refletir sobre o valor das certificacoes profissionais, em especial a SCEA agora chamada OCMJEA (essa sigla e pessima).A busca pelas certificacoes foi um grande incentivo para aprofundar meus conhecimentos em cada um dos topicos estudados. Passei de uma leitura superficial, focada em um problema especifico ou outro, para uma visao geral que me preparou para varias situacoes posteriores. Por exemplo, quando fiz a SCBCD 5.0 ainda nao havia bons livros sobre a certificacao de EJB 3.0 e tive que me preparar atraves das JSRs (especificacoes originais da tecnologia). Na mesma epoca, em um projeto real, precisei usar esses mesmos conhecimentos para apoiar decisoes importantes na arquitetura de um sistema. Algo semelhante aconteceu na SCWCD. Sempre me recusei a estudar certos detalhes de Servlets e JSP por acha-los totalmente inuteis. Estudei obrigado para a certificacao, mas depois colhi frutos podendo solucionar problemas mais complexos e entender o funcionamento de frameworks dos quais, antes, eu era um mero consumidor.Mas falando agora da SCEA e sua relevancia, uma das criticas que ouco e que a certificacao foca muito em detalhes tecnicos da plataforma e que realmente nao testa os conhecimentos de um arquiteto. Discordo. Dentro do seu escopo que e arquitetura de solucoes corporativas na plataforma Java ela cumpre bem o seu papel. Vou citar alguns exemplos baseados na minha experiencia. Primeiramente, a SCEA(OCMJEA) possui tres fases:1. Uma prova objetiva sobre arquitetura de sofware, design, Java EE e etc. 2. O projeto arquitetural de uma solucao na plataforma Java EE para um problema hipotetico3. Uma prova aberta sobre a solucao proposta para o problema da fase 2.Visao do problemaA fase 1 testa os conhecimentos fundamentais e habilita o candidato para as proximas etapas. Na fase 2 e que comeca a diversao para valer. E fornecida uma descricao do problema sem muitos detalhes, o que gera alguma inseguranca no inicio. Esta situacao e muito comum em projetos reais. Muitas vezes, a visao inicial do problema nao e clara o suficiente para pensarmos logo na solucao. Na analise arquitetural, boa parte dos requisitos sao descobertos, nao apenas coletados. Uma vez entendido o problema passamos a solucao.Foco no clienteNeste ponto, assim como no mundo real, somos tentados a perder o foco, seja pensando apenas em tecnologia, ou sendo preciosistas em relacao a detalhes como notacao UML. Todas estas coisas so tem valor na medida em que nos ajudam a solucionar o problema do cliente. O cliente e aquele cara que esta te pagando para resolver um problema concreto. Nas empresas, sempre temos alguem nos lembrando dos prazos. Durante a certificacao, porem, essa responsabilidade e nossa. Acredito que muitas pessoas desistem no meio do caminho da SCEA por este motivo. Para mim foi importante ter definido um cronograma para monitorar meu progresso. Quando percebi que nao saia do lugar, concentrei o foco na solucao DO problema, sem tentar abracar o mundo e ser perfeito em