O SOFTEX divulgou os resultados de desempenho de 2009 das empresas que adotaram o MPS BR.

A síntese do relatório é fornecida abaixo:

“De forma geral, a satisfação das empresas com o modelo MPS é notória, com mais de 98% das empresas se dizendo parcialmente ou totalmente satisfeitas. Além disso, as empresas relataram que o retorno do investimento foi obtido e, principalmente, para aquelas empresas que evoluíram ou internalizaram o modelo MPS em seus processos foi possível observar tendência a melhoria de custo, qualidade, prazo e produtividade, princípios básicos quando se desenvolve software seguindo os preceitos de engenharia.”

Os resultados detalhados do estudo são muito interessantes e destaco neste espaço dois índices: o aumento do faturamento das empresas e o retorno sobre o investimento obtido no esforço da implementação. Com cada vez mais evidências estatísticas, podemos começar a observar dados quantitativos que correlacionam investimento em engenharia de software com melhorias concretas e permanentes nas empresas.

O relatório completo, para os interessados, está disponível aqui.

Todo software instalado possui uma arquitetura que o rege, seja esta tácita ou explicitamente construída por arquitetos de software. Além disso, toda arquitetura tem um estilo associado. Se não pensamos na arquitetura de um software e no estilo desta arquitetura, ela pode ter um estilo diferente do que gostaríamos. Um estilo inadequado pode aumentar sobre-maneira os custos de construção e manutenção de uma aplicação.

Estilo Arquitetural - O padrão primordial para externalização da sua arquitetura

Um estilo arquitetural é um padrão arquitetural primordial que antecede todos os outros padrões arquitetural.Ele define e direciona outros padrões arquiteturais, padrões de desenho e decisões táticas ao longo do projeto. Exemplos de estilos arquiteturais incluem:

• Cliente-Servidor
• Baseado em cadastros Web
• Aplicações Ricas de Internet (RIA)
• Multi-camadas (n-camadas)
• Baseado em integração de aplicações (EAI)
• Baseado em serviços
• Baseado em processos de negócio
• Dirigido por domínio (DDD)
• Baseado em computação em grade (Grid)
• P2P

Normalmente uma aplicação possui apenas um estilo arquitetural, embora em situações incomuns possamos ter estilos combinados ou mesmo um estilo particular. A escolha de um estilo, entretanto, não é escolhida pela conveniência de um arquiteto, mas pelos condutores de negócio do projeto, produto e empresa do contexto onde a arquitetura e o software estejam sendo produzidos.

Se escolhermos um estilo inadequado, o projeto sofrerá sérias dificuldades. Por não pensar no estilo, desenvolvedores são guiados por decisões táticas, o que leva na maioria dos casos a sistemas de informações cadastrais, mesmo quando o estilo tem outra natureza. Acompanhei um colega de profissão que foi comandado a usar um framework de mercado que automatiza padrões cadastrais em um sistema de estilo baseado em fluxos de trabalho. A equipe deste colega de profissão tentou durante alguns meses resolver o projeto, até que o projeto fosse cancelado devido a uma baixíssima produtividade.

Ao começar o seu projeto, então, convoque uma entrevista com os seus usuários e investigue o estilo arquitetural do sistema que você irá construir.

Pensamento do dia: “Bona diagnosis, bona curatio”, (Um bom diagnóstico, uma boa cura)

O termo BPM nos remete a uma ênfase na palavra processos e uma visão de mundo onde uma empresa pode ser vista como uma coleção de processos. Este pensamento, em si, é perigoso e infelizmente enganoso. A palavra processos nos remete ao “como” e nos faz esquecer do entendimento do “quê” deve ser realizado. A consequência prática é que algumas iniciativas BPM de mercado tem falhado ou no máximo obtendo ganhos marginais. Podemos combater este pensamento com o conceito das “capacidades de negócio” como um elemento que precede os processos de negócio.

Repensando o salto em altura
Conforme citado no bom livro Rethink, de Ric Merrifield, os saltos em altura eram realizados com o atleta em direção frontal ou diagonal à barra. Ao tentar melhorar a eficiência destas técnicas, alguns atletas apenas obtinham um ganho marginal na altura transposta. Ao remover o raciocínio limitante e pensar em uma nova forma de saltar, um atleta chamado Dick Fosbury estabeleceu novos patamares para o esporte, ganhou a medalha de ouro no méxico em 1968 e batizou o estilo de salto usado hoje em 2010 com o seu nome. Ele escapou da armadilha do “como” antes do “quê”.

Modelagem de Capacidades de Negócio
O problema do BPM não é o foco em processos, mas o foco prematuro em processos. O atleta Dick Fosbury trabalhou muito na eficiência dos seus processos, mas depois de entender as corretas capacidades a serem realizadas. Estendendo as idéias tradicionais do BPM, destacamos aqui a idéia das capacidades de negócio.

Uma capacidade de negócio é visão multi-dimensional de uma organização com um objetivo claro de negócio, atividades de negócio (processos), recursos humanos, um modelo de governança e serviços de negócio. Um exemplo no segmento de TELECOM seria a “Ativação de Serviços de Telefonia”. Um outro exemplo, no segmento de aluguéis de carros seria a “Gerência de Frotas”. Neste instante do tempo, ainda não estamos preocupados com os processos necessários para a ativação de telefonia ou os processos para o gerenciamento de frotas.

Técnicas de modelagem de capacidades como o IBM Component Business Model ou o Microsoft Business Capability Mapping podem nos ajudam a modelar todas as capacidades da sua organização e desenvolver visões chamadas de mapas de calor para perceber os elementos disfuncionais em uma organização. Ao saber que disfunções a nossa organização possui, podemos então focar então na modelagem dos seus processos e então nas suas melhorias.

A disciplina de modelagem de capacidades é vista como arquitetura de negócio e deve preceder e guiar as atividades de modelagem de processos de negócio. A modelagem de capacidades é realizada pelo arquiteto de negócio da sua organização e a modelagem de processos pelo analista de processos de negócio.

Para os interessados no tema, coloco aqui algumas referências a respeito:

• Artigo de Ulrich Homann sobre o conceito de capacidades de negócio.
• Artigo de Michael Poulin sobre o IBM Business Component Model.
• Entrevista com Ric Merrifield sobre a modelagem de capacidades de negócio.

Aplicações Java EE impõe fortes desafios aos times de testes, qualidade e arquitetura de aplicações. Além dos inúmeros aspectos funcionais a serem observados, devemos observar também elementos técnicos de qualidade interna e qualidade externa tais como desempenho, usabilidade, segurança ou manutenibilidade.

Sabemos que ferramentas isoladamente não resolvem problemas complexos, mas uma vez que você tenha um método simples e eficaz para endereçar um problema, podemos aumentar a eficiência do método com ferramentas eficientes. Neste contexto, destacamos aqui algumas ferramentas que podem apoiar o seu trabalho em testes técnicos na plataforma Java EE.

• Testes de acessibilidade - O portal DaSilva (http://www.dasilva.org.br) realiza testes de acessibilidade a partir dos padrões WCAG e eGOV. Além disso, o portal também disponibiliza uma ferramenta para download para testes em Intranets.
• Testes de desempenho - O Apache JMeter é uma ferramenta para testes de carga, estresse e maturidade de páginas Web, filas JMS, pool de conexões JDBC e outros objetos Java EE. Robusta e madura, possui diversos tipos de gráficos e análises estatísticas de confiança. Recomendo também uma extensão simples do JUNIT chamada JUNITPerf, para testes de caixa branca de desempenho ou vazão (thoughput).
• Testes de instrumentação de códigos e servidores - O Eclipse TPTP realiza testes de instrumentação de código (profiling), que permite análise em nível de caixa branca (métodos Java) o uso de CPU, consumo de memória, vazamentos de memória e mesmo contenções de threads. Muito robusto ele gera inclusive diagramas UML2 de sequência dinamicamente a partir da interação com o servidor de aplicação alvo.
• Testes de cobertura - Recomendo novamente o Eclipse TPTP, que permite analisar que linhas, métodos e classes foram cobertas durante um determinado tipo de teste. A ferramenta indica linhas virgens e também permite montar histogramas das seções e métodos mais usados durante teste de aceite do usuário.
• Testes de automação Web - A plataforma Selenium realiza a automação de testes na Web através do conceito de gravação automatizada, extensão dos códigos gerados e reprodução. Os scripts gravados podem ser incluídos em suítes do JUNIT e ser também colocados em processos de integração contínua. O TPTP também possui uma ferramenta neste sentido, embora um pouco mais complexa para operação que o Selenium.
• Testes de interoperabilidade - Ferramentas como o jMOCK ou o EasyMock permitem que simulemos recursos como programas de terceiros para que possamos fazer testes fim a fim mesmo antes que estes programas estejam prontos. Estas ferramentas são baseadas no conceito de “dublês” e simulam literalmente o comportamento de um recurso a ser integrado. Este tipo de tecnologia também é util em grandes projetos quando times estejam construindo módulos que requeiram grande integração. e que ainda não estejam prontos.
• Testes de manutenibilidade - O Metrics é um plugin simples para Eclipse que faz análises diversas de código e extrai métricas universais de qualidade como por exemplo a complexidade ciclomática. Em resumo, ela responde a pergunta se o seu código é manutenível ou não. Uma outra ferramenta de livre acesso neste sentido é o SourceMonitor, que também traz gráficos diversos de análise como gráficos de histogramas e diagramas de Kiviat (gráficos polares) para análises executivas de qualidade.

Caso você conheça alguma outra ferramenta de teste técnico para Java EE, deixe aqui a sua opinião ou comentário.

Pensamento do dia: Amplius juvat virtus, quam multitudo (Mais vale a qualidade que a quantidade)

Tradicionalmente o desenho e implementação de aplicações modernas em linguagens como Java EE e .NET é tratado como um elemento puramente técnico. Um pequeno volume de horas é concedido ao time de desenvolvimento para resolver um problema complexo através de um conjunto de modelos técnicos, linguagens como UML e provas de conceito exploratórias. O foco na ótica gerencial é apenas em custos, o que explica porque pouco times no Brasil exploram o desenho como um software realmente merece. O resultado é publicamente conhecido, como nos relatórios das crônicas do caos na TI, que mostram o pífio desempenho dos projetos de TI por todo o mundo.

E se ao invés de pensarmos no desenho como um custo, pensássemos no mesmo como um investimento financeiro baseado nos conceitos de valor agregado e da prática da indústria chamada de software engineering economics.

O desenho baseado em valor agregado pode ser visto como uma atividade econômica, visto fazer um software não é uma atividade puramente técnica. Arquiteturas conceituais como o SOA mostram a importância de se pensar em software como um elemento de negócio.

Compilo aqui um conjunto de elementos necessários à implementação do desenho baseado em valor econômico em times de software.

1. Times devem ser auto-gerenciáveis. Times auto-gerenciáveis definem coletivamente os passos necessários para produzir os entregáveis técnicos de um projeto, ao invés de receber ordens de gerentes de mais alto nível que não entendem do método construtivo de software. Naturalmente, time auto-gerenciáveis são completamente responsáveis pelas consequências dos seus atos. O SCRUM é um excelente exemplo do uso desta técnica.
2. Todo elemento técnico deve ser pensado no valor agregado que ele produz para o projeto. O raciocínio da análise de valor agregado, difundida nos círculos gerenciais, deve se tornar uma obsessão diária. Por exemplo, a escolha sobre o uso de um estilo de RPC baseado em WS-* versus um estilo REST-* deve ser analisado de forma quantitativa e econômica. O valor agregado deve ser medido através do alinhamento dos benefícios técnicos aos condutores do projeto, ao custo de oportunidade do produto para uma organização e outros elementos organizacionais.
3. Orçamentos de projetos devem ser comunicados aos times técnicos. Times devem ser responsáveis pelo uso adequado do investimento do dinheiro de um projeto. Para criar esta responsabilidade, os orçamentos devem ser divulgados. Já tive a oportunidade de presenciar projetos onde técnicos passaram semanas experimentado tecnologias a seu bel prazer, sem nenhum compromisso com o dinheiro que estava sendo investido pelos patrocinadores.
4. Orçamentos devem ser monitorados diariamente. Por exemplo, um dia de um projeto de um time de cinco pessoas com formação plena no mercado Brasileiro é um investimento da ordem de 2 a 4 mil reais. Qual a contra-partida fornecida tecnicamente para justificar este investimento? Ao divulgar e monitorar o raciocínio de investimentos para desenvolvedores, eles se tornam mais comprometidos, conscientes e criativos no uso do dinheiro.
5. Praticar a mentalidade da abundância, do líder Stephen Covey. Ao comunicarmos investimentos para os times, temos que promover mecanismos de recompensas. Por exemplo, se tivermos um orçamento de 100.000 reais para um projeto e se o time atingir os critérios de qualidade para a entrega no projeto, a sobra de orçamento deve ser dividida pelo time, conforme a participação entre os seus membros.
6. Educar desenvolvedores em práticas de administração. Talvez a mais difícil missão, desenvolvedores devem não apenas conhecer Java, .NET, OO e padrões de desenho, mas também sobre o contexto e a importância do software para as organizações e empresas.

Pensamento dia dia:

“Não somos responsáveis apenas pelo que fazemos, mas também pelo que deixamos de fazer.”, Molière

Analistas são frequentemente questionados pelos seus gerentes sobre as suas decisões e tem por frequência a necessidade de expor a estes conceitos técnicos. Muitas destas apresentações se tornam desastrosas por desconhecimento do modelo mental dos gerentes. Adapto (e estendo) aqui um belo trabalho realizado por Gerrit Mulller, que discute aspectos importantes em apresentações técnicas para não-técnicos (gerentes).

1. Compreenda como gerentes funcionam. Gerentes são orientadas por ações, são normalmente impacientes, ocupados, trabalham com fatos e não com crenças, operam em contextos essencialmente políticos e buscam elementos financeiros e mercadológicos todo o tempo.

2. Apresente um material profissional, com uso moderado de imagens e animações e textos curtos. Longos textos e uma aparência pobre distraem gerentes e dificultam a venda de idéias técnicas.

3. Não apresente crenças e filosofias sobre métodos e técnicas explicitamente. Deixe que os fatos conduzam os gerentes sobre uma técnica ou um método que você deseje demonstrar.

4. Não subestime o conhecimento técnico dos gerentes. Ao mesmo tempo, nunca corrija um gerente desinformado caso ele diga uma “asneira” técnica no meio da sua apresentação. Lembre-se que gerentes possuem autoridade formal e analistas normalmente somente autoridade moral.

5. Não deixe que um gerente conduza e domine a reunião. Lembre-se que você é o “maestro”.

6. Organize o conteúdo sobre quatro elementos centrais (uma definição clara do problema, uma exploração da solução, opções e recomendações e uma lista de ações e decisões). Lembre-se, entretanto, de usar fatos e figuras para conduzir estes elementos.

7. Esteja confiante, mas aberto a ouvir. Esteja bem-vestido, mas permaneça autêntico ao seu estilo.

8. Gerencie as expectativas desde o começo da reunião. Diga o que irá fazer, faça o que disse que iria fazer e lembre a todos no final da reunião o que você disse.

9. Endereçe as preocupações gerenciais típicas. Traduza os requisitos técnicos em consequências de negócio (esforço e pessoas envolvidas nas ações, tempo, custos, riscos, investimentos necessários e lucro sobre este investimento).

10. Se atenha as princípios fundamentais das “Idéias que Colam” do irmãos Heath e do seu livro homônimo. Os seis princípios fundamentais são: Simplicidade, Concretude, Credibilidade das Idéias, Surpresa, Emoções e Histórias.

A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.

Caso a nossa empresa ou o problema em questão apresente a lista de condutores abaixo, uma abordagem arquitetural mais adequada é a orientação por eventos.

Condutores Arquiteturais para CEP (Processamento de Eventos Complexos)

• Agilidade e adaptabilidade.
• Gerenciamento por exceção.
• Respostas imediatas.
• Respostas instantâneas a eventos que ocorrem fora do seu eco-sistema de parceiros.
• Resposta a situações não antecipadas.

O CEP como um contraponto ao BPM tradicional

Dois cenários clássicos deste contexto são aplicações que monitoram fraudes e aplicações que reagem a eventos de mercado para sistemas de suporte a decisão de investidores. Uma abordagem tradicional baseada em BPM geraria um esforço absurdo na tentativa de modelar diversos caminhos e percursos de processos e situações, sendo que muitas destas situações ainda não são conhecidas.

No paradigma CEP (Complex Event Processing), a chave é adaptar software chamados de máquinas de eventos para ouvir a determinados tipos de eventos que necessitem ser monitorados. Estes eventos podem ser capturados de bases de dados, ERPs, CRMs e outros elementos arquiteturais do seu eco-sistema. A partir da sua máquina de eventos, processos podem ser iniciados ou outras ações podem ser disparadas. Por exemplo, se três eventos de uso de cartão de crédito ocorrem em um intervalo de cinco minutos com soma total acima de 500 reais, a máquina de eventos poderia solicitar a um operador do call-center ativo para retornar uma ligação a um cliente.

O CEP não invalida o BPM, assim com um contraponto musical não invalida a melodia central da música. Pelo contrário, o CEP enriquece o BPM, pois permite que processos de negócio sejam invocados de formas inesperadas. No cenário acima, o processo de monitorar compras do cliente pode ser invocado a partir de uma máquina de eventos, gerando maior eficiência e assertividade em uma administradora de cartão de crédito.

Uma arquitetura de TI que suporte o modelo CEP é chamada de EDA, i.e, Event Driven Architecture. Dentro do amplo leque de ferramentas SOA, temos diversos fornecedores com bons produtos EDA/CEP.

Esta é uma tradução pessoal do SOA Manifesto Guiding Principles criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis.

Bons projetos SOA!

O Manifesto SOA

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.

Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.

Esta é uma tradução pessoal do SOA Manifesto criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis. Acredito no manifesto. Também aderi ao manifesto, ao qual me tornei signatário.

Bons projetos SOA!

Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra linha de código, conforme mostrado abaixo.

Entretanto, se olharmos as especificações anteriores do EJB, veremos que esta simplicidade foi alcançada depois de muito trabalho na remoção de complexidades.

Por exemplo, o mesmo código em EJB 3.0 requer uma classe e duas interfaces Java, conforme mostrado abaixo:

Mais impressionante é notar que na especificação EJB 2.1 este mesmo exemplo seria implementado como uma interface local, uma interface remota, uma interface home, uma classe de implementação de negócio, uma classe de implementação da interface home e alguns arquivos XML. Um exemplo arqueológico pode ser encontrado aqui para os mais curiosos. Para criar um único método distribuído, precisamos de várias dezenas de linhas de código.

Se observamos ainda mais atrás no tempo um objeto CORBA, fonte de inspiração dos primeiros EJB, veremos ainda um código mais complexo.

Felizmente temos observado este movimento de simplificação de APIs em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo.

O modelo de servlets também foi simplificado. Agora podemos ter Servlets que são configuradas puramente com anotações ao invés de arquivos XML, conforme podemos ver no exemplo abaixo:

Um ambiente que já suporta estas novidades de simplicidade é o NetBeans 6.8. Notavelmente, o NetBeans tem conseguido “roubar” muita audiência dos desenvolvedores Java justamente por ser mais simples do que o poderoso (mas complexo) Eclipse. Para os programadores Java que nos leem, um tutorial é fornecido aqui.

Pensamento do dia: “Tudo deveria ser mantido o mais simples possível, mas não mais simples que isso”, Albert Einstein.

Pensamento do dia seguinte: “Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor””, William de Ockham