PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • [SOA # 5] – Processos

    Da mesma forma que SOA não requer nenhuma nova tecnologia, o mesmo vale quando tratamos de processos ou metodologias para gestão de programas e projetos. A corporação pode e deve reaproveitar os processos existentes, principalmente as práticas com benefícios comprovados.

    Mas algumas mudanças podem ser necessárias, visando atender principalmente os meta-requerimentos Agilidade, Flexibilidade e Simplicidade. Um processo burocrático ou resistente a mudanças, como aqueles baseados em modelos waterfall (cascata), é incompatível com tais requisitos. Por outro lado, processos muito “leves” como XP (eXtreme Programming) podem resultar em redundância e retrabalho por não fornecerem uma visão geral da empreitada e por carecerem de atividades gerenciais.

    O equilíbrio entre a agilidade de um processo e robustez de seus mecanismos de administração e controle, alvo de vários estudos e propostas, é crítico para a realização das promessas de uma iniciativa SOA. Por isso trata-se de uma definição que deve ocorrer no âmbito do Programa, logo em seus primeiros momentos.

    Para um processo ser considerado adequado para a implementação de uma SOA ele deve:

    • Promover Agilidade: o que não significa apenas ganho de produtividade dos desenvolvedores. Um processo ágil elimina barreiras e integra atividades visando aumento da qualidade de todos os produtos gerados;
    • Absorver Mudanças: e não combatê-las. Um Serviço em uma SOA deve assimilar e refletir as mudanças que ocorrem em um processo de negócio de forma quase imediata. É vital que o processo saiba tratar tal volatilidade;
    • Respeitar a Arquitetura: ou seja, garantir que todos os participantes de uma iniciativa SOA tenham uma visão do todo, da Arquitetura, seus padrões e princípios;
    • Incentivar o Reuso: valorizando todos os ativos existentes e aqueles produzidos no programa e facilitando sua reutilização e combinação com outros ativos;
    • Facilitar a Comunicação: entre todos os participantes do programa e respectivos projetos e destes com as áreas de negócio.

    ===============

    Gestão do Portfólio de Serviços

    Uma das responsabilidades mais críticas do Comitê Gestor SOA é a administração do portfólio de serviços. A garantia do alinhamento do programa com as estratégias da organização e da satisfação de seus requerimentos são realizadas através de uma correta gestão do portfólio de serviços. Existem no mercado várias ferramentas que apóiam tal atividade, normalmente direcionadas para o acompanhamento de vários projetos. Elas podem ser adaptadas para o gerenciamento de um programa SOA.

    Os idealizadores da ferramenta Balanced Scorecard, Robert Kaplan e David Norton, lançaram recentemente um novo conceito que pode agregar considerável valor à gestão de um programa SOA. É o Mapa Estratégico , que “é a representação visual da estratégia de uma empresa. Sua principal finalidade é demonstrar a Prontidão de determinado ativo intangível para atendimento dos processos internos críticos: gestão de operações, gestão de clientes, inovação e processos regulatórios e sociais. Ele se torna uma visão consolidada das quatro perspectivas do Balanced Scorecard (Financeira, do Cliente, dos Processos Internos e de Aprendizado e Crescimento). Os ativos intangíveis foram estruturados em 3 grandes grupos: Capital Humano, Capital Organizacional e Capital da Informação. De acordo com os estudos conduzidos pelos autores e parceiros ao redor do globo, para o chamado Capital da Informação, o grande objetivo das empresas é a ‘disponibilidade de sistemas de informação, de infra-estrutura e de aplicativos de gestão do conhecimento necessários para suportar a estratégia’” .

    A relativa simplicidade desta ferramenta e a clareza com a qual demonstra as estratégias corporativas e sua relação de dependência com ativos de TI, o Capital da Informação, a tornam bastante adequada para a gestão, em alto nível, do portfólio de serviços. Como um serviço em uma SOA é a representação direta de um processo ou atividade de negócio, a comunicação do comitê gestor SOA com as áreas de negócio é bastante facilitada pelos mapas estratégicos.

    No entanto, serão necessárias várias alterações no formato original da ferramenta. Os ativos de TI são apresentados na obra em 4 grandes grupos: Sistemas Transacionais, Aplicações Analíticas, Aplicações Transformacionais e Infra-Estrutura de Tecnologia. Tal classificação deve ser trocada pelos 4 tipos de serviços (Básicos, Intermediários, Processos e Públicos) mais o Frontend das Aplicações e a Infra-Estrutura tecnológica.

    Uma nova dimensão deve ser criada para indicar a relevância estratégica de determinado serviço. Esta alteração também deveria afetar o modelo original, de forma a possibilitar que sistemas transacionais ou analíticos também possam ser classificados como “Transformacionais”, ou seja, como sistemas que alteram drasticamente um ou mais processos de negócios.

    Outra mudança necessária é na escala de avaliação da prontidão dos ativos. O estudo original apresenta seis níveis de prontidão :

    1. OK. Ativo atende plenamente os requisitos do negócio
    2. Leves Melhorias são necessárias
    3. Novos desenvolvimentos a caminho
    4. Novos desenvolvimentos atrasados
    5. Grandes Melhorias necessárias
    6. Nova Aplicação necessária

    A nova escala deveria refletir o ciclo de vida dos serviços, o que a deixaria da seguinte forma :

    1. Publicado: em Produção;
    2. Classificado: alocado na arquitetura e agendado para publicação;
    3. Certificado: aprovado nos testes de qualidade. Atende todos os requisitos especificados no Contrato do Serviço;
    4. Submetido: em processo de Certificação;
    5. Em Desenvolvimento;
    6. Identificado / Especificado: serviço já foi identificado e modelado – encontra-se na fila para início de sua construção.

    Deve-se lembrar que a principal utilidade desta ferramenta é a comunicação com o corpo diretivo da empresa. Daí a relativa superficialidade da escala de avaliação do grau de prontidão dos serviços. No entanto nada impede que extensões sejam desenvolvidas de forma a enriquecer o relatório e municiar os processos de tomada de decisão do comitê gestor SOA. As alterações mais desejadas talvez sejam aquelas que propiciem:

    • Visibilidade dos prazos de transição entre as etapas do ciclo de vida dos serviços;
    • Opções de aquisição ou desenvolvimento do serviço (compra no mercado, desenvolvimento interno, desenvolvimento terceirizado ou utilização de ativo livre e aberto disponível na Internet); e
    • Estimativas de custos de cada serviço.

    >>>>>>>>>> SOA #6 – MDA (Model Driven Architecture)

    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).
    5. “Gestão Estratégica de Ativos e Portfólios de Projetos de TI”, Paulo F. Vasconcellos
    Artigo publicado em Out/2004.
    6. “Mapas Estratégicos”, Robert S. Kaplan e David P. Norton
    Editora Campus / Elsevier (2004).

  • [SOA # 4] – O Programa SOA

    SOA representa uma nova forma para se desenvolver, manter, comprar e vender aplicações de negócios. Ela pode afetar praticamente todos os sistemas de informação de uma empresa. E, quando bem sucedida, não possui um prazo para terminar. Como a construção de cada novo Serviço pode ser gerenciada como um projeto em si, é recomendável que uma iniciativa para implementação de uma SOA seja tratada e gerenciada como um Programa. Como tal, deve possuir definições acerca de sua Estrutura, Processos e Padrões.

    Um programa SOA deve ser dirigido por um Comitê Gestor, desenhado e populado especificamente para a iniciativa. Dentre as responsabilidades deste Comitê destacam-se :

    • Estabelecimento e revisão das estruturas, processos e padrões utilizados tanto no âmbito do programa quanto no nível dos projetos;
    • Acompanhamento da execução de todos os projetos SOA;
    • Garantia do apoio e participação das áreas de negócio durante todo o programa;
    • Manutenção do plano estratégico e do foco da iniciativa; e
    • Execução de atividades de evangelização, como treinamento, coaching e divulgação dos benefícios e restrições do programa para toda a organização.

    O Comitê Gestor de um programa SOA possui algumas funções bastante particulares. A figura 3 abaixo apresenta um modelo padrão desta estrutura, destacando seus principais atores:


    O Gestor do Programa responde por ele perante toda a organização. Dada sua importância estratégica não será estranho se algumas empresas optarem por alocar o próprio CIO ou Diretor da área de TI nesta função. Ele é apoiado diretamente por um Engenheiro do Processo, que pode ser um representante do Escritório de Projetos (PMO – Project Management Office), caso exista. A uniformidade e respeito aos processos de desenvolvimento e manutenção são fatores críticos de sucesso. O Engenheiro do Processo deve garantir que tanto o programa quanto os projetos SOA estejam sendo executados dentro dos padrões estipulados pela corporação. Também é sua responsabilidade a indicação dos Coordenadores de Projetos, seu acompanhamento e apoio.

    No entanto, o “braço direito” do gestor do programa é o Arquiteto SOA. Ele é o principal responsável técnico pela elaboração e implementação da arquitetura orientada a serviços. Devido a abrangência, complexidade e criticidade de tal iniciativa, o Arquiteto SOA compartilha suas responsabilidades com outros 5 arquitetos, cada um especialista em uma parte do programa.

    O Arquiteto de Negócio é o principal representante do programa perante as áreas de negócio. Visto de outra maneira, ele também representa as comunidades usuárias no Comitê Gestor. Ele deve coletar, avaliar, apresentar e defender os requerimentos de negócio. Portanto ele faz uso, em alto nível, das disciplinas Modelagem de Negócios e Engenharia de Requisitos. Se estivessem representadas na figura 3 acima, as áreas de negócio estariam no lado esquerdo do desenho. Entende-se então que os membros do comitê gestor que se relacionam de maneira direta com a comunidade usuária, além do Arquiteto de Negócio, são o Gestor do Programa, o Engenheiro do Processo e o Arquiteto SOA. Mas sua representação é uma atribuição exclusiva do Arquiteto de Negócio.

    O Gestor da Biblioteca de Ativos (GBA) é um personagem raríssimo nos ambientes e projetos de TI. Mas sua existência é fundamental para o sucesso de um empreendimento SOA. Além do gerenciamento do Repositório, apresentado anteriormente, o GBA também é responsável pelos principais processos de reutilização de ativos , ou seja: publicação e manutenção dos Contratos; introdução e coordenação do reuso de ativos; evolução do processo de reutilização etc. Com o tempo e conseqüente aumento no número de serviços disponíveis cresce também a importância do GBA.

    O Arquiteto dos Frontends das Aplicações tem sua alocação no comitê justificada pelo fato destas interfaces serem o único ponto de interação dos usuários com a SOA. São críticas as atividades de padronização das interfaces e garantia de usabilidade, que são atribuições exclusivas deste arquiteto.

    O Arquiteto de Serviços, por sua vez, concentra-se na padronização, acompanhamento do desenvolvimento e avaliação dos Serviços. Nos momentos iniciais do projeto são de sua responsabilidade a elaboração de padrões para os quatro tipos de Serviços existentes em uma SOA, ou seja: Básicos, Intermediários, Processos e Públicos.

    Por fim, temos o Gestor da Infra-estrutura Tecnológica, o membro do comitê responsável por garantir que os recursos computacionais disponíveis sejam adequados para atender a demanda que SOA e seus serviços gerarão. Além do sizing e estudo de capacidade de carga dos servidores, redes e softwares de infra-estrutura, este Gestor também acompanha os serviços em ambiente de produção visando garantir os níveis de serviço esperados.

    Percebe-se que o Comitê Gestor é praticamente uma representação do corpo gerencial de uma organização de TI. Em muitos casos talvez seja uma estrutura ainda mais sofisticada e completa. Acontece que em um “mundo ideal”, quando SOA encontra-se em estágio avançado de maturidade e todos os processos de negócio são representados por Serviços, o comitê gestor do programa SOA torna-se praticamente a equipe de gestão de toda a organização de TI. Apesar de ser um conceito relativamente novo, alguns casos de sucesso comprovam que tal “metamorfose” é uma conseqüência bastante plausível de uma implementação SOA bem sucedida. É curioso notar também que em uma situação onde a empresa decide pela total terceirização de sua área de TI, as 8 funções apresentadas acima talvez sejam as únicas que a empresa decida manter internamente. Para não correr o risco de perder o alinhamento de TI com o negócio.

    >>>>>>>>>> SOA #5 – Processos

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).
    4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
    Springer (2002).

  • [SOA # 3] – É o Negócio, Estúpido!

    Um dos principais apelos e, porque não dizer, motivo de estranheza quando se analisa uma proposta de implementação de uma SOA, é o fato dela não apresentar ou forçar a utilização de nenhuma nova tecnologia. Pelo contrário. SOA deve promover a sobrevida dos ativos de software de uma organização, tanto das aplicações de negócio quanto dos elementos de infra-estrutura (como servidores de aplicações, middleware para comunicação assíncrona, dentre outros). Martin Frick chega a sugerir que troquemos o termo “sistema legado” por “Sistema Herdado” .

    O fato é que há muito conhecimento codificado na forma de software e espalhado pelas organizações. Mesmo após a implementação de soluções de integração de larga escala como os ERPs e sistemas CRM, a arquitetura de software das empresas continuou fragmentada, com diversos silos de informação. A característica “monolítica” destas soluções tornou cada esforço de integração uma espécie de barreira para a implementação de mudanças e novas funcionalidades no nível do negócio.

    O “ovo de Colombo” de uma proposta SOA está em seu linguajar, totalmente orientado ao Negócio. Os Serviços, suas Interfaces e Contratos são apresentados na língua de seus usuários e clientes. Elimina-se desta forma aquela distância e confusão que sempre caracterizou as interações das áreas de TI com seus usuários. Mas esta nova aproximação requer uma revisão na estrutura e processos da organização de TI, como será apresentada nos capítulos seguintes.

    Não é objetivo deste artigo tratar de questões acerca dos aspectos tecnológicos de uma implementação de uma Arquitetura Orientada a Serviços. Mas é importante lembrar que o conceito SOA nasceu logo após o advento dos Web Services. Estes nasceram com escopo relativamente limitado, propondo uma forma de integração de aplicações utilizando padrões abertos da Internet. Apesar de não serem obrigatórios para a realização de uma SOA, os Web Services e os padrões que os viabilizaram, como XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol) e WSDL (Web Service Definition Language), dentre outros, podem favorecer, e muito, a implantação de uma SOA. Mas deve-se lembrar que SOA não é um conjunto de Web Services e, por outro lado, o fato de uma empresa ter uma porção de serviços Web não significa necessariamente que ela possua uma arquitetura de aplicações orientada a serviços.

    As organizações de TI têm, talvez pela primeira vez em sua história, a oportunidade de fazer com que seus investimentos e custos tenham claro e inequívoco objetivo de negócio atrelado. Mas o sucesso de uma implementação SOA depende de uma ampla e compartilhada visão de seus objetivos, restrições e roteiro de construção. Como será exposto nos capítulos seguintes, a gestão do Programa SOA e respectivos projetos desempenha papel fundamental nesta realização.

    >>>>>>>>>> SOA #4 – O Programa SOA

    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).

  • [SOA # 2] – Conceitos Básicos

    SOA não é e também não promove uma nova tecnologia. Também é equivocada sua apresentação como uma nova “metodologia”. Trata-se de um conceito ou, como colocado anteriormente, uma Estratégia de TI. A principal motivação para sua implementação é a realização do tão sonhado (e raramente concretizado) Alinhamento Estratégico de TI com o Negócio. Entende-se que tal alinhamento acontece de fato quando :

    • TI agrega real valor ao plano de negócios;
    • Não resiste às mudanças;
    • Combate a resistência às mudanças; e
    • É planejado.

    Os três primeiros itens da lista são traduzidos em considerável ganho de Agilidade. SOA promete a criação de uma estrutura que reproduz fielmente, em mapeamento um-para-um, os processos e atividades de negócios. Tamanha aproximação deve gerar uma arquitetura flexível, que favorece as mudanças. Mas os ganhos possibilitados pela implementação de uma Arquitetura Orientada a Serviços não ocorrem por acaso ou de forma pontual. Uma implementação SOA é uma iniciativa de longo prazo – é a execução de um bem elaborado Plano Estratégico.

    SOA é uma arquitetura de software. Uma arquitetura de software é “um conjunto de definições que descreve componentes de software e associa a funcionalidade do sistema a tais componentes. Descreve a estrutura técnica, restrições e características dos componentes e das interfaces entre eles. A arquitetura é uma ‘planta baixa’ para o sistema e um plano de alto nível para sua construção” .

    Serviços em uma SOA são a representação direta de entidades, tarefas, atividades ou processos de negócio. Por representação direta entende-se a paridade em sua granularidade e o uso de um vocabulário comum, que deve ser a terminologia padrão do negócio. São características-chave de uma Arquitetura Orientada a Serviços:

    • Acoplamento fraco dos serviços;
    • Independência de tecnologias e protocolos;
    • Uso irrestrito de padrões; e
    • Incentivo à reutilização de ativos.

    SOA é composta de quatro elementos principais: Frontends de Aplicações, Serviços, um Repositório de Serviços e um Mecanismo de Execução e Comunicação (Bus) para os serviços.

    Os Frontends de Aplicações representam a “ponta do iceberg” de uma SOA. Eles são a interface dos serviços para os usuários finais. Portanto são de sua responsabilidade a iniciação e o controle da execução dos Serviços.

    Os Serviços são componentes de software que representam um processo, entidade, atividade ou tarefa de negócio. É importante salientar que são componentes de alto nível, diferentes daqueles existentes em plataformas como o J2EE e o Microsoft .NET, que são muito granulares e mais orientados a tecnologia, não ao negócio. Existem quatro tipos de Serviços:

    • Básicos: que representam os elementos básicos de um processo de negócio, como Entidades e Tarefas básicas de Negócios;
    • Intermediários: são o único tipo de Serviço mais orientados a tecnologia em uma SOA. Fornecem pontes, conversores ou funcionalidades adicionais aos demais serviços;
    • Processos: são os serviços que representam de forma direta um processo ou atividade de negócio, do início ao fim.
    • Públicos: extensão aos serviços do tipo Processo que possibilita sua exposição para clientes (usuários) que estejam fora das fronteiras da organização.

    Todo serviço, independente de seu tipo, é sempre composto por três partes principais, como ilustrado na Figura 1 acima. A primeira parte é um Contrato, um acordo que é fechado entre os consumidores de um serviço e seus provedores. Este documento explica os propósitos do serviço, contexto, regras de utilização, restrições, níveis de serviço esperados, além de apresentar uma definição formal da interface do serviço.

    Interface esta que é implementada em separado, sendo o segundo elemento de construção de um serviço. Trata-se do único meio de comunicação com um serviço, seja seu cliente um frontend de uma aplicação ou outro serviço. A terceira e última parte de um Serviço é sua Implementação propriamente dita, através da realização da Lógica do Negócio e acesso e manutenção de seus Dados, de forma a atender todos os objetivos fixados no Contrato.

    O Repositório armazena todos os Contratos dos Serviços disponíveis, o que o torna o ponto de partida para utilização destes. Além dos Contratos, o Repositório pode armazenar informações adicionais e mais específicas acerca dos serviços, como localização física, restrições de uso e segurança etc. Apesar de ser apresentado por alguns autores como um elemento opcional em uma SOA, o Repositório pode ser fator crítico de sucesso em grandes implementações, principalmente naquelas que envolverem a disponibilização de serviços do tipo Público.

    Por fim temos o Mecanismo de Execução e Comunicação para os Serviços, ou simplesmente Bus, que interconecta todos os participantes de uma SOA, abstraindo a complexidade técnica que existe nas camadas inferiores. Um Bus pode ser constituído de várias tecnologias e/ou produtos, dependendo da infra-estrutura existente e dos requerimentos de distribuição dos serviços.

    >>>>>>>>>> SOA #3 – É o Negócio, Estúpido!

    2. “The Squandered Computer”, Paul Strassmann
    The Information Economics Press (1997).
    3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
    Prentice Hall (PTR) (2005).

  • [SOA # 1] – Introdução

    As organizações de Tecnologia da Informação (TI) lidam há tempos com dois meta-requisitos conflitantes: ao mesmo tempo em que as áreas de negócio exigem mais e mais agilidade, a pressão por redução de custos se torna mais forte. “Fazer mais com menos” virou regra geral. Mas os ambientes de TI viram, nos últimos 10 anos, sua complexidade aumentar em escala exponencial. Diversas tecnologias, pacotes de software e sistemas desenvolvidos in-house se entrelaçam e se sobrepõem de forma que beira o caos.

    Não se trata de má administração, não na maioria dos casos. Acontece que a urgência dos requisitos de negócio e o relativo curto ciclo de vida de algumas tecnologias levaram as organizações a erguerem verdadeiras torres de Babel. Durante um tempo foi possível apagar fogueiras localizadas com certa agilidade. Mas esse imediatismo também criou uma infra-estrutura de aplicações com muita redundância de funções e responsabilidades, pouco flexível, cara de ser mantida e, principalmente, pouco ágil.

    Mesmo as tecnologias que surgiram para promover padronização e integração, particularmente aquelas chamadas Middleware, em pouco tempo passaram a se digladiar na mesma infra-estrutura de TI, acrescentando mais complexidade e heterogeneidade.

    Testemunhamos hoje o nascimento de uma série de tecnologias, processos e modelos que visam combater a imensa complexidade das estruturas de TI. Consolidação de servidores, virtualização e grid-computing, dentre outras, miram a racionalização dos recursos. Porém são propostas que visam quase exclusivamente os ativos palpáveis, desconsiderando as principais causas da falta de agilidade e flexibilidade das organizações de TI: as aplicações e os dados.

    Por isso que a proposta de implementação de uma Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture) ganha importância e faz com que alguns institutos, como o Gartner, prevejam que será a arquitetura dominante nas corporações já em 2007.

    SOA é uma estratégia que propõe a organização dos ativos de software de forma que eles possam representar Processos, Atividades ou Tarefas de Negócio de forma direta. Tais representações são chamadas de Serviços, que devem ser baseados em padrões e facilmente combinados e reutilizados visando a satisfação dos requisitos do negócio.

    A dinâmica do mundo dos negócios exige que as organizações de TI sejam ágeis, flexíveis e simples. São os mesmos meta-requisitos que governam os Programas e Projetos SOA. Esta série apresenta as particularidades dos projetos SOA, os novos desafios apresentados e a possibilidade de realização, enfim, de antigas promessas como a Reutilização de Ativos de Software.

    Apesar do aparente ceticismo e da profusão de definições desencontradas, naturais quando se trata de uma novidade apresentada como “panacéia” pelo mercado de TI, SOA deve se consolidar como uma nova forma de desenvolver, comprar e vender sistemas de informação. Se tal hipótese se confirmar, será a maior evolução da área desde a invenção do COBOL*. Que seja bem-vinda.

    >>>>>>>>>> SOA #2 – Conceitos Básicos

    * 1964

    1. “Service-Oriented Architecture Scenario”, Yefim Natis
    Gartner, artigo AV-19-6751 (2003).

  • Meme #009

    ManagementSpeak: This company is ISO 9000 certified.
    Translation: We have documents to prove who screwed up.

    Hehe.. Sou fã do Bob Lewis desde que li “IS Survival Guide”. No livro ele já tinha essa série, com “falas da gerência” e suas “traduções”. Hoje ele mantém o site “IS Survivor” e o mesmo bom humor.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Scrum !

    Para o artigo que estou desenvolvendo sobre “Projetos SOA” tive que mergulhar em alguns “Processos Ágeis”. Gostei um tanto do Scrum, e agora tento adaptá-lo para o desenvolvimento de Serviços em uma SOA. Trabalho legal.

    BTW, muito legal tb é o trabalho do Jeff Sutherland, criador do Scrum. Ele mantém um blog sobre o assunto. Foi lá que surrupiei a charge legalzinha aí de baixo:

    Espero voltar ao tema em breve.

  • CMMI x mpsBR

    Já divulguei aqui (e/ou no Graffiti) o grupo CMM-Br. O grupo praticamente dobrou de tamanho nos últimos três meses. E, por incrível que pareça, o aumento do número de participantes não resultou em queda da qualidade das discussões. Muito pelo contrário! Desde a semana passada tá rolando um debate legal sobre CMMI x mpsBR. Pra quem chegou agora: o mpsBR (Melhoria do Processo do Software Brasileiro) é um modelo ‘alternativo/suplementar’ ao CMMI. Tá aqui o pomo da discórdia: estamos reinventando a roda? Os defensores do modelo tupiniquim alegam a enorme economia de custos. Concordo. Mas ainda não consegui gostar do modelo. Não entendi o pq das diferenças, inclusive dos níveis de certificação. Mas o importante é que exista o debate. Em cima de propostas. Trouxe para o Finito um dos posts que pintaram no grupo. Seu autor, Sr Ricardo Mansur, autorizou sua publicação. Saca só:

    Boas colocações na questão de separação, afinal os chamados pacotes não demandam as certficações CMMI.

    Em relação ao software sob encomenda (serviço)eu discordo a little bit pois a India ( principalmente ) e China vem nadadando de braçadas neste mercado quase que sozinhas ( alguma competição do México ) e temos algumas empresas nacionais fazendo este tipo de desenvolvimento fora do Brasil.

    Então devemos nos perguntar por que empresas diversas do Brasil ( Não tão diversas assim, umas cinco ou seis ) ganham licitações para desenvolver software fora do Brasil, ou seja no local do solicitante e não conseguem na modalidade de offshore ?

    Por que a India consegue vender na modalidade off shore ?

    A resposta passa pelo termo gerenciamento. O Brasil consegue ganhar vendas na modalidade local do cliente pois tem engenheiros e outros profissionais de excelente qualidade, mas peca em termos de gerenciamento, a nossa fama é muito ruim quando falamos neste quesito e a India nada de Braçada porque além de estar cada vez mais se aprimorando no CMMI, ISO os seus profissionais tem em geral certificados PMP, ou seja eles se valem de certificados internacionais como pilares da sua vantagem
    competitiva.

    Ao se adotar modelos que não sejam padrão de mercado para métricas de qualidade nós estamos levando não apenas a indústria do software para um modelo que o mundo não reconhece, mas também arrastamos todos os setores produtivos nesta onda, já que tecnologia faz parte da infra dos negócios.

    Se o projeto for tocado 100% com capital próprio e sem incentivos fiscais e de juros será o mercado o decisor de que é mesmo é válido ou não, mas se existir dinheiro público, mesmo que na forma de renúncia fiscal nós estamos levando para a sociedade como um todo a conta de algo que é na minha visão como incerto….

    Quando falamos que estamos despreparados para um melhor nível de qualidade estamos na realidade condenando mais uma geração de brasileiros à probreza e miséria já que novamente estamos no posicionando no quarto de empregada da casa e não na sala de estar aonde estão ocorrendo as conversas de negócios lucrativos.

    A nossa qualidade de software está intimimanente ligada ao modelo de negócios no Brasil que tem remuneração como PJ e custo hora. Ora, qual profissional irá aumentar a sua produtividade em um cenário que ele irá receber menos ?

    Por que a India ganhou este mercado ? Parte se explica pelo modelo de negócios e a outra parte pela política coerente com normas, padrões mundiais e principalmente por conseguir alcançar primeiro objetivos que o primeiro mundo considerava quase impossível.

    O Brasil pode e deve ser um lider, se não mundial, pelo menos na América Latina e de repente podemos simplificar não mais falando de nível 5 mas de nível 2 ou 3 e com planos de médio e longo prazo para maiores níveis.

    Reparem na parte que negritei. Há tempos ‘arranho’ o tema mas o Ricardo, em 2 frases, falou tudo.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Meme #008 – "You Get what You Pay For"

    Trechos de um excelente artigo de Bob Lewis, autor de “IS Survival Guide”:

    …

    What motivates most employees is achievement, approval, or a sense of belonging to an exclusive group that’s doing something important. The money is nice, but not their primary driver.

    Not that they ignore what they’re paid. Quite the opposite — they give it their closest attention. That’s because a company’s compensation system is the loudest, clearest, and most emphatic communications channel it has for explaining to employees what it considers important.

    The classic example, used in every introductory seminar on Total Quality Management ever given, is the company that decided it wanted quality. It preached quality, taught quality techniques, and measured quality improvement. The result, month after month, was a total lack of improvement in its defect rate. Why? The factory manager’s bonus depended on how many widgets rolled off the production line every month.

    Pay for quantity, beg for quality, and quantity will win every time. What you pay for explains your priorities far better than your company newsletter.

    Bring it home to IT. Many CIOs want to establish a more process-oriented perspective in their organizations, to get (all together now!) Repeatable, Predictable Results. Whether it’s an ITIL initiative or an attempt to rise to higher levels in the Software Engineering Institute’s Capability Maturity Model, they want the IT staff to “plan the work and work the plan” instead of coming to work every day as if the world had just been created fresh and new.

    Good for them. These are important goals for many IT organizations. So if you’re one of them, go ahead and want process, teach process techniques, and measure process results. And then …

    A project team finds itself under time pressure. The project manager rallies the troops, who work a succession of twenty-four hour days and seven-day weeks. Gasping for breath, exhausted but exhilarated, they meet their deadline with minutes to spare.

    Impressed, you give them all bonuses for going the extra mile.

    Outstanding. Except …

    Another project team doesn’t find itself under time pressure. Every week, every team member meets every milestone. The project manager spots risks and issues early and deals with them. If one team member gets into trouble, the rest help out immediately so the schedule is never in jeopardy. The deadline rolls around, they put the software into production, and go home to spend the weekend with their families.

    Boring. Why would you give them a bonus? They didn’t go an extra block, let alone an extra mile. All they did was the work in front of them.

    Making process happen in IT is hard. If you pay extra for heroics while ignoring those who do their work by the numbers, you’re preaching process in a whisper while shouting, in the loudest voice you can, that you really don’t care for it all that much.

    As with any good process, the results are predictable, and have been repeated so many times you’d think we’d have caught on by now.

    You get what you pay for. If you want process, start paying for it, instead of its opposite.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Placar CMM/CMMI

    O SEI (Software Engineering Institute) acabou de publicar resumos das avaliações aplicadas no mundo todo, o Maturity Profile. Apesar de certa ‘economia’, alguns dados interessantes podem ser extraídos de lá. Por exemplo: mais de 70% das certificações CMMI reportadas nos EUA vão para organizações que trabalham para o governo ou para os militares. Fora dos EUA, quase 90% concentram-se em trabalhos internos ou comerciais.

    Mais de 20% das organizações certificadas CMM possuem entre 101 e 200 empregados. E 46% delas atuam na área de serviços, contra 24% na indústria. O ranking por países ficou assim:

    1o. EUA :: 1947
    2o. Índia :: 387
    3o. China :: 243
    4o. Japão :: 149
    5o. França :: 142
    6o. Reino Unido :: 139
    7o. Canadá :: 79
    8o. Coréia do Sul :: 75
    9o. Alemanha :: 62
    10o. Austrália :: 36
    11o. Itália :: 33
    12o. Israel :: 30
    13o. Brasil :: 28

    Meu “placar” ali do lado fala de 39 certificações no Brasil. Tirei os dados das 2 empresas certificadoras daqui, ISD e Procesix, e somei CMM e CMMI. Provavelmente vem daí a diferença.

    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.