Marco Mendes´s Blog

Gosto do título desta frase, que remonta ao inglês arcaico do século XVI (”Byrdes of on kynde and color flok and flye allwayes together”) e que metaforicamente diz que pessoas com interesses comuns se juntam e permanecem juntas em suas atividades.

Tive a chance de acompanhar dois interessantes eventos de comunidades esta semana (SUN Tech Days - Capítulo MG e o Primeiro Encontro de Comunidades Microsoft de Minas Gerais) e presenciar como redes sociais físicas podem potencializar e criar valor único para todos os seus participantes

O primeiro evento foi organizado pelo MGJUG, comunidade de usuários Java de Minas Gerais. Embora o evento tenha deixado a desejar no seu número de participantes, tivemos a oportunidade de acompanhar três boas palestras em temas como SOA e Java Mobile. Em particular, a SUN divulgou o seu programa de parceria acadêmica que fornece benefícios bem interessantes a alunos das faculdades credenciadas.

O segundo evento foi um encontro para fomentar a criação de comunidades ligadas a temas Microsoft (tecnologias e produtos). Atualmente já existem algumas comunidades em Minas Gerais como por exemplo os .NET Raptors ou o CanalSharePoint. O evento propôs a criação de diversas comunidades que terão espaço permanente no portal de redes sociais do Mundo IT, do Yuri Gitahy. Inicialmente as comunidades de BI, Gerência de Projetos, InfraEstrutura e Arquitetura de Software serão criadas no mundo IT. Impossível não citar também as excelentes palestras e depoimentos do Ricardo Guerra (coordenador regional da INETA - organismo responsável por fomento às comunidades de desenvolvimento Microsoft) e também do Marco Aurélio Peres (Coordenador do grupo de SharePoint MG) , entre vários outros, que mostraram o quão bem organizada a Microsoft é no fomento a programas de parcerias e comunidades. A quantidade e qualidade destes programas é mais um aspecto invejável (no bom sentido da palavra invidia) e que deveria ser copiado por comunidades open-source e empresas como a IBM, SUN ou Oracle.

A mensagem é simples. Se você tem algum interesse, busque comunidades para potencializar o seu interesse, compartilhar experiências e aprender com os nossos amigos de trabalho. Afinal, como diz um outro ditado - “Nenhum de nós é melhor que todos nós”.

Tive a sorte de poder acompanhar e trabalhar com Java desde o começo da linguagem, em 1995. Naquela época, o papel do arquiteto de software era algo praticamente inexistente no Brasil e a menção a estes termos era distante e mencionado por pessoas como Grady Booch, Bertrand Meyer, Erich Gamma, Dana Bredenmeyer, Paul Clements e outros visionários. Desde o começo do século XXI, entretanto, a figura do arquiteto de software começou a se tornar popular no Brasil e em Belo Horizonte. Três fatores que ajudaram neste espalhamento foram o processo unificado (UP), a plataforma Java e a certificação SUN SCEA.

O processo unificado (UP), em minha visão, teve uma importância ímpar no espalhamento da figura do arquiteto. Isso é claro em um livro chave de 1995 chamado Object Solutions, de Grady Booch. Por o processo unificado (e suas derivações como o AUP, RUP ou EUP) ser um processo dirigido por cenários arquiteturais, vários gerentes e várias empresas começaram a entender a importância da figura do arquiteto. Hoje, 2008, toda fábrica de software de porte no Brasil possui algum arquiteto de software em seu corpo de profissionais.

A plataforma Java, por sua grande inovação e grande complexidade exigia também um outro tipo de papel além do clássico programador (hacker) no sentido original e bom desta palavra - sem nenhuma relação com os crackers.

A certificação SUN Java Certified Enterprise Architect também teve um papel chave para que a figura do arquiteto fosse conhecido. Isso certamente foi bom. Isso reconhecou a nossa profissão no mundo Java e nos valorizou profissionalmente. Entretanto, o objeto deste blog é avaliar o quão fraca são as certificações das empresas “Java” de mercado e constatar (heresia!?) que a certificação mais completa de arquitetura de mercado é de uma empresa que não pratica Java.

A certificação Java SCEA certamente foi muito bem construída e muito trabalho sério e competente foi colocado ali. Ela mede, sem dúvida, o nosso conhecimento de Java e aspectos de design de Java EE, APIs Java EE e os Core Java EE Patterns. Entretanto, aos analisarmos os seus objetivos vemos que diversas habilidades de um arquiteto de software não são trabalhados.

Alguns destes aspectos incluem:

• Experiência prática. Todos sabemos que um arquiteto Java que não tem uma vasta experiência prática de projetos (medido em milhares de horas como desenvolvedor e líder técnico) é igual a uma nota de 3 reais.
• Habilidades de liderança. A principal característica de um arquiteto é a capacidade de estabelecer autoridade moral dentro de um time para conseguir transmitir boas práticas e criar uma visão arquitetural e uma arquitetura executável adequada para o projeto.
• Compreensão de aspectos de negócios. Um arquiteto deve conhecer sobre arquiteturas de negócio e saber avaliar requisitos de negócio para saber como a sua solução técnica irá realizar estes aspectos.
• Habilidades de gestão de riscos técnicos. Fazer uma arquitetura é, em boa parte, gerir e mitigar riscos técnicos.
• Conhecimento lateral de tecnologias. Um arquiteto Java deve conhecer (mesmo que superficialmente) outras tecnologias além de Java (ex: Estratégias de EAI, Protocolos de EDI, Plataformas Altas, Bancos de Dados, Sistemas de Messageria, Sistemas de Orquestração de Processos, Ferramentas de BI, Portais, CRMs, ERPs, Sistemas Especialistas para o negócio sendo modelado, Usabilidade, Segurança da Informação, Testes de Desempenho, Planejamento de Capacidade, Processos de Software, Metodologias Ágeis, Redes, BPM, SOA, ITIL, Six Sigma e COBIT).
• Forte conhecimento de métodos arquiteturais (ex: SEI ATAM, RUP 4+1, ARID, FURPS+, ISO 9126).
• Arquiteturas corporativas. (ex: EABOK, TOGAF ou Zachman Framework).

As certificações com título de arquiteto da IBM e BEA, entre outras que observo, medem conhecimentos semelhantes à certificação de Java EE da SUN. Elas pecam, novamente, por não avaliar alguns dos aspectos citados acima.

Tentarei explicar aqui porquê o programa de certificação de arquitetura da Microsoft é tão rico e mais apropriado para alguém que queira trabalhar com arquitetura de software.

• Ele é um programa e não uma prova. Esta certificação é um processo com um tutor do núcleo de arquitetura da Microsoft que culmina na defesa de um projeto do mundo real perante uma banca para a avaliação das habilidades, conhecimentos e atitudes do candidato.
• As principais competências exigidas e avaliadas são (nesta ordem) - Forte conhecimento do negócio, Pensamento Inovador e Estratégico, Capacidade de Investigar Novas Tecnologias, Conhecimento de Frameworks Arquitetônicos e Melhores Práticas, Capacidade de Usar e Criticar Frameworks, Capacidade de Atingir Rápida Proficiência em Qualquer Tecnologia e Capacidade de Trabalhar com Informações Incompletas,

Como curiosidade, em todo o texto detalhado das competências exigidas por esta certificação, a palavra C# não é mencionada uma única vez. A palavra “Java EE” é citada uma vez! Uma outra curiosidade é que a primeira característica citada nesta página chama-se: Liderança.

Infelizmente, esta certificação (MCA) é muito cara (pelo menos para mim!) e requer a defesa em território americano. Talvez não por acaso existam somente 90 pessoas no mundo com esta certificação. Obviamente, esta certificação não é perfeita. Nenhuma certificação o é, mas ela consegue medir mais adequadamente, em minha modesta opinião, o que esperamos de um arquiteto de software em um projeto de TI.

Gostaria que a SUN, a IBM ou mesmo a Microsoft tivessem uma certificação como essa sendo executada em terrítório Brasileiro, com preços mais acessíveis. Até lá, é muito importante ter cuidado com “arquitetos de papel” que habitam o nosso mercado com suas certificações reluzentes.

Uma nota final. Para quem ficou interessado no programa da Microsoft (que inclui também 4 semanas obrigatórias de treinamento em Redmond), segue o link com mais informações.

É fato notório para a comunidade de TI Brasileira o uso das soluções JBOSS para o desenvolvimento de aplicações corporativas basadas em Java. A ausência de um reconhecimento formal, entretanto, gerava questionamento por diversos decisores sobre a maturidade desta solução. Uma notícia recente, entretanto, lança o devido reconhecimento técnico e mercadológico desta solução.

O JBOSS AS figura no Gartner Magic Quadrant como um membro do quadrante líder, conforme mostrado na figura abaixo.

.

Vejo esta análise de forma similar as análises realizadas pelo grupos de investimento internacionais, como o Standard and Poors, a respeito da maturidade da economia Brasileira. A análise, por si só, nada muda na solução JBOSS AS, mas traz possibilidade de adoção da solução em contextos onde esta hipótese nao caberia por falta de respaldo de institutos de renome como o Gartner.

Apesar disso, o grupo JBOSS ainda carece de um modelo de serviço e suporte mais presente no Brasil para que possa enfrentar definitivamente os seus grandes concorrentes (BEA, IBM, Oracle e Microsoft) no disputado mercado de servidores de aplicação. Mais informações sobre esta análise podem ser encontradas no relatório do Gartner, disponível aqui.

O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimento de soluções de software dentro da Microsoft e também para os milhares de clientes e parceiros da Microsoft em todo o mundo.

A disseminação deste método, agora na versão 4.0 no Visual Studio 2005, normalmente induz as pessoas a compará-lo com outros “métodos” da indústria, como o RUP, CMMI ou XP, entre outros. É importante entender, entretanto, o que são estes elementos antes de compará-los.

O MSF, por exemplo, não é um processo de software (de acordo com a própria Microsoft). Ao invés, o MSF é um conjunto de boas práticas provadas em projetos da Microsoft e em seus parceiros e clientes. Por exemplo, a MSF é agnóstica do uso de técnicas de análise essencial ou análise orientada por objetos ou do uso da UML ou outra linguagem de notação. A MSF pode ser rapidamente entendida através de seus oito princípios fundamentais, que são:

1. Manter a comunicação aberta.

   “Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn’t know what the right hand is doing…. How, then, shall teams communicate with one another? In as many ways as possible.”, Frederick P. Brooks, Jr.

2. Trabalhar com uma visão compartilhada.

   “Before the project gets rolling, a team needs to buy in to a common vision. Without such a shared vision, high-performance teamwork cannot take place. A study of 75 teams found that in every case in which the team functioned effectively, the team had a clear understanding of its objective.”, Steve McConnell

3. Fornecer mais poderes aos membros do time.

   “On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down. The structure of a team is a network, not a hierarchy.”, —Tom DeMarco and Timothy Lister

4. Estabelecer responsabilidades compartilhadas.

   “Each [team] member’s relationship to the team must be defined in terms of the role to be assumed and the results the role is to produce. Eventually, any team effort boils down to the assumption of individual responsibilities and accountabilities.”, Carl Larson and Frank LaFasto

5. Focar na entrega de valor no negócio.

   “Experience had taught Thomas Edison to combine commercial and technical considerations. The ‘electric vote recorder,’ the first invention for which Edison received a patent, tallied votes quickly and was intended for use within legislatures. But when he approached a congressional committee about sales, the committee chairman told him, ‘Young man, that is just what we do not want.” (It would infringe on the sacred institution of the filibuster.) His machine was never produced, and he resolved not to devote his attention to the invention of anything
   that lacked ‘commercial demand.’”, Randall E. Stross

6. Manter a agilidade e esperar mudanças.

   “Agile managers understand that demanding certainty in the face of uncertainty is dysfunctional. They set goals and constraints that provide boundaries within which creativity and innovation can flourish.”, Jim Highsmith.

7. Focar em qualidade continuamente.

   “Quality improvement is a never-ending journey. There is no such thing as a top-quality product or service. All quality is relative. Each day, each product or service is getting relatively better or relatively worse, but it never stands still.”, Tom Peters.

8. Aprender com a experiências passadas

   “Those who do not remember the past are condemned to repeat it.”, George Santayana

Estes princípios são universais e podem sem dúvidas ser aplicados ao RUP, CMMI, XP, PSP ou qualquer outro modelo.

O MSF conta hoje com duas personalizações; o MSF Agile (para projetos com menos rigor de processo) e o MSF CMMI (para empresas aderentes à praticas do CMMI).

O MSF ainda apresenta na sua estrutura os seguintes conceitos:

- Modelo de Times - Uma estrutura de papéis e as suas responsabilidades dentro de um projeto. O MSF define seis papéis centrais em uma estrutura de rede (não hierárquica!): Gerente de Produto, Gerente de Projeto, Desenvolvedor, Testador, Gerente de Implantação, Gerente de Usabilidade e Eficiência de Usuários.
- Modelo de Processos - Uma estrutura de organização de atividades nos ciclos de vida de um projeto
- Disciplina de Gerência de Riscos.
- Disciplina de Gerência de Projetos
- Disciplina de Gerência de “Readiness” (Foco no reuso de conhecimento e habilidades para prover soluções de software).

A estrutura de times do MSF, o modelo de processo e suas disciplinas são descritos nos documentos oficiais da Microsoft sempre como um conjunto de boas práticas, guias de orientação e aplicação e não como um processo prescritivo e dogmático de software. Dito isto, podemos definir e comparar o MSF, RUP e CMMI brevemente.

• MSF: Conjunto de boas práticas para desenvolvimento de software.
• RUP: Framework de processo de software.
• CMMI-Dev: Modelo de avaliação de maturidade no desenvolvimento de software.

Um comparação sobre o MSF e RUP pode ser encontrada no artigo a seguir daRational Edge - MSF and RUP.

Mais informações sobre o MSF podem ser encontradas no site oficial do MSF da Microsoft, disponível aqui.