Marco Mendes´s Blog

Se a sua empresa lembra o programa Zorra Total, talvez seja interessante trocar de canal. A troca de canal significa pensar sua empresa como uma coleção de processos e implementar práticas ágeis de BPM e BPM Enabled by SOA. Experiências a respeito são sempre uma boa fonte de inspiração e por isso compartilho neste brevíssimo blog uma coletânea de dezenas de filmes SOA compilados pela IBM.
Filmes e WebCasts SOA

Acredito que independente da sua escolha de fornecedor, estes vídeos fornecem exemplos, relatos, experiências e casos de sucesso da adoção de BPM e SOA em empresas de toda sorte.

Recomendo também, para complementar estes webcasts, o espaço SOA da IBM (SOA Space). O SOA Space é um mash-up (portal Web 2.0) com dezenas de portlets com conteúdos variados e informativos sobre SOA.

A Internet nos trouxe as bibliotecas digitais. Bibliotecas digitais são excelentes mecanismos para conhecer novos assuntos, nos aprofundarmos em assuntos já conhecidos ou mesmo aumentar a nossa produtividade enquanto engenheiros de software.

Melhor ainda se a biblioteca digital puder ser usada sem a violação de direitos autorais, fato que infelizmente não ocorre com outras “bibliotecas” de endereço e reputação duvidosa.

Em particular, recorro sempre à um biblioteca de excelente qualidade chamada RedBooks. O RedBooks (http://www.redbooks.ibm.com) é uma biblioteca pública de livros diversos de TI. O download dos livros em formato digital é gratuito e os livros podem eventualmente ser comprados em formato impresso.

O segredo do Redbooks é que esta é uma rede social, i.e., qualquer pessoa com conhecimento técnico suficiente pode se inscrever e participar de um projeto que irá escrever um novo livro. Vários Brasileiros participam ativamente deste processo, inclusive.

Existem vários domínios (assuntos) dentro desta bibliotecas. Destaco três em particular:

• RedBooks para Desenvolvimento de Aplicações.
• Software Rational (Ferramentas para Governança do Desenvolvimento e Entrega de Aplicações)
• Software WebSphere (Ferramentas para Operações de Aplicações e SOA)

A qualidade dos RedBooks, de forma geral, é muito boa. É possível, inclusive, votar na qualidade e criticar os livros, que eventualmente são melhorados ao longo do tempo. Dados de pesquisa da IBM junto a seus clientes mostraram dados interessantes do aumento de produtividade no uso dos RedBooks. Coloco aqui um fragmento desta pesquisa.

Para não perder o hábito de falar sobre SOA, coloco aqui as dezenas de ocorrências que encontrei sobre SOA no RedBooks Online.
- Redbooks de SOA

O que é uma arquitetura de referência?

É uma coleção de de boas práticas arquitetônicas para capturar soluções provadas em um problema de um determinado domínio. Em termos simples, ele oferece uma base de onde criamos boas arquiteturas de software em projetos de TI. Um exemplo interessante de uma arquitetura de referência específica para o domínio Java é o Java EE (Java Enterprise Edition), que define um modelo provado para a montagem de aplicações corporativas em tecnologias Java.

Quando falamos de SOA, estamos falando de gerar agilidade para os negócios. O propósito básico de SOA é prover à TI um mecanismo provado de alinhamento com áreas de negócios. Quando somamos SOA e arquiteturas de referência estamos falando, portanto, de um conjunto de mecanismos provados para projetos SOA. Interessante notar que SOA não é uma arquitetura de TI, mas uma arquitetura de negócio. Portanto, uma arquitetura de referência para SOA envolve aspectos técnicos e também aspectos de negócios. Exemplos incluem:

• Camada de Governança
• Camada de Serviços de Apresentação (ex: Portais e Mash-ups)
• Camada de Serviços de Processos de Negócio
• Camada de Serviços de Dados

Desenhar e montar uma arquitetura de referência, entretanto, não é uma tarefa fácil. São necessários anos de práticas e vários projetos para capturar as boas práticas e afastar as más práticas. Felizmente, podemos contar com duas empresas sólidas, com dezenas de anos de experiência no desenvolvimento, entrega e suporte de aplicações corporativas. Destaco aqui a BEA e a IBM. Exemplos de seus produtos incluem os OLTPs de excelente reputação como o BEA’s TUXEDO (desde 1983) e o IBM CICS (desde 1969). Interessante notar, as duas soluções mais maduras de SOA do mercado são da BEA e IBM. Delas vêm também boas arquiteturas de referência, que podem ser usadas até por empresas e pessoas que não usem produtos destas empresas. Destaco, em particular, dois excelentes white papers da BEA e da IBM, respectivamente.

• BEA’s SOA Reference Architecture SOA - Excelente artigo com a montagem de uma arquitetura de referência para SOA.
• Design an SOA solution using a reference architecture - Também um excelente artigo com uma arquitetura de referência em nove camadas.

Embora com visões diferentes, os dois artigos podem e devem ser usados por qualquer técnico interessado em SOA e BPM. Como disse Isaac Newton certa vez sobre o seu trabalho da figura do começo deste artigo: “Eu pude ver mais longe porque estava apoiado nos ombros de gigantes”.

O Apache Tuscany é um servidor (ambiente de execução) baseado na Arquitetura de Componente de Serviços (SCA - novo modelo de componente que facilita a construção de aplicações SOA), e se baseia em um conjunto de especificações inicialmente desenvolvido pela IBM e BEA, que está sendo padronizado pela OASIS, como parte da Arquitetura Aberta de Componente de Serviços (Open CSA). Tecnologicamente, o SCA pode ser comparado a especificações de Web-Services (WS-*), só que um estágio evolutivo à frente.

A versão 1.1 do Tuscany foi lançada recentemente e suporta diversas linguagens de implementação em sua versão atual, tais como:

• Java Beans
• Spring
• Scripting - JSR 223(JavaScript, Groovy, Ruby, Python & XSLT)
• BPEL
• XQuery
• OSGI

Algumas das especificações SCA suportadas por este ambiente incluem:

• SCA Assembly Model V1.0
• SCA Policy Framework V1.0
• SCA Java Common Annotations and APIs V1.0
• SCA Java Component Implementation V1.0
• SCA Spring Component Implementation V1.0
• SCA BPEL Client and Implementation V1.0
• SCA Web Services Binding V1.0
• SCA EJB Session Bean Binding V1.0

A princípio, tudo isso pode parecer muito complexo. Por outro lado, podemos entender o SCA como uma tecnologia muito interessante que permite expor códigos legados ou novas funções dentro de uma arquitetura de serviços 100% SOA.

Uma boa forma de desmitificar esta complexidade é rodar o tutorial abaixo, onde você monta uma aplicação SOA baseado em serviços compostos em apenas dez minutos.

- SOA com SCA em Dez Minutos

Um aspecto muito importante dentro do mundo SOA é que novos papéis emergem e devem ser considerados na montagem de um time de projeto com orientação a SOA. Estes papéis são baseados nos papéis já conhecidos pelo mercado, mas algumas diferenças são notadas.

O ciclo de desenvolvimento SOA pode ser descrito em alto nível como mostrado na figura abaixo.

Dentro deste ciclo de vida, podemos identificar os seguinte papéis primários:

• Analista de Negócio. Descrito no passo (1), este analista é responsável pela modelagem dos processos de negócio da organização e pela exploração de novos cenários de negócios e pela definição e aferição de métricas de negócio (KPIs). Este analista não deve ser confundido com o analista de sistemas ou o analistas de requisitos. O analista de requisitos é responsável por descrever requisitos em modelos de casos de uso, enquanto que o analista de sistemas é responsável por exprimir a solução técnica de TI de um requisito. O analista de negócio, muitas vezes, se encontra fora da área de TI e possui um profundo conhecimento do seu segmento de negócio, como por exemplo o segmento bancário, indústria ou logística. O analista de negócio exprime o seu trabalho em notações como o BPMN ou o XPDL, entre outras. Não é incomum observamos em organizações mais evoluídas a figura do arquiteto de negócio, que tem a responsabilidade primária de organizar e garantir o reuso dos diversos processos de negócio de uma organização.
• Arquiteto de Integração. Este papel é responsável pela orquestração dos processos de negócio descritos pelo analista de negócio. Ele opera sobre modelos BPEL, entre outros, que são linguagens que permitem orquestrar um processo de negócio, i.e., implementar cada passo de um processo como chamadas a Web Services a recursos legados distintos tais como COBOL, ADABAS, MUMPS, SAP e PeopleSoft, entre outros. Para este trabalho, ele conta com o trabalho de desenvolvedores especialistas e arquitetos de sistemas, que a ele provêm adaptadores e conectores para o seu trabalho de integração. Este arquiteto produz códigos executáveis que irão rodar sobre servidores de processo, que são extensões sobre os famosos servidores de aplicação e que usam ESBs e servidores de filas de mensagens para conseguir rodar um processo de negócio.
• Implantador. Este papel é responsável pela implantação e operação dos processos de negócio nos ambientes de execução. Ele pode ser pensado como um papel similar ao *Deployer* Java EE, responsável pelo empacotamente, ajustes finos e garantia do uso dos melhores recursos do servidor de aplicação.
• Usuários e Administradores. Finalmente, conforme mostrado no passo 4, existem os usuários e administradores, que irão operar os processos de negócio. Os processos terão as suas métricas avaliadas em tempo real através dos servidores de processos e retroalimentarão os analistas de negócios com possíveis melhorias nos processos de negócio.

Sempre ouço questionamenos sobre o uso efetivo de SOA no mercado Brasileiro. Infelizmente temos poucos casos publicados e isso leva sempre a um questionamento sobre a efetividade de SOA dentro da nossa realidade. Nesste contexto, coloco em anexo uma apresentação realizada pela IBM com casos relacionados a SOA no governo Brasileiro. Estes casos mostram que a arquitetura orientada por serviços é bastante real e está mais presente na nossa vida que podemos imaginar.

Casos de Sucesso SOA no Governo Brasileiro

Para quem quiser se familizarizar antes com os conceitos de SOA, disponibilizei uma apresentação de SOA em um blog anterior.

Milhares de empresas em todo o mundo sofrem da síndrome do búfalo mais lento, que atrasa a movimentação de uma manada de búfalos nas migrações nas savanas africanas nas suas constantes buscas por novos locais de alimentação e procriação.

A notícia ruim, para a área de TI, é que nós somos este búfalo mais lento. A TI, historicamente, mostra uma impressionante falta de flexibilidade para responder às necessidades de negócio cada vez mais dinâmicas de toda empresa. Isso tem transformando áreas de TI em pesados dinossauros, inflexíveis às mudanças.

O tema modernização corporativa de TI é cada vez mais uma prática chave para permitir a evolução das empresas e suas pesadas áreas de TI. Mas o que é a modernização corporativa?

A modernização corporativa é um conjunto de boas práticas que tem por objetivo promover maior flexibilidade às organizações, reduzir o custo operacional de TI e promover alinhamento entre as áreas de negócio. Podemos entendê-la em cinco grandes áreas:

• Reuso de Ativos
• Arquitetura
• Habilidades das pessoas e equipes
• Processos e ferramentas
• Racionalização dos Investimentos

O reuso de ativos tem por missão promover uma maior gestão do conhecimento através da montagem de inventários eletrônicos dos ativos de software de toda organização de TI. Padrões OMG como o Reusable Asset Especification padronizam e formalizam os mecanismos de reuso corporativos de ativos. Ferramentas open-source como o Reusable Asset Specification Repository for Workgroups ou profissionais como o IBM Rational Asset Manager ou IBM WebSphere Service Registry and Repository fornecem mecanismos para inventariar eletronicamente os softwares. A montagem de um robusto inventário de meta-dados sobre os ativos existentes permite às organizações gerir o seu conhecimento tangibilizado em milhares ou milhões de linhas de código. Outras ferramentas, como o IBM WebSphere Studio Asset Analyser, permitem manter e estender ativos já existentes, com suporte também a controle de mudanças e análise de impacto nestes ativos. Ferramentas ainda mais avançadas, como o IBM WebSphere Asset Transformation Workbench permitem um suporte a gestão do conhecimento, com mecanismos e técnicas para manter e evoluir ativos, descobrir e registrar regras de negócio em sistemas legados e também a analisar o potencial de reuso de trechos de aplicativos.

Independentemente de ferramentas, a mensagem é clara. Um programa de reuso de ativos é fundamental para o reaproveitamento dos investimentos realizados ao longo de décadas em tecnologias legadas como Natural, PowerBuilder, COBOL, PL/1, versões antigas de VB e Delphi, entre outras. Uma metodologia para suporte a um desenvolvimento orientado a reuso de ativos pode ser encontrada aqui.

A arquitetura também é uma peça chave para modernizar empresas. Nexte contexto, a palavra chave é SOA. A arquitetura SOA é uma arquitetura de negócio que busca o alinhamento das ações de TI. Uma das premissas de SOA é permitir que os ativos já existentes sejam expostos como serviços para consumo por outras aplicações. Um bom ponto de partida para o desenvolvimento de uma arquitetura corporativo é o TOGAF, que comentamos em um blog anterior uma excelente base de conhecimento para arquitetos corporativos.

O terceiro aspecto neste processo de evolução de um réptil legado em uma ave é o uso dos talentos corporativos. Solicitar a uma pessoa com dez, vinte ou trinta anos de experiência de negócios que ela se capacite em complexos middlewares de aplicações distribuídas como Java EE é um contra-senso. Estes “analistas de negócio” devem ser potencializados onde agregam mais valor: conhecimento do negócio. Opcionalmente, eles podem operar ferramentas de mais alto nível com linguagem chamadas de EGL. Linguagens EGL permitem a abstração de complexos detalhes de arquitetura tais como clusterização, controle transacional, segurança e aspectos avançados de programação OO. Um exemplo de ferramenta que suporta este paradigma é o IBM Rational Business Developer, que opera sobre o Eclipse em uma linguagem trivial para pessoas sem fluência em OO e arquitetura e gera código executável em COBOL ou Java EE.

O quarto aspecto no processo lida com o fênomeno negativo dos silos em empresas de porte médio ou grande. Nestas organizações, cada time tem o seu próprio processo de coleta de requisitos, gerência de defeitos, uso de práticas tecnologicas ou de manutenção de aplicações. É o que CMMI descreve como processo ad-hoc, que alguns gostam de chamar perversamente de caótico. Devemos combater isso com a intitucionalização de boas práticas de engenharia de software e mecanismos de automação do ciclo de vida de projetos de software. Iniciativas inovadoras como o projeto JAZZ ou ferramentas para automação do ciclo de vida do desenvolvimento de software com o IBM Rational ClearQuest podem apoiar esta questão. Uma outra interessante iniciativa neste contexto também e o Eclipse Process Framework, solução open-source para a documentação e publicação em Web Sites de processos de qualquer natureza. Novamente, a mensagem é clara. Silos de comunicação devem ser combatidos e o conhecimento destas ilhas deve ser promovido para toda a organização para a criação de processos consistentes, ágeis e produtivos.

O último aspecto é a racionalização dos investimentos necessários ao suporte de TI. Uma análise comentada neste interessante podcast sobre modernização corporativa mostra que entre 15 e 25% do código mantido em produção nas organizações nunca é alcançado, isto é, nunca é usado pelos usuários. Este código morto é claramente um fonte de custo e complexidade nas áreas de TI. Uma outra fonte de gasto o tremendo esforço gasto para testes de regressão em aplicações ou para tratar graves defeitos em produção. Ferramentas open-source como o Eclipse TPTP ou profissionais como o IBM Rational Functional Tester e IBM Rational Purify Plus podem apoiar na automatização de testes e análise de cobertura de código, racionalizando desta forma os investimentos de TI.

Obviamente, o esforço de modernizar uma empresa ou uma TI é bastante complexo. Devemos escolher uma ou duas áreas acima e começar um programa de modernização com metas e focos claros e dentro da gerência de um projeto coordenado.

Finalmente, é importante citar que empresas que ainda operem em modo legado vão ter cada vez mais dificuldade em responder aos negócios e irão sofrer uma lenta e dolorosa morte empresarial. As empresas ágeis que aprenderam a evoluir, inovar e se re-inventar como aves de rapina irão sobreviver.

Recomendo, para os interessados neste tema, outras fontes de informação sobre isso, colocadas abaixo:

• PodCast (em inglês) sobre modernização corporativa. The growing importance of enterprise modernization
• Página sobre Modernização Corporativa da IBM
• Demonstrações de Ferramentas

Realizamos esta semana uma palestra sobre SOA no 44 Café Empresarial da ASSESPRO-MG. Neste encontro, pudemos debater sobre aspectos importantes sobre uma arquitetura de serviços e paradigmas que devem ser adotados para a sua correta implementação.

A apresentação realizada neste evento está à disposição aqui para download.

Observo, com cada vez maior frequência e mais preocupação, a baixa importância dada a gerência de riscos em projetos de TI. A gerência de riscos é um dos princípios chave do RUP e de vários outros processos de software. Apesar disso, observo riscos de toda sorte que surgem, crescem, tomam proporções gigantescas e levam a equipe a níveis de stress e desespero.

A gerência de riscos pode parecer assustadora, mas pode ser realizada em passos simples. Considere um projeto de TI qualquer. Podemos dividí-lo em quatro marcos, associados a zonas de riscos.

• Riscos de Viabilidade - Devem ser mitigados até 10% do prazo de um projeto.
• Riscos de Colapso Arquitetural - Devem ser mitigados até 30% do prazo de um projeto.
• Riscos Logísticos - Devem ser mitigados até 50% do prazo de um projeto.
• Riscos de Entrega - - Devem ser mitigados até 70% do prazo de um projeto.

Os riscos de viabilidade surgem quando o gerente ignora leis fundamentais de estimativas na organização do escopo, prazo, custo, qualidade e riscos na iniciação de um projeto. Diversos projetos são fechados com escopos não realizáveis nos prazos, custos e qualidade acordados. A consequência é na maior parte das vezes a qualidade, dado que alguma variável tem que ceder. Por exemplo, observações exaustivas de Barry Boehm mostram que comprimir um cronograma em mais que 25% do seu cronograma nominal é estatisticamente inviável. Diversas outras observações de Frederik Brooks, em seu clássico livro “The Mythical Man-Month”, mostram que adicionar pessoas a um projeto já atrasado também não funciona. Uma excelente fonte de consulta e aprendizado sobre este tema e o livro “Software Estimation - Demystifying the Black Art“, do autor Steve McConnel. Um artigo rápido sobre este tema é Something’s Gotta Give, do autor Scott Ambler. O resumo aqui é: Se um projeto mostra-se inviável em suas variáveis básicas (qualidade, riscos, escopo, prazo e custo), nao o traga para casa. Dizer NÃO ao final da iniciação de um projeto não deveria ser uma vergonha. Muito pior é perceber dez meses depois que o projeto foi cancelado pelo cliente depois de milhares ou centenas de milhares reais gastos.

Dado que um projeto seja viável, temos que torná-lo livre de riscos técnicos. Para isso, gerentes não podem ignorar que todo projeto merece uma arquitetura executável. Para isso, devemos priorizar os requisitos mais importantes do usuário e de maior dificuldade técnica e gerar códigos que os realizem, em conjunto com todos os requisitos não-funcionais críticos de um sistema. Nunca devemos começar por cadastroa CRUD, dado que isso apenas adia os riscos dos riscos de integração, desempenho, usabilidade, segurança e especialmente de mudanças de escopo. Concentrar a energia central no mais crítico antecipa riscos e promove um mecanismos saudável de mitigação dos mesmos. Nesta fase, o projeto ainda deve ter poucas pessoas, dado que o ambiente está instável. Recomendo, em particular, um excelente artigo de um dos pais do RUP (Phillippe Kruchten) — Common Misconceptions about Software Architecture para removermos mal-entedidos sobre a palavra arquitetura. Exemplos de colapsos arquiteturais são banco de dados ou servidores Web que não escalam ou descobertas tardias que a aplicação não opera em um browser não identificado. Em resumo, para evitarmos um colapso arquitetural devemos implementar e testar entre 5 e 20% dos requisitos mais críticos para termos um arquitetura executável (fundação) que sustente os vintes andares de código que nos aguardam.

Dado que a base técnica do projeto tenha sido criada, é hora da economia de escala. Neste ponto, podemos ter vários desenvolvedores operando em paralelo (como uma linha de montagem) para implementar os diversos casos de uso de um sistema. Entretanto, antes devemos preparar a logística de operação do time. Temos já um líder técnico de desenvolvimento para suporte imediato às dúvidas do time? Temos um processo de micro-gerência nas mãos? Temos um criterioso processo de controle de mudanças definido? Temos ferramentas de micro-gerência como o Mylin para controle fino do tempo gasto por cada desenvolvedor? O ambiente e políticas de gerência de configuração está estável? Conheci (e conheço) gerentes ingênuos que fizeram (e ainda fazem) a alocação de várias pessoas ao projeto sem ter respondido a estas questões. O resultado é ….caótico. Tarefas redudantes, re-trabalho, conflitos no versionamento do código, equipes estressadas e outros sintomas se manifestam.

Finalmente, se o gerente conseguiu chegar até aqui, ele deve se preparar para os riscos de entrega do produto. Um plano de implantação foi definido? Os usuários chaves foram envolvidos? Os ambientes de teste integrado, homologação e produção foram corretamente desenhados e testados? Critérios claros de aceite como percentual mínimo de cobertura de código em testes integrado, curvas de tendência de defeitos ou mecanismos de operação da aplicação da produção foram pensados? Novamente o gerente deve estar atento a estes detalhes para evitar a morte do projeto quase na sua entrega. Uma leitura chave para este processo é o excelente livro do autor Scott Ambler chamado The Unified Process Transition and Production Phases : Best Practices in Implementing the UP.

Afinal, matar um elefante é fácil, mas….

A área de TI cada dia conta com mais (e melhores) corpos de conhecimento para vários papéis de engenharia de software, gerência e outras áreas. Compilo aqui um conjunto de BOKs de renome reconhecido e de grande valor para projetos de TI.

• PMBOK: Clássico corpo de conhecimento do PMI. Atualmente em sua terceira edição (inclusive em português), compila as melhores práticas para a gerência de projetos para as áreas de gerência integrada, de escopo, qualidade, custo, prazo, recursos humanos, aquisições, riscos e comunicações. Outros excelentes corpos de conhecimento do PMI incluem o corpo de conhecimento para gerência de portfólios de projetos e o corpo de conhecimento para gerência de programas (conjunto de projetos relacionados em um tema).
• SWEBOK: Iniciativa de grande qualidade do IEEE, traz um excelente conjunto de referências para informações primárias sobre requisitos, desenho, construção, implementação, qualidade de software, gerência de projeto, processos de software, ferramentas e métodos.
• BABOK: Corpo de conhecimento para modelagem de processos de negócio do Instituto Internacional de Analistas de Negócio.
• EABOK: Corpo de conhecimento de arquiteturas corporativos do MITRE. Outros corpos de conhecimento sobre arquitetura corporativa incluem o DODAF (do Departamento de Defesa Americano), MODAF (Governo Inglês), o SEI Feature Oriented Domain Analysis, o TOGAF ( do Open Group) e talvez o mais conhecido deles, o Zachman Framework.
• Usability Body of Knowledge: Corpo de conhecimento de usabilidade da associação de professionais de usabilidade.