Realizamos recentemente uma palestra na SUCESU-MG sobre Arquiteturas de Negócio no grupo de trabalho de BPMS. Uma arquitetura de negócio é uma peça importante na estruturação e entendimento do modelo de negócio de uma organização e se constitui de ferramenta essecial para analistas de negócio e também arquitetos de TI.

Em particular, discutimos nesta apresentação o conceito de arquiteturas de negócio, modelos operacionais, capacidades corporativas e como estes conceitos são determinantes para facilitar implementações BPMS em organização. Discutimos também o anti-padrão “Ferramentas Primeiro”, onde procuramos mostrar que ferramentas BPMS não podem ser o elemento central de uma programa de melhoria BPM.

Disponibilizo a apresentação abaixo para os interessados no tema.

Arquiteturas de Negócio

A maioria de nós já ouviu falar da eficência da Toyota, que já assumiu o posto de primeira montadora de carros do mundo. Entretanto, é ainda mais interessante estudar os princípios que norteiam esta eficiência, chamados de manufatura enxuta. São sete os seus princípios, que focam na redução do desperdício:

• Superprodução: a maior fonte de desperdício.
• Tempo de espera: refere-se a materiais que aguardam em filas para serem processados.
• Transporte: nunca geram valor agregado no produto.
• Processamento: algumas operações de um processo poderiam nem existir.
• Estoque: sua redução ocorrerá através de sua causa raiz.
• Movimentação
• Defeitos, produzir produtos defeituosos significa desperdiçar materiais, mão-de-obra, movimentação de materiais defeituosos e outros.

Em 2004, dois computatas (Mary e Tom Poppendieck) adaptaram este processo para o contexto da engenharia de software, criando um conjunto de 22 “ferramentas” que promovem o aumento da eficiência de projetos em TI. Estes princípios foram batizados como “Desenvolvimento Enxuto de Software”.

Eliminação de Desperdícios

Comento aqui sobre o princípio da eliminação de desperdício através da remoção de atividades e produtos que não geram valor para o cliente. Alguns exemplos incluem:

• Requisitos folheados a ouro. A XP Conference de 2002 mostrou que quase metade das funcionalidades de um sistema não é usada. Funcionalidades não usadas implicam em desperdício. Uma forma de combater este mal é fazer perguntas e estudar a causa raiz das necessidades dos usuários.
• Requisitos ambíguos e voláteis. Requisitos voláteis provocam retrabalho. Retrabalho é desperdício. Devemos simplificar requisitos e criar sessões intensivas de coletas e acomodação de requisitos junto a todos os usuários chave.
• Burocracia. Reuniões gerenciais sem foco, sistemas de apontamento de horas que controlam até a ida de um funcionário ao banheiro e excesso de controle gerenciais são exemplos de burocracia.
• Comunicação interna ineficiente. Afastar os usuários dos analistas desenvolvedores, trocar a comunicação face a face por documentações frias e trancar desenvolvedores em baias (cubículos com paredes) são excelentes exemplos de como reduzir a comunicação em times e aumentar a ineficiência.
• Defeitos. Defeito é retrabalho. Devemos evitar defeitos realizado um processo contínuo de testes de unidade e refatorações desde o primeiro dia do projeto. Devemos procurar reduzir ao mínimo a densidade de defeitos no código de um sistema.
• Atrasos no processo de desenvolvimento de software. Testes que somente começam no meio do projeto, processos “mastodontes” e foco em documentos que não geram valor reduzem o valor de processos e aumentam o desperdício.

Alguns recursos complementares sobre o desenvolvimento enxuto de software são listados abaixo:

• Instituto para o desenvolvimento enxuto de software.
• Entrevista com Mary Poppendieck
• O livro que originou o tema na Engenharia de Software - Lean Software Development - An Agile Toolkit.

Estive em uma interessante e instigante apresentação de um arquiteto chamado Jan Bosch no último evento do SBQS. Comento aqui alguns dados interessantes sobre a organização de times da Amazon e do Google.

• 3 homens mês x 3 meses. Todo e qualquer projeto tem no máximo 3 pessoas em um tempo não maior que 3 meses.
• A regra das 2 pizzas. O tamanho máximo de um time deve ser limitado pela quantidade de comida presente em 2 pizzas grandes. Fiz rápidas contas e acredito que um o tamanho máximo não deve exceder 6 ou 7 pessoas para que ninguém fique com fome.

Aparentemente, a premissa é colocar como regra corporativa que o ciclo de vida de um produto deva ser guiado por projetos curtos com poucas pessoas e portanto com pouco overhead gerencial. Em times deste porte, podemos ter gerentes técnicos ou mesmo arquitetos que possam conduzir as atividades necessárias a geração de um produto.

Este conceito também traz implicações interessantes. Produtos devem ser gerados incrementalmente respeitando as enormes pressões de tempo de mercado e ao mesmo incentivando a criatividade dos técnicos envolvidos. A técnica clara para que isto opere é uma forte priorização de requisitos e um adiamento dos requisitos menos importantes para futuros ciclos e novas versões dos produtos.

Podemos ver também uma forte influência de culturas ágeis, com a geração de valor (produto operável na mesa dos usuários) como a regra número 01.

Em resumo, o que vemos nestas empresas talvez seja também uma forma humilde de reconhecer que a TI não deve operar como um fim em si mesma mas como uma forma de gerar maior valor de negócios. Projetos pequenos e rápidas liberações parece ser uma estratégia interessante, o que pode explicar uma parte do sucesso da Amazon e da Google.

Pensamento do dia: “Divide et impera”, ditado latino.

No Budismo, o caminho do meio (madhyamā-pratipad, em sânscrito) é a prática de ensinamentos que nos afastem das vaidades, extremismos e nos guiem a uma busca por mais sabedoria, moralidade e raciocínio. No mundo Java e .NET, o caminho do meio possui o mesmo conceito. Gostaria de compartilhar, neste contexto, uma interessante leitura sobre experiências de diversos arquitetos de software que guardam uma espantosa coincidência com as idéias e conceitos do caminho do meio. Esta lições estão coletadas no excelente e sucinto livro 97 Things Every Software Architect Should Know, escritas por diversos arquitetos de todo o mundo e compiladas por Richard Monson-Haefel.

Dentro das 97 dicas presentes neste livro, gostaria de destacar três:

• Não coloque seu resumè a frente dos seus requisitos. Este pequeno texto discute porque bons arquitetos primeiro entendem o problema e o contexto de negócio antes de propor a tecnologia preferida do seu currículo. A lição é clara: não leve a sua tecnologia Java ou .NET preferida para o seu cliente antes de entender claramente o problema.
• Simplifique a complexidade essencial, diminua a complexidade acidental. A complexidade essencial diz respeito a complexidade inerente a um problema. A complexidade acidental diz respeito a efeitos colaterais introduzidos por escolha de tecnologias complexas e soluções estado da arte. Exemplos são o uso de EJBs, servidores como o BizTalk, servidores de transações distribuídas ou modelos complexos de orientação por objetos para problemas simples que não necessitam deste tipo de solução. A lição novamente é clara: não introduza complexidade acidental para aprender uma nova tecnologia. É responsabilidade do arquiteto gerir bem o dinheiro do projeto, da sua empresa e do seu cliente. Não brinque com o dinheiro alheio por vaidade.
• Arquitetura é sobre equilíbrio. A arquitetura deve equilibrar aspectos técnicos e aspectos de negócio (condutores de negócio). “Arquitetos Java e .NET” que se esquecem de olhar para o negócio estão violando o caminho do meio. Estão buscando apenas um meio de satisafazer seus egos no uso de soluções “elegantes” e criar novos desafios técnicos que apenas eles precisam.

Um “arquiteto Java” e um “arquiteto .NET”, portanto, irá se tornar um melhor arquiteto se não ficar cego pelas palavras “Java” e “.NET” e colocar no seu cardápio porções de liderança técnica e práticas de alinhamento ao negócio.

Pensamento do dia: “A pior escravidão possível é a escravidão a si mesmo”, Sêneca.

Todos sabem que o Spagetti é uma massa de origem italiana muito popular no Brasil. Nem todos sabem, entretanto, o que é um código spagetti. Um código desta natureza é normalmente formado por um longo conjunto de instruções, com um vários níveis de aninhamento e grande complexidade técnica. A sua manutenção é trabalhosa e muitas vezes injeta erros colaterais na aplicação sendo mantida. Diferentemente do seu primo culinário, portanto, o código spagetti não é bem visto no mundo de TI.

Cortando spaggettis com o uso da métrica de complexidade ciclomática
Cortar um spagetti com faca é um crime culinário para os italianos. Na TI, infelizmente, não nos resta outra opção. Devemos cortar o mal pela raiz, literalmente.

Para isso, podemos usar como métrica um algoritmo que mede o quão simples ou complexos são os métodos e funções que compõem uma aplicação. Chamado de complexidade ciclomática e formalizado por Thomas McCabe, este algoritmo basicamente mede o número de caminhos lineares independentes encontrados em um método ou função. Quanto maior o número de caminhos, mais complexo é o seu código. Valores maiores que 10 geram um alerta amarelo, pois isto indica que o código está muito complexo para um ser humano manter. Surpreendentemente, vemos códigos em empresas com valores maiores que 100, 200 ou 500 (!!!), que são verdadeiros lamaçais de spagetti.

Felizmente não precisamos conhecer os detalhes do algoritmo (baseado em teoria de grafos) para usá-lo. Ferramentas simples e gratuitas analisam todo o código fonte das nossas aplicações e produzem uma análise de complexidade média e de ofensores individuais. Compilo abaixo algumas ferramentas para suporte este processo.

• Source Monitor - Ferramenta simples que calcula a complexidade ciclomática e outras métricas para Delphi, VB, VB.NET, HTML, C#, C++, Ansi C e Java.
• Metrics - Excelente plugin para eclipse, compila diversas métricas de qualidade de código, incluindo a complexidade ciclomática.

Com os resultados em mãos, podemos refatorar os códigos para torná-los mais simples.

Pensamento do dia: “A evolução do conhecimento humano é em direção à simplicidade, e não à complexidade”, L. Ron Hubbard

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Pensamento do dia - Eclesiastes 4:9 Melhor é serem dois do que um, porque tem melhor paga do seu trabalho. 4:10 Porque se um cair, o outro levanta o seu companheiro.

Duas notícias recentes levantam críticas sobre o uso dos tradicionais e estabelecidos modelos de gerência de projetos, programas e portfólios do renomado instituto PMI.

1. O Gartner Group fez críticas duras à falta de aplicabilidade destes corpos de conhecimento para TI devido especialmente à sua superficilialidade em diversos pontos (sic). A notícia completa e uma análise desta polêmica esta aqui na portal da SearchCIO. Compilo aqui uma frase do diretor de pesquisa do Gartner Group, Michael Hanford - “Their portfolio management standard shows a solid understanding of a complex discipline, but I’d say it disappoints with an uneven level of explanations“.

2. O SCRUM tem sido adotado mundialmente em cada vez mais empresas no Brasil e no exterior. Uma interessante reportagem do uso do SCRUM em empresas fora do âmbito de TI está disponível aqui. Aparentemente, o SCRUM se adapta melhor a empresas com realidades dinâmicas e ágeis e segue a escola de gerenciamento ágil que também tem sido fomentada pela IBM em sua melhor prática denominada Two Level Planning.

Pensamento do dia: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”, Charles Darwin

Diversas empresas já possuem iniciativas SOA em andamento ou pensam em fazê-lo em breve. Entretanto, poucas empresas no Brasil tem discutido o conceito do Centro de Excelência. Endereço neste artigo o conceito e a função do centro de excelência em implementações SOA.

Em termos simples, um Centro de Excelência (CDE) é um time multi-disciplinar dentro de uma empresa que promove melhores práticas, conhecimento e a implementação de novas soluções dentro de um determinado escopo. Um escritório de projetos (PMO), como exemplo, é um centro de excelência para gerência de projetos. Um CDE SOA faz este trabalho dentro do universo SOA, que envolve um grande conjunto de conhecimentos e habilidades necessárias para a sua implementação.

Tipos de Centros de Excelência SOA

De acordo com um excelente artigo de auxílio na montagem de centros de excelência SOA, podemos classificar os CDE em três tipos - Acadêmico, Técnico e Técnico Avançado. As principais funções destes CDEs são descritas abaixo:

Membros de um Centro de Excelência SOA
Quem irá participar de um centro de um excelência SOA é decisão do CIO, mas a recomendaçào primária é que arquitetos, times de infra-estrutura, gerentes de produtos e vendas e influenciadores de negócio e técnicos estejam envolvidos, bem como o chefe de tecnologia (CTO) e o próprio CIO.

Pudemos acompanhar um CDE em uma empresa que está iniciando uma implementação SOA recentemente e notamos um forte envolvimento do CIO, CTO e time de arquitetura, bem como pessoas de áreas de negócio e produtos em um modelo similar ao da figura abaixo.

Para os mais interessados, um bom artigo que endereça este tema é discutido na revista CIO Zone. Um webcast a respeito está disponível também no excelente site SearchSOA da TechTarget.

A comunicação talvez seja o princípio mais importante das escolas ágeis mas é infelizmente muito mal compreendido por técnicos de TI. Exploro aqui duas rápidas questões sobre princípios de comunicação efetiva.

O princípio da comunicação quente
A paleta de cores abaixo mostra algumas formas de comunicação em projetos. Quanto mais quente (à direita), mais rico e efetivo é o mecanismo de comunicação.

Surpreendemente, analistas gostam de email e documentação (mesmo com o colega a dez metros de distância), que são formas frias de comunicação. Ao invés, comunicações quentes (conversas) devem ser usadas para estabelecer sinergia e transmitir idéias entre times. Este princípio, explorado anteriormente por Alistair Cockburn e revisitado por Scott Ambler, é descrito em mais detalhes aqui.

O princípio SUCESSO
Idéias que colam e sào lembradas por pessoas são simples, inesperadas, concretas, transmitem crença imediata, remetem a emoções e são baseadas em histórias. Cito como um exemplo um assunto aparentemente árido - a instrumentação de alarmes em sistemas telefônicos, que foi transmitido com sucesso através da metáfora arquitetural Clínica médica por um grupo de técnicos do nosso convívio.

O caso completo é descrito em mais detalhes aqui.

O livro Idéias que Colam, escrito por Chip Heath e Dan Heath, endereça estes princípios e fornece dezenas de exemplos de como comunicar efetivamente idéias para outras pessoas.É um livro brilhante e leitura indispensável a bons comunicadores.

Pensamento do dia: “True interactivity is not about clicking on icons or downloading files, it’s about encouraging communication.”, Edwin Schlossberg.

Adapto para o português algumas pérolas extraídas de um bem humorado web site sobre “verdades” SOA, citadas pelo arquiteto de software Neal Ford, da Thought Works.

• SOA é á unica coisa que Chuck Norris não pode matar.
• O livro “SOA in a Nutshell” são dez volumes com 7531 páginas cada um.
• Uma pessoa conseguiu definir SOA com sucesso… e então morreu.
• SOA pode vencer você no jogo da velha, mesmo que você comece!
• Em uma batalha entre um Jedi e um Ninja, o SOA vence.
• SOA viola a primeira e terceira leis da termodinâmica, mas não a segunda, dado que toda a energia vem do SOA.
• No oitavo dia, Deus criou o SOA, e SOA criou o Rock e Roll.
• Plutão não é mais o nono planeta, porque SOA queria o seu lugar.
• SOA é a postura da Yoga que consiste de realizar todas as outras posturas da Yoga ao mesmo tempo.
• Dante tem um nível especial no inferno para consultores que não tenham SOA nos currículos.
• A solução para SOA é 42, que nos leva a questão….
• Se você plugar SOA na sua nuca, você já sabe Kung Fu.
• SOA significa SOA Oriented Architecture.
• Einstein definiu E=mc2 depois de rejeitar a equaçÃo soa = mc2 , que era muito poderosa e volátil.
• Arquitetos de software não usam SOA. SOA usa arquitetos de software.
• Com muito SOA na sala, você nao precisa de desenvolvedores.
• A resposta para a última questão sobre vida, universo e tudo mais é…. SOA.
• Darth Vader disse uma vez, “SOA, eu sou seu pai”. SOA replicou…”Vader, EU sou o lado negro”.
• Não existe governança SOA. SOA governa você.
• O aquecimento global não foi causado por dióxido de carbono, mas pelo calor dos servidores rodando SOA.
• A primeira implementação SOA em uma empresa é o triunfo da imaginação sobre a inteligência.
• A segunda implementação SOA em uma empresa é o triunfo da esperança sobre a experiência.