O MPS-BR, modelo Brasileiro de maturidade de software, está evoluindo a pleno vapor. Três novos guias estão disponíveis no portal do MPS-BR.

- Guia de Implementação – Parte 8: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações que adquirem software.

-Guia de Implementação – Parte 9: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Software.

- Guia de Implementação – Parte 10: 2009 (Outubro de 2009)
Este guia contém orientações para a implementação do Modelo de Referência MR-MPS em organizações do tipo Fábrica de Teste.

Estes novos guias mostram a necessidade de personalização de processos para segmentos específicos da indústria e também indicam um caminho de aumento de maturidade para organizações de TI sérias mas que infelizmente não possuíam um modelo de referência para trabalhar.

Pensamento do dia revisitado: “Um longo tempo é necessário para trazer a excelência à maturidade”, Publius Syrus, Séc. I A.C.

Depois de um longo e pesado Setembro, estamos de volta ao nosso bom hábito de escrever. Desta vez gostaria de falar sobre uma habilidade cada vez mais valorizada pela empresas de TI, que são os “soft skills˜, ou habilidade suaves, em uma tradução literal. Estas habilidades são muito enfatizadas pelos agilistas e escolas ágeis e tem a ver com habilidade de comunicação, compreensão, liderança moral e a capacidade de unir e organizar times de trabalho. Um artigo muito interessante de Gary Pollice, da IBM, está disponível aqui.

Li recentemente trechos da filosofia estóica, que tem similiaridade com o Budismo, e que por incrível que pareça podem nos ajudar na TI a sermos pessoas melhores e ganhar autoridade moral sobre times. Parece que filosofia e TI tem pouco em comum, mas o oposto é verdade. As frases abaixo nos mostram como a nossa atitude correta importa muito na saúde de projetos.

“As coisas que nos afetam estão fora de nós. Mude sua atitude e então, como um navio entrando num porto seguro, você encontrará a calma.”

“Quando contrariado, recue e considere se às vezes você não é culpado exatamente pela mesma coisa.”

“Antes de cada ação pense: eu não teria nenhuma razão para me arrepender depois?”

“A felicidade daqueles que querem ser populares depende dos outros; a felicidade daqueles que buscam prazer flutua com humores fora do seu controle; mas a felicidade do sábio nasce dos seus próprios atos livres.”

A virtude e a maldade existem, não como emoções e pensamentos, mas como ações.”

Frases do imperador romano e filósofo estóico Marcus Aurelius Antoninus

Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?

Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de BRMS (Business Rules Management Systems).

Um BRMS não nos é útil se não entendermos o conceitos primário de uma regra de negócio, descrito abaixo.

Regras de Negócio - Átomos de Negócio do Domínio

Uma regra de negócio expressa uma restrição sobre um domínio de negócio. Um exemplo simples é mostrado abaixo:
Se o cliente possuir cadastro de crédito positivo no SERASA, então o desconto sobre o financiamento será de 1%

A premissa de um motor de regras é que as regras podem ser expressas e mantidas em uma linguagem natural (ou uma aproximação) e portanto permitem uma velocidade e responsividade muito maior da TI a alterações regulatórias e de inovação nas áreas de negócio. Em tese, a mudança da regra de desconto de um financiamento de crédito pode ser totalmente implementada por um analista de negócio em um sistema BRMS, sem conhecimentos profundos dos complexos padrões WS-* e de linguagens pouco produtivas como Java, COBOL ou C++.

Regras não são um agrupamento desordenado de textos. Um modelo de regras deve ser identificado e organizado a partir de um conjunto de critérios formais tais como:

• um vocabulário de negócio que exprime a semântica dos conceitos sendo trabalhados em um domínio - Fatos;
• um conjunto de proposições que permitem a geração de conhecimento a partir destes fatos.

No exemplo acima, podemos identificar como fatos primários o CLIENTE e o FINANCIAMENTO. A proposição do exemplo usa o crédito do CLIENTE para estabelecer uma política de desconto sobre o FINANCIAMENTO.

Um modelo formal para compreender como estruturar regras de negócios é o OMG SVBR, cuja versão 1.0 está disponível aqui. Recomendo fortemente que os iniciados em BRMS estudem este documento antes de abrir e trabalhar com uma suíte BRMS. O documento pode parecer tedioso, mas assim como para dirigirmos um carro precisamos de aulas de legislação, precisamos entender que suítes BRMS estão baseados em conceitos não tão populares que precisam ser entendidos. Para os mais apressados, uma boa introdução ao tema está disponível aqui.

Outras especificações relacionadas são o OMG BMM (que motra o papel das regras de negócio dentro da modelagem de negócio) e o OMG PRR (que mostra como um programa computacional pode ativar inferências a partir de um conjunto de regras de negócio e uma memória de trabalho). O PRR é, em termos leigos, o mecanismo de inteligência artificial usado pelos motores de regras. O BMM, por sua vez, permite entender como o BRMS está ligado com o BPM e as estratégias corporativas.

Suítes BRMS

Um BRMS parece ser apenas uma ferramenta, mas como o próprio nome diz ele se refere a um conjunto de ferramentas, onde cada ferramenta tem um propósito. Listo abaixo algumas categorias de ferramentas BRMS:

Um dos gaps existentes nos times de desenvolvimento de software é a distância entre a concepção e desenho da arquitetura e sua efetiva realização. Motivos para este problema incluem:

• Mudanças de escopo e mudanças nas prioridades dos condutores e requisitos arquiteturais,
• Ausência de desenvolvedores na definição da arquitetura. Quando uma pessoa não participa da definição de um plano arquitetural, ela tem dificuldades naturais em se comprometer com aquele planejamento.
• Dificuldades para uma pessoa qualquer (inclusive o arquiteto) para manter o rigor das suas próprias definições dentro da complexidade e pressão de um projeto.
• Complexidades nas transformações e na rastreabilidade dos requisitos de negócio em condutores, dos condutores em requisitos arquiteturais, dos requisitos arquiteturais em mecanismo de análise, dos mecanismos de análise em mecanismos de desenho e estes em mecanismos de implementação, que possibilitam que um código fonte seja escrito.

Práticas arquiteturais como a arquitetura coletiva e a gestão do ciclo de vida da arquitetura de software, que descrevemos em outros posts, podem nos ajudar a minimizar estes problemas.

Uma outra ajuda neste sentido foi lançada recentemente no JBOSS World 2009 que ocorreu semana passada em Chicago. O projeto SAVARA tem por objetivo garantir um modelo vertical completo de rastreabilidade de requisitos de negócio em projetos SOA, conforme a figura abaixo mostra.

Este projeto é baseado em uma metodologia de governança de serviços da Red Hat e Cognizant e apresenta como conceito interessante o uso da CDL como técnica de representação arquitetural dos requisitos arquiteturais. Do que pudemos examinar até o momento, o projeto utilizará como tecnologia central o JBOSS Drools Guvnor como ferramenta de repositório. O Guvnor, conceitualmente, é uma implementação da especificação Java para conteúdos de repositórios (JSR 170).

Embora ainda tenhamos que esperar que este projeto possa amadurecer e se tornar um produto real, é no mínimo uma satisfação ver frutos dos conceitos de arquiteturais testáveis e métodos de avaliação arquitetural como o ATAM.

Um conceito muito importante no mundo SOA é a escolha do ponto de entrada. Um ponto de entrada descreve para uma empresa, área de negócio ou mesmo uma unidade de negócio qual a melhor abordagem arquitetural para uma automação SOA.

Os principais pontos de entrada SOA são:

• Integração de pessoas;
• Integração de processos;
• Integração de aplicações (conectividade);
• Integração de informações;
• Reuso.

Um ponto de entrada de pessoas por exemplo irá demanda uma abordagem arquitetural baseada em serviços visuais. Tecnologias como portais, mash-ups, portlets, sindicalização, colaboração, fluxos de trabalho/workflows devem fazer parte da sua agenda técnica.

Um ponto de entrada de processos, por outro lado, irá demanda uma abordagem arquitetural baseada em serviços de processo e serviços de negócio. Tecnologias como BPMN, BPEL, orquestração e coreografia e processos e motores de execução de processos farão para da sua agenda técnica.

Um ponto de entrada de integração de informações, para citar um outro exemplo, nos leva a uma plataforma de serviços de dados. Tecnologias e conceitos como replicação de dados, federação de dados, bancos federados, caches, GEDs, entre outros, irão fazer parte da sua agenda.

A natureza operacional da sua unidade de negócio determina os pontos de entrada SOA

Pode parecer que *nós*, analistas e arquitetos, temos livre arbítrio para escolher qual o ponto de entrada que desejamos usar. Entretanto, isso não pode estar mais longe da verdade.

A natureza e o modelo operacional de uma empresa, uma área ou mesmo unidade de negócio demanda maior ou menor necessidade de integração de dados e integração de processos. Nem sempre uma grande integração de dados e uma grande integração de processos é necessária. Uma holding, por exemplo, necessita de grande integração de dados mas baixa integração de processos. Cada empresa que compõe a holding, entretanto, pode ter diferentes necessidades e assim recursivamente nas suas unidades de negócio.

Conforme estas necessidades de integração, podemos derivar quais capacidades de TI serão mais úteis e mais corretas para que possamos então escolher um melhor modelo SOA para a nossa área, unidade de negócio ou empresa. Escolher o SOA correto para a sua unidade de negócio tem a ver com eficácia e com o alinhamento das ações de TI com a arquitetura de negócio da sua empresa.

Para os mais céticos, basta olhar os portifólios de produtos que trabalham com SOA. A JBOSS, por exemplo, tem diferentes suítes de produtos para diferentes abordagens arquiteturais. O JBOSS MetaMatrix (TEIID), por exemplo, é para o SOA baseado em serviços de dados e faz parte do JBOSS Data services Platform. O JBOSS jBPM, por outro lado, é para o SOA baseado em serviços de processo e serviços de negócio. O JBOSS Portal, como um terceiro exemplo, é para o SOA baseado em integração de pessoas e faz parte do Portal Platform.

Nas empresas líderes SOA de mercado (IBM, Oracle/BEA/SUN, TIBCO), a segmentação do portfólio é ainda mais aparente e os pontos de entrada SOA são uma boa forma de digerir e entender como a oferta de valor destas empresas pode ser melhor para a sua empresa.

Antes de começar a sua implementação SOA, então, faça a seguinte pergunta: “Qual o melhor SOA para a minha empresa?”.

Postei há algum tempo aqui uma notícai sobre o jogo Innov8 (Innovate) da IBM que mostrava de forma lúdica os conceitos de BPM em um jogo 3-D com excelente qualidade gráfica.

Agora o jogo está disponível online para qualquer usuário (basta preencher um registro e criar uma conta). Para os estudantes universitários da parceria acadâmica IBM, ele pode ser baixado para a sua máquina.

O jogo foi melhorado e agora apresenta cenários de negócios diferentes para os jogadores.

Bons jogos e bom aprendizado!

Veja o trailer aqui.
Jogue o jogo online aqui.
Baixe o jogo completo aqui.

O modelo de “fábricas de software” está em franca expansão na TI Brasileira. Com a premissa de maior produtividade e redução de custos para contratantes, este modelo originalmente nasceu do belo conceito de “Software Product Lines”, muito bem documentado em corpos de conhecimento do SEI e outros institutos mundo afora.

Infelizmente, algumas “fábricas de software” não são exatamente “Product Lines”, mas instrumentos de lucratividade apenas de seus sócios.

Coloco abaixo um teste lúdico para que um desenvolvedor possa avaliar a qualidade do ambiente que ele trabalha. Quanto maior a pontuação, melhor.

Horas Extras

• Horas extras são uma exceção e você é pago com um valor de hora extra conforme legislação CLT. (SOME 1 PONTO)
• Horas extras são uma constante e você é pago com incentivos morais, tapinhas nas costas e elogios oportunistas. Normalmente você trabalha mais de 200 horas por mês. (SOME -1 PONTO)
• Você não tem finais de semana. (SOME -2 PONTOS)

Treinamento e Aprendizado

• Existe um programa de treinamento formal na sua empresa e você é normalmente capacitado em novas tecnologias e novos domínios de negócio. (SOME 1 PONTO)
• O seu programa de treinamento é feito por conta própria por você de madrugada e nos finais de semana. (SOME -1 PONTO)

Participação em Projetos

• Você é normalmente convidado para opinar e propor soluções técnicas no seu projeto. (SOME 1 PONTO)
• Você recebe ordens e deve executá-las sem discutir. (SOME -1 PONTO)

Apoio Gerencial

• O seu gerente é um facilitador para os seus problemas. (SOME 1 PONTO)
• O seu gerente somente sabe cobrar o % de completude do caso de uso. “E aí, tá pronto?”. (SOME -1 PONTO)

Apoio Técnico

• A sua empresa possui uma área de frameworks e técnicos especialistas para resolução de problemas. (SOME 1 PONTO)
• O seu suporte técnico é o Google. (SOME -1 PONTO)
• Você não tem acesso ao Google no trabalho. (SOME -2 PONTOS)

Tratamento na empresa

• O seu RH o trata pelo nome. (SOME 1 PONTO)
• O seu RH o chama de recurso ou colaborador nos emails. (SOME -1 PONTO)

O resultado da sua fábrica…

Se você marcou mais que 3 pontos, isso é uma excelente notícia. O seu ambiente é saudável e você tem uma boa qualidade no desenvolvimento diário dos seus sistemas. Conte a sua história aqui.

Se você marcou entre 0 e 3 pontos, você provavelmente trabalha em uma fábrica de recursos. Você é uma mais uma peça da engrenagem fabril. Recomendo que você assista ao clássico filme chamado “Tempos Modernos”, com o Charles Chaplin.

Se você marcou pontuação negativa, você trabalha em um presídio de software. Recomendo que você assista ao clássico filme “Fuga de Alcatraz”, com Clint Eastwood.

Fizemos na semana passada uma apresentação sobre o modelo de computação nas nuvens e a sua interação com novos modelos de negócio e novos modelos técnicos tais como software como serviço, virtualização de hardwares e o modelo de cauda longa.

A apresentação está disponível aqui para os interessados:

Fiz recentemente um diagnóstico de maturidade no desenvolvimento de software de empresas de software de todo o Brasil. Um dos pontos de investigação era o uso de modelos formais de “certificação”. Para minha surpresa, vi que o modelo CMMI está com uma audiência muito baixa no Brasil quando comparado ao modelo brasileiro MPS.BR, que goza de grande popularidade. Como exemplo, no estado onde fizemos um estudo mais detalhado (Minas Gerais), vimos apenas 4 empresas com modelos CMMI implementados, contra mais de duas dezenas de empresas com o modelo MPS.BR implementado.

Não tenho a pretensão de realizar aqui um julgamento de valor, mesmo porque a constelação CMMI é um trabalho mais sólido e maduro que o nosso modelo tupiniquim, mas coloco abaixo uma percepção sobre esta grande popularidade do modelo MPS.BR

• O MPS.BR conta um programa de fomento do governo Brasileiro, capitaneado pela SOFTEX.
• O MPS.BR é aceito como comprovação de maturidade em toda licitação de um órgão do governo.
• O MPS.BR conta com um rede articulada de atores de negócio regionais e um número cada vez maior de implementadores e avaliadores.
• Uma implementação CMMI é bem mais cara que uma implementação MPS.BR. A relação é da ordem de 3 para 1 e especialmente para empresas de pequeno e médio porte o custo pode ser proibitivo.
• O MPS.BR possui um modelo de implemetação para grupos de empresas, que torna os custos compartilhados de cursos, de implementadores e avaliadores bem mais adequados à realidade do mercado nacional de desenvolvimento de software.
• A premissa de offshoring do CMMI não se mostra economicamente viável na prática. Um desenvolvedor Brasileiro custa em torno de 25 dólares, contra 10 dólares de um desenvolvedor Indiano ou os meros 7 dólares de um desenvolvedor Chinês. Somos clararamente não competitivos quando comparados a eles para atividades triviais e sem valor agregado dentro da cadeia de desenvolvimento de software.

É importante dizer que o MPS.BR e o CMMI são modelos que aferem a qualidade do processo e não a qualidade do produto e por isso não tem a pretensão de garantir a qualidade dos sistemas de software desenvolvidos por empresas. Entretanto, devido a futura e próxima ubiquidade do MPS.BR no Brasil, vejo um efeito similar ao das empresas indianas com o CMMI, i.e, quem não possuir pelo menos uma titulação MPS.BR nível G (parcialmente gerenciado) ficará fora do mercado e nem será avaliado por empresas contratantes de software.

Pensamento do dia: “Um longo tempo é necessário para trazer a excelência à maturidade”, Publius Syrus, Séc. I A.C.

Diversas empresas da primeira onda de SOA criaram um vasto portifólio de serviços em suas implementações de automação de processos de negócio. Muitas destas empresas, entretanto, criaram serviços não governados, i.e, serviços sem controle (sem cadeias de autoridade, controle de mudanças, versões, relacionamento entre serviços, políticas de reuso). A consequência foi um desalinhamento entre o valor esperado pelo programa SOA e um valor realmente obtido.

A governança SOA surge neste contexto de desalinhamento. O seu objetivo é prover algum nível de controle destes serviços para que possamos gerir cuidadosamente o investimento de TI destas iniciativas de melhorias.

Para tornar concreto nosso raciocínio, vamos usar um exemplo prático associado ao desenvolvimento de WebServices. Podemos ter uma política de governança SOA para testes de WebServices que diga que todo arquivo .WSDL seja interoperável conforme com o padrão de interoperabilidade de WebServices WS-I Basic Profile 1.1. Este exemplo de governança garante que um WSDL criado em Java será compatível com um cliente de serviço escrito em ASP.NET.

Um centro de excelência SOA, que descrevemos em outro post, seria responsável pela implementação deste tipo de política de governança em uma organização.

Fizemos recentemente uma apresentação sobre este tópico, que gostaria de compartilhar neste nosso espaço.