finito

Tag: SOA

  • Lean Architecture

    Lean Architecture

    Autores: James O. Coplien e Gertrud Bjørnvig. Gertrud tem mais de 20 anos de experiência em desenvolvimento de sistemas e é especialista em requisitos Ágeis. James é pioneiro em projetos OO, padrões de arquitetura e desenvolvimento Ágil de software. É autor, dentre outros títulos, de “Organizational Patterns of Agile Software Development” (Prentice-Hall, 2004).

    Editora: Wiley (2010).

    Site: LeanSoftwareArchitecture.com

    Do que se trata: Arquitetura de Software, pensada e construída segundo princípios Lean e Agile.

    Indicado para: Arquitetos, Desenvolvedores e afins. Sim, eu entrei de gaiato no navio (porque há tempos não arquiteto nem programo). Mas gostei do que vi, como testemunho abaixo.

    Contra-indicações: Quem não conhecer o mínimo de OO, arquitetura de software e que tais sentirá uma certa dificuldade. Quem acha que arquitetura é burocracia, BDUF ou conversa pra boi dormir terá dois tipos de reação: espanto (positivo) ou um notável desconforto. Indiferente, acho que ninguém fica.

    Breve resenha: Eu não pego um livro (técnico) que não fale sobre o que precisa ser feito e/ou gerenciamento desde os idos de 2005 e 2006, quando cismei de estudar e falar sobre SOA, Reuso e afins. Acontece que o choque do livro anterior, “Management 3.0“, foi forte demais. Vai demorar para outro livro sobre o tema me abalar tanto. Resolvi mudar de assunto. E decidi que era hora de ver o que o “outro lado” anda fazendo. Não pesquisei muito até decidir pelo livro do Coplien e da Gertrud. Mesmo sabendo que encontraria linhas de código (em Java, C++, Ruby e outras) e conceitos que talvez fossem grandes demais para minha cabecinha.

    O que me chamou a atenção foi exatamente a presença da Gertrud como co-autora, dada sua especialização em requisitos. Desconfiei que não seria um livro tradicional sobre arquitetura de software. E estava certo. Vou arriscar um resumo em um parágrafo:

    Se você é verdadeiramente Ágil, a arquitetura projetada por ti deve saber acomodar mudanças. Não só em tempo de projeto, mas durante todo o ciclo de vida de um sistema. Para tal, desde o início você deve saber distinguir coisas que mudam com menos frequência daquelas que mudam ‘quase todo dia’. Os autores sugerem uma divisão bem simples: O-que-o-Sistema-É é uma parte mais estável, é a forma – o pensamento do usuário; O-que-o-Sistema-Faz é a porção mais dinâmica, mais suscetível a mudanças, é o comportamento – a ação do usuário. O respeito pelo ‘modelo mental do usuário’ e a preocupação em fazer com que todos os elementos da arquitetura sejam representações fiéis deste modelo guiam todo o livro. Os letrados a antenados já devem ter desconfiado que esse papo todo desemboca no uso dos padrões MVC-U (Model-View-Controller-User. Não se incomode, é o mesmo velho MVC demonstrando simpatia pela parte mais importante do problema) e seu novo complemento chamado DCI (Data, Context and Interaction), duas crias de Trygve Reenskaug.

    Resumo dado, tempo para outras considerações. Sim, esse papo de “representação fiel do modelo mental do usuário” rola, sem muito sucesso, desde a segunda metade da década de 1960 (quando surgiu OO). E sim, letrados e antenados não devem ver muito valor no livro. Como eles não são tantos assim, como atestam as aplicações que vemos por aí, o livro deve atrair um bom público. O público nerd, tratado exatamente desta maneira no texto, deve se satisfazer com as dezenas de páginas (de um total de 357) com puro código. Além de três capítulos nomeados “Coding it Up …”, o livro dispõe de seis apêndices tratando um mesmo exemplo em Scala, Python, C#, Ruby, Qi4j (segundo os autores, a melhor forma de implementar DCI em Java) e Squeak. E, como já coloquei, C++ e Java não são ignoradas. Se eu curti esse tanto de código? Olha, deu pra lembrar porque não programo mais. Mas, o código é bonito, elegante.

    Aliás, a proposta como um todo é bonita (e ver Beleza em coisas assim é atestado inconteste de que um pouco de sangue nerd ainda corre nestas veias). Sempre avalio uma sugestão de arquitetura através da tríade vitruviana: firmitas (robustez), venustas (beleza) e utilitas (utilidade / funcionalidade). Os autores, pelo menos na teoria, passam no teste do Vitruvius. E insistem em nos lembrar, pelo menos uma dúzia de vezes, a Lei de Conway.

    Para a turma d’o que precisa ser feito: Além do primeiro capítulo, uma Introdução, outros quatro ‘falam’ com a turma do negócio, analistas, donos de produtos e afins. São eles: “3 – Stakeholder Engagement“, “4 – Problem Definition“, “5 – What the System Is, Part I: Lean Architecture” e “7 – What the System Does: System Functionality“. Vou destacar os pontos que mais me chamaram a atenção.

    Gostei muito da separação incondicional de o-que-o-sistema-É de o-que-o-sistema-FAZ. Quando estudamos um negócio, também devemos ter esse tipo de preocupação. Separamos a Visão da Estrutura da Visão dos Processos, cientes da maior complexidade e volatilidade da segunda. Costumo dizer em meus treinamentos que a Visão dos Processos ocupará, no mínimo, 70% do tempo de um analista de negócios. Acontece que a aplicação tradicional ou indisciplinada de conceitos OO, em determinado momento, mistura tudo. Através do padrão DCI essa separação é sempre respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto é uma representação fiel de… um Caso de Uso!

    Qual não foi minha surpresa quando vi os autores ‘ressuscitando’ as Especificações de Casos de Uso. Segundo eles, de forma bem direta, o mundo Ágil reinventou a roda com as Histórias de Usuários e todos os seus ‘complementos’ (Mapas de Histórias, Dependências, Restrições, Test Cases etc). Casos de Uso oferecem, segundo os autores, consolidação de todas as informações necessárias para a construção d’o-que-o-sistema-FAZ. Há muito em comum entre a sugestão do livro e o modelo de casos de uso que aplico. Por exemplo: “O Fluxo Principal não deve ter mais que 7 passos!”; “Questões sobre interface do usuário e projeto do sistema são melhor representadas em outras ferramentas, não em casos de uso“. E por aí vai. E vai tão longe que merecerá um artigo específico.

    Por ora, fica minha curiosidade em saber como os desenvolvedores tupiniquins estão vendo a proposta. Fiz uma breve pesquisa no Google e em alguns grupos de discussão e não vi uma única menção ao termo DCI. Como a comunidade Ruby só faz crescer por aqui, pensei que acharia algo. Mas talvez eu não tenha procurado direito. Lá fora as reações são variadas e algumas bem iradas, como mostra esta thread. Aliás, estou para ver o dia em que novas ideias de nossa área não virarão um Fla X Flu.

    Enfim, duas coisinhas que me incomodaram: i) Não há um único diagrama UML no livro. Mesmo que os autores defendam fervorosamente a ‘modelagem com código’, deveriam entender que um ou outro diagraminha poderia facilitar a compreensão de alguns conceitos; ii) SOA morreu? Sinceramente, não esperava ler um livro sobre arquitetura de software escrito em 2010 que praticamente passa em branco pelo assunto. Os autores até justificaram no início do livro a ausência, mas não foram muito convincentes. Ou, de fato, SOA morreu?

  • Sobre Legados e o Incêndio Nosso de cada Dia

    Eu pagaria para ver estudos mais recentes sobre o rateio do orçamento de TI em médias e grandes empresas. Lá no já distante século passado era mais ou menos padrão a destinação de 70% ~ 80% do total das verbas para a manutenção das operações. Desconfio muito que este número esbarre hoje nos 90% ou 100%. Projetos novos e upgrades, que um dia mereceram algo entre 20% e 30% do orçamento total, atualmente ou são bancados pelas áreas de negócios ou simplesmente postergados. Não por acaso o Windows XP, por exemplo, ainda predomina em várias organizações¹. Alguns podem dizer que a nova política é reflexo da falta de confiança na organização de TI como um todo. Não estão de todo errados. Mas não tocam nas raízes do problema.

    O tema começou a me chamar a atenção quando percebi que vários participantes do FAN não eram analistas de negócios (AN’s) de fato, mas luxuosos atendentes de help desk. Seu dia-a-dia não é o apoio a novos projetos mas sim o tratamento de demandas de manutenção em sistemas. Por favor, não estou dizendo que demandas de manutenção não mereçam a alocação de AN’s. Algumas poucas, que de fato representam mudanças no negócio, justificam isso. Acontece que a grande maioria delas, independente do tipo ou porte do negócio, refere-se exclusivamente aos sistemas. Pior, são fruto de sistemas de baixíssima qualidade técnica.

    O imenso e incomensurável backlog de manutenção é o inferno de um sem número de departamentos de TI. Ao que tudo indica, muitos acreditaram que os AN’s representariam uma boa resposta. Caro engano. Tão dispendioso quanto aquele de um famoso instituto que registra “recomendações” numa famosa publicação tupiniquim: em um de seus últimos artigos, “ele” falou que estruturas de projeto e de manutenção não precisam ser separadas. E que tal divisão poderia resultar em acidentes. Céus!

    Quando projetos e manutenção começam a concorrer pelos mesmos recursos, e dado nosso “tudo é para ontem”, é claro que a manutenção – a necessidade “indriblável” de apagar de incêndios – sempre prevalecerá. Resumindo: se a empresa nutre uma mínima preocupação com seu futuro, deveria ter uma unidade que cuide exclusivamente de novos projetos. E é aqui que os AN’s podem provar seu valor e justificar seus custos.

    .:.

    Mas, como antecipei lá nas categorias deste artigo, eu não quero falar apenas sobre a análise de negócios. Quero aproveitar a oportunidade para tocar n’outro tema caro e meio raro (por aqui): arquitetura. Já acreditei que SOA (Arquitetura Orientada a Serviços) era uma excelente resposta à crescente demanda por flexibilidade e agilidade. Bom, ela segue excelente. Mas está longe, muito longe de ser uma resposta universal. Muitos daqueles sistemas que conhecemos como “legados” são tão feios, frágeis e gambiarrados que impedem que o “botox” SOA surta algum efeito. Daí que de uns tempos pra cá resolvi ressuscitar um conselho daquele mesmo instituto que critiquei acima: “aposente 2 ou 3 sistemas legados por ano. Ponto.”

    O conselho é anterior às ondas EAI (Enterprise Application Integration) e SOA. Mas a cada dia se torna mais necessário e urgente. O fato é que há um imenso abismo entre a arquitetura tecnológica de vários sistemas legados e as demandas atuais. A ploriferação de modernos canais digitais e a crescente pressão que eles excercem sobre aplicações antigas justificam a incorporação desse discurso de urgência. E é importante notar que não estou falando apenas de coisas de museu como Cobol², Oracle Forms, Delphi, Visual Basic, Fox ou Clipper. Tudo o que nasceu na primeira geração da Internet deve ir para o lixo. Devemos aceitar o fato de que nossos primeiros sites e aplicações Web, mesmo aqueles com “apenas” 5 ou 6 anos de vida, serviram para aprendizado. Mas hoje são pesadíssimas âncoras que impedem nossa evolução. Cada centavo gasto em sistemas antigos (feios, frágeis e gambiarrados) é centavo jogado fora. Mesmo que o centavo seja contabilizado em rubricas chiques como SOA, BPM, BI e afins.

    A aposentadoria de aplicações de negócios está longe de ser uma coisa trivial. São raríssimas as empresas que utilizam um processo de gerenciamento do ciclo de vida de sistemas³. Nós desenvolvedores só falamos, através de nossas mágicas metodologias, do ciclo de vida de projetos. Pouquíssima ou nenhuma atenção é dada ao sistema entregue. Até o dia seguinte ao término do projeto, quando aquele sistema vira “legado” e um novo foco de incêndio a ser combatido diariamente.

    .:.

    Auren Hoffman escreveu um excelente artigo sobre “Ser Bom em Matar Coisas“. Um bom líder de TI deve saber hora e forma de matar (ou aposentar) seus sistemas. Como já falei demais, guardarei “hora e  forma” para futuros artigos. Inté!

    .:.

    Observações:

    1. O colega Saulo Arruda citou, num comentário lá no Graffiti, que uma grande empresa de Telco ainda demanda projetos em ASP (não .Net) com uso incondicional do Windows 2000 e IE6. Falou também de uma montadora com a mesma arquitetura. Qualquer coisa feita em ASP deveria ir para o lixo incondicionalmente. E escrever projetos novos em ASP é o mesmo que “tentar apagar incêndios com etanol”, para surrupiar e adaptar um antigo dito de Fred Brooks (utilizado em outra situação, é claro).
      Pedindo licença aos letrados, tentarei explicar aos leigos porque ASP (Active Server Pages) é uma das coisas mais medonhas e perigosas já inventadas em nossa área. Pensem num texto qualquer escrito de maneira desestruturada e acidental em três dialetos distintos, todos misturados. Três dialetos mais ou menos assim: a língua de participantes do BBB, a linguagem cifrada que a geração Y usa em sites de relacionamento mais um manuscrito original de um Jack Kerouac bêbado. ASP é assim. E na mão de programadores eXpertos vira poesia pura.
    2. Há quem diga que Cobol se modernizou. Tem também aqueles que defendem que ainda não inventamos nada para substituí-lo em grandes corporações (o que me faz pensar se Google, Amazon e afins são pequenas). De qualquer maneira, como não vejo a carinha dele (Cobol) há muito tempo, deixo a dúvida no ar.
    3. Para falar a verdade, só conheço uma proposta formal de processo que prevê o gerenciamento do ciclo de vida de sistemas. Ele atende pelo nome EUP (Enterprise Unified Process) e foi criado por Scott Ambler. Sim, podemos dizer que é um irmão bastardo (e ainda não reconhecido) do RUP.
    4. A imagem utilizada, Tändsticka, é do brandbild e foi liberada como CC-by, por isso está aqui.

  • Quem Paga a Dolorosa?

    O negócio não interessa. O que interessa, isso sim, são os maravilhosos badulaques, frameworks, caixinhas-caixões e código. Adoramos esquecer que, no final das contas, quem ‘morre com a dolorosa’ é o tal do negócio. Há mais de uma década o Gartner estampa no Top 5 das preocupações dos CIO’s: “Alinhamento Estratégico“. Perdemos o novelo ou o papo sobre alinhamento não é sério?

    É claro que é sério. Na maioria das empresas é. O problema é mudar uma cultura de décadas de “cara-caixa-preta”. Não são poucos os exemplos de modelos, processos e metodologias que colocam TI como um fim e não um meio. Não por acaso, a Análise e Modelagem de Negócios é a disciplina mais ignorada em projetos de TI, particularmente em iniciativas para desenvolvimento ou implantação de sistemas. É comum que a Modelagem de Negócios seja vista como papo furado, desperdício ou algo do tipo.

    .:.

    A edição 903 da revista Exame (10/out/2007) apresenta uma série de artigos especiais. Mostra como o Brasil mudou nos últimos 40 anos. Alguns números são tão espetaculares que nos fazem questionar essa eterna mania de achar que tudo por aqui está ou dá errado. Ops… o assunto mudou ou o editor viajou? Não.

    Pense nas empresas que estão aí há 40, 20 ou 10 anos. Como elas passam por tantas ondas de mudanças? Processos de negócio envelhecem e adoecem. Quando o mesmo ocorre com recursos da empresa, máquinas por exemplo, eles são trocados. E o que acontece com os processos de negócio?

    Em grande parte das vezes eles são ajustados ou remendados. Várias empresas optaram pela implantação de ERP’s – grandes sistemas corporativos que em seu conceito original propunham a adoção de novos processos. Grande parte dos problemas com a adoção desse tipo de solução acontece exatamente na diferença entre processos existentes e os novos desenhos.

    Mas a questão está longe de ser uma exclusividade das empresas mais velhas. Mesmo empresas muito novas convivem diariamente com a pressão por mudanças em parte de seus processos de negócio. A demanda ocorre, particularmente, nos processos primários – aqueles que lidam diretamente com o mundo exterior, com os clientes.

    Processos ultrapassam as fronteiras de uma organização. Para frente, na direção dos clientes, e para os outros lados, no sentido dos fornecedores e parceiros de negócios. Na economia atual, têm nítida vantagem as empresas que oferecem processos abertos e flexíveis. Então, testemunhamos o surgimento de propostas muito boas para a realização dos requisitos de abertura e flexibilidade, notadamente SOA (Arquitetura Orientada a Serviços) e BPM (Gerenciamento de Processos de Negócio).

    Mas, como quase sempre ocorre em TI, caixinhas e ferramentas monopolizam discursos, press-releases e budgets. Passa desapercebido o fato de que processos remendados, velhos e doentes seguirão remendados, velhos e doentes numa SOA ou sob os cuidados de um BPMS. É muito velha a máxima que diz que “engessamos processos equivocados”. Tão antiga quanto nossa teimosia em ignorá-la.

    .:.

    A Análise e Modelagem de Negócios, uma das duas macro-disciplinas que formam o corpo de conhecimentos dos Analistas de Negócios (AN’s), está longe de ser papo-furado ou desperdício. Na realidade, quando bem executada, pode ser a diferença entre um projeto de sucesso e o total fracasso.

    A correta compreensão dos requisitos do negócio – seus objetivos e as metas específicas de seus processos – possibilita que projeto e produto tenham um horizonte e escopo bem definidos. Por isso a modelagem de negócios é bem mais que o mapeamento de processos. Ela pode compreender o estudo da estratégia da empresa, suas oportunidades e limitações, estrutura e relações.

    O que não pode significar, de maneira alguma, que projetos de TI devem ficar ‘congelados’ por um bom tempo, aguardando a realização da tal Modelagem do Negócio. Trata-se de um mito bastante comum que acompanha a disciplina. Uma primeira visão, a primeira iteração, pode demandar apenas alguns dias. E ela ocorre de forma simultânea com sua co-irmã, a Engenharia de Requisitos (a outra macro-disciplina que forma BoK do Analista de Negócios, aquela que mereceu maior atenção do BABoK).

    Ao incorporar práticas de Análise e Modelagem de Negócios em seus processos para desenvolvimento ou implantação de sistemas de informação, a organização fortalece equipes e projetos. Indica que está falando sério quando fala em alinhamento estratégico. Entende que o negócio é tudo o que importa. Afinal, quem paga a dolorosa?

    .:.

    Modelagem de Negócios é o primeiro módulo do curso para Formação de Analistas de Negócios, que o finito realizará em conjunto com a Tempo Real Eventos. Conheça mais detalhes sobre o curso, e veja aqui o seu conteúdo programático.

    .:.

  • D.E.V.A.G.A.R.

    Como apresentei no post anterior, DEVAGAR é um acrônimo para um conjunto de princípios que deveriam nortear um processo de desenvolvimento ‘business-centric’. Confesso, não deixa de ser uma provocação. E um contra-ponto ao ABCDEF que, segundo seus autores, seria ‘business-centric’. Na minha opinião, mais que ‘business-centric’, aquele conjunto de princípios – que, aliás, é muito legal – é mais ‘agile-manifesto-centric’ ou, em outras palavras, ‘developer-centric’.

    Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

    D)emonstrar Valor de maneira Iterativa
    Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

    E)ntender (e Melhorar) o Negócio
    É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

    V)alorizar os Ativos de Software
    Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

    1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
    2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

    A)daptar o Processo
    Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

    No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

    G)erenciar Requisitos (e Mudanças)
    Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

    A)tacar os Riscos
    Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

    R)espeitar os Usuários
    É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

    Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

    .:.

    Notas:

    1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
      O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
    2. Object Solutions – Managing the Object-Oriented Project
      Grady Booch. Addison-Wesley (1996).

    .:.

  • Surpresa

    Abro o workshop e o livro falando do Analista de Negócios (AN), dizendo que ele praticamente não existe. Profissão ou função mal definida, muito mal apresentada e representada. Mas reforço: ao lado do Arquiteto (ou Arquiteto Corporativo), é a profissão mais promissora da área de TI. Aposta que faço há algum tempo.

    Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que “não via utilidade nos AN’s”.

    Contei a “estorinha” no workshop e muitos pegaram carona na provocação: “você acredita nos AN’s e em sua aposta?” Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

    “Abrir a ‘caixa preta’ que é a organização de TI das empresas”
    – Gilson Silva

    “Alinhar TI com o negócio”

    • “O Alinhamento deve mostrar evoluções no plano de negócios”
    • “O Alinhamento se mantém atualizado na medida em que o negócio evolui”
    • “O Alinhamento ultrapassa obstáculos aos seus propósitos”
    • “O Alinhamento é planejado”

    – Paul Strassmann

    E aí vieram SOA, BPM, ITIL, SOX… todas buscando, de uma forma ou de outra, o tal “alinhamento”. Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN’s e AN’s de TI são “negócios” diferentes estão um tanto equivocados . Negócio é negócio. Ponto.

    .:.

    Momento “Catorze Zero Meia”

    Leitores do finito interessados em participar da próxima edição do workshop “Formação para Analistas de Negócios” acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

    Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

    1406 + “modelito vivarina”: todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

    “Desgraça pouca é bobagem”, como a gente costuma falar aqui nas Geraes.

    .:.

    * Válido para os 20 primeiros.
    (ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas…)

    .:.

    1. Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul…
    2. The Squandered Computer
      Paul A. Strassmann – The Information Economics Press (1997).
    3. UML for the IT Business Analyst
      Howard Podeswa – Thomsom / PTR (2005).
    .:.

  • O Analista de Negócios e o tal BABoK

    Faz pouco tempo que descobri o BABoK (Business Analysis Body of Knowledge). Quem cuida dele é o IIBA (International Institute of Business Analysis). A descoberta aconteceu por acidente, no meio das minhas pesquisas. Usando o Google, não consegui achar nenhuma referência em língua portuguesa. Estranhei. Afinal, a versão atual (1.6) está disponível para download desde 12/jul do ano passado. A versão 2.0 está programada para este trimestre. Mas, como escrevi no meu material, “o analista de negócios não existe. Particularmente aqui no Brasil”. Normal. Quantos gerentes de projetos existiam há uns 10 anos? E quem conhecia o PMI?

    O IIBA segue os passos do PMI. Ou seja, lança um ‘guia para o corpo de conhecimentos’ e, na cola, uma certificação. Tenho minhas restrições ao formato, mas elas ficam para outra hora. O lado bom é que a iniciativa pode ajudar a divulgar e, de certa forma, consolidar a profissão. Em tempos de altas ondas (SOA e BPM), passa da hora de percebermos que o Analista de Negócios desempenha funções cruciais.
    .

    .:.


    Mas o BABoK me assustou um pouco e decepcionou um tanto. Ainda não vi as alterações previstas para a versão 2.0, mas a versão 1.6 cobre, na minha opinião, apenas 50% do trabalho de um AN. Dos seus 8 capítulos, 5 cobrem exclusivamente as atividades de planejamento, desenvolvimento e gerenciamento de requisitos. O gráfico abaixo ilustra as áreas de conhecimento cobertas pelo BABoK:

    “Enterprise Analysis”, segundo capítulo do BABoK, é descrita como “uma coleção de atividades pré-projeto que servem para capturar uma visão futura do negócio, formando assim uma base a a elicitação de requisitos e para o desenho da solução “.

    Como já comentei aqui, e talvez seja uma falha minha, mas não consigo dissociar a Modelagem de Negócios da Engenharia de Requisitos. Lógico, são duas disciplinas diferentes. Mas elas compartilham “momentos”, independente do modelo de processo utilizado. E o BABoK não fala nada sobre Modelagem de Negócios. Se ela não é uma responsabilidade do AN, então é de quem?

    Quero crer que, com a demanda gerada pelas ‘ondas’ BPM e SOA, o BABoK passe a contemplar atividades para modelagem de negócios e de processos de negócios em suas futuras versões. Melhor seria se a incorporação fosse motivada pela percepção de que o trabalho do AN não se restringe à coleta, análise e documentação de requisitos.

    .:.

    Como mostra o conteúdo programático do workshop promovido pela Tempo Real Eventos, a primeira metade do evento tratará exclusivamente da modelagem do negócio e seus processos. Apresentarei algumas práticas sugeridas pelo BABoK na segunda parte do evento.

    .:.

  • Para que serve o Analista de Negócios?

    A pergunta acima, colocada num fórum de discussão há pouco tempo, foi o último empurrão que eu esperava. Volta e meia ouvimos que problemas com a compreensão do negócio e com requisitos respondem por cerca de 80% das causas das falhas em projetos. Com uma freqüência ainda maior, somos comunicados de que uma das maiores prioridades das áreas de TI nos últimos tempos é o alinhamento com o negócio. Mas, por incrível que pareça, um dos profissionais mais importantes no atendimento dessas duas demandas é pouco conhecido. Afinal, quem é o Analista de Negócios (AN)? Qual a sua formação? Quais as suas habilidades? E, mais importante, quais as suas responsabilidades em uma organização de TI e em projetos para desenvolvimento ou implantação de sistemas?

    Há muito tempo o tema me persegue. Em 98, logo que cheguei em Sampa, entrei numa briga surreal para conseguir justificar, contratar e treinar 2 Analistas de Negócios. Minha primeira palestra aberta, realizada nos idos de 2002, foi sobre um dos dois principais conjuntos de disciplinas que devem ser dominados por um AN: a Engenharia de Requisitos. Nos últimos tempos, com a confirmação das propostas SOA e BPM, a importância e a necessidade de Analistas de Negócios cresceram ainda mais. Ainda assim, suspeito que pouco se sabe sobre eles e suas funções.

    Por isso comecei a compilar minhas experiências e meus achados com o intuito de lançar um workshop e um treinamento. Eles apareceram no meu ‘cardápio’ deste ano. O primeiro workshop aberto, chamado “Formação para Analistas de Negócios“, será realizado pela Tempo Real Eventos. Acontecerá no próximo dia 19/junho (uma terça-feira), em Sampa. Dura o dia todo e tem 50 vagas.

    Update: a data mudou. O workshop será no dia 20/junho (quarta-feira).

    .:.

    Há tempos um pessoal mais próximo me cobra: “por que você não escreve um livro?”. Minha resposta era sempre a mesma: “não tenho assunto”. Caramba, nesta semana completo 3 anos de blogs. Só no Graffiti são mais de 1400 posts. Mas eu realmente nunca tinha achado uma “lacuna”. Não iria “chover no molhado” com mais um título sobre gerenciamento de projetos, apesar de achar que existem boas oportunidades e áreas pouco cobertas (TOC, OpenUP, Scrum), particularmente em língua portuguesa. Também não tenho como escrever sobre reuso e gerenciamento de ativos de software. Careço de mais e melhores experiências.

    Mas quando vi que a minha apostila para o curso “Formando Analistas de Negócios” estava ficando grande demais – o curso tem 80 horas – a ficha caiu. Caramba, está aí meu primeiro livro. Era tão óbvio, estava tão ‘colado no nariz’, que quase perco a oportunidade.

    Utilizarei um ‘draft’ do livro como apostila, tanto para o workshop quanto para os treinamentos. Será uma forma legal de validar os escritos – um tipo de “versão beta”. Alguns exercícios e exemplos que pintarem nos eventos devem ser incorporados ao texto final. E, claro, utilizarei este blog para breves pesquisas, sugestões, críticas e também para documentar o andamento do processo.

    Conteúdo programático e outras informações sobre o workshop já estão no site da Tempo Real Eventos. Se quiserem conversar comigo sobre o evento ou o livro, fiquem à vontade.

    .:.

  • UML e BPMN: Mutuamente Exclusivas?

    Nossa área parece ter uma ‘quedinha’ especial por polarizações. Algumas são necessárias (REST vs SOAP). Seriam menos chatas se fossem breves e mais produtivas (Open Source vs Software Proprietário ou Agile vs Classic). Mas alguns embates parecem não fazer nenhum sentido. Um que descobri só recentemente é o duelo UML ou BPMN. Taí uma discussão muito ‘nada a ver’, na minha opinião. Vamos aos fatos.

    A UML, particularmente sua versão 2.0, é muito extensa? Muito genérica? Sim. Mas isso não é um acidente – um defeito. O ponto mais forte da UML, fora a coerência e legibilidade de seus artefatos, é a sua extensibilidade. Qualidade óbvia, já que ela é genérica. Tipo: “não faz mais do que a obrigação”. Várias extensões foram desenvolvidas desde o nascimento da linguagem, no final da década passada. Uma delas é muito relevante para esta discussão: a EPBE, ou “Eriksson-Penker Business Extensions“.

    Apresentada por Hans-Erik Eriksson e Magnus Penker no livro “Business Modeling with UML” (Wiley, 2000), a EPBE cobre todos os aspectos da modelagem de negócios. Ou quase todos. É curioso, por exemplo, que ela não contemple diagramas de casos de uso. Na visão dos autores, tanto o diagrama de casos de uso quanto os diagramas de componentes e de distribuição (deployment) “são utilizados na análise e projeto de sistemas de informação, mas são pouco relevantes na modelagem de negócios”. Por não conseguir dissociar a modelagem de negócios da engenharia de requisitos (falha minha), coloquei aquele “quase” acima.

    Mas a EPBE realmente cobre o essencial na modelagem de negócios, estruturando-se em torno de 4 visões:

    • Visão do Negócio: uma visão geral do negócio, destacando aspectos estratégicos e táticos (problemas a combater ou oportunidades a aproveitar);
    • Processos de Negócio: mostra a dinâmica da organização, inclusive seu relacionamento com entidades externas.
    • Estrutura do Negócio: apresenta a estrutura da organização, a divisão de recursos e a carteira de produtos e/ou serviços;
    • Comportamento do Negócio: o comportamento individual de cada recurso ou processo no modelo do negócio.

    Apenas nesta breve descrição já fica claro que não é possível comparar UML com BPMN. Seria algo como comparar uma bela melancia com uma simpática jaboticaba. BPMN, como o próprio nome indica, é uma Notação para Modelagem de Processos de Negócio. Ou seja, cobre apenas 1/4 do que é possível realizar com a UML devidamente extendida. Mas a questão não se encerra aqui.

    Muitos lembrarão: “ah, mas o debate verdadeiro é BPMN versus o Diagrama de Atividades da UML”. De forma simples e direta: não há nada que eu faça em BPMN que eu não consiga representar em UML. Sim, com BPMN eu consigo diagramas mais ‘bonitinhos’, mas acho que este, definitivamente, não é o caso. Agora vamos elencar algumas coisas que conseguimos representar em UML e que não estão previstas na especificação BPMN:

    • Know-Why: um processo de negócio bem documentado justifica sua existência. Precisamos conhecer os objetivos e metas atrelados àquele dado processo. É fácil extender o diagrama de atividades para armazenar essas informações. Mas para que reinventar a roda? O Diagrama de Processos da EPBE já prevê e obriga a inserção desses atributos do processo.
    • Métricas: apelando para a batida máxima, “não se gerencia o que não se mede”. Pode não ser verdadeira para tudo mas, em se tratando de processos de negócio, a afirmação é mais que verdadeira. Cada tipo de processo pode ter um conjunto muito específico de medidas relevantes. Mas existem duas que deveriam estar em todo mapa de processo: Custo e Tempo de Ciclo. Para conhecer os custos de um processo é imperativo que mapeemos todos os recursos utilizados em sua realização. BPMN simplesmente ignora-os.
    • Informação: na EPBE as informações são tratadas como um tipo de recurso que municia um processo. BPMN, como dito anteriormente, não se preocupa com recursos.
    • Pessoas: ou stakeholders, também são recursos na notação EPBE.
    • Requisitos: sim, a EPBE também não contempla artefatos para a captura e gerenciamento de requisitos. Mas ela, ao contrário da BPMN, não ignora sua existência. Há um diagrama muito útil na EPBE, o Diagrama de Linha de Montagem (Assembly Line – veja exemplo abaixo), que permite associar processos de negócios (diretamente de seu respectivo diagrama), com pacotes de objetos (ou serviços!) e casos de uso. Ou seja, consigo rastrear – navegar entre o domínio do problema e o domínio da solução. Com uma vantagem imbatível: usando a mesmíssima linguagem: UML.

    Conclusão

    Não é o caso de simplesmente dizer que BPMN não é útil. Suas boas idéias, particularmente o maior detalhamento de alguns elementos (só obtidos através do uso de estereótipos no Diagrama de Atividades), podem e devem ser aproveitadas. BPMN e UML estão sob os cuidados do OMG. Acredito que num futuro próximo veremos uma mixagem das duas especificações. Ou então a transformação de BPMN em uma extensão da UML. Algo fácil e natural.

    Se BPEL é o seu sonho de consumo, saiba que já existem tradutores de diagramas de atividades para ela. Portanto, BPEL não é desculpa para a adoção da BPMN.

    Por fim é arriscado mas necessário dizer que não podemos confundir Modelagem de Negócios com a Modelagem de Processos de Negócios. A primeira é uma disciplina muito mais ampla e complexa. Que é muito importante em projetos para desenvolvimento de sistemas. E nada menos do que VITAL em iniciativas SOA.

  • SOA: As Mudanças Culturais

    No mundo de TI, tudo que é realmente novo gera mudanças culturais. SOA propõe e depende muito de uma série de mudanças culturais. A forma como uma organização percebe e gerencia seus processos de negócio talvez seja uma das mudanças mais visíveis – mais claras. Mas existem outros tipos, relativamente menores, que também são críticos para o sucesso da iniciativa.

    Alguns princípios que regem o gerenciamento de projetos, por exemplo, precisam ser revistos. Recentemente aconteceu uma boa discussão no grupo CMM-Brasil que envolveu, entre outras coisas, o balanceamento do ‘trio de ferro: Preço x Prazo x Escopo’. Resumindo: quem defende uma abordagem Ágil* diz que, após a negociação e contratação formal, o único item que deveria variar na equação acima é o escopo. Deveríamos eliminar algumas funcionalidades com o intuito de manter intactos o valor e o prazo inicialmente acordados.

    De uma maneira geral, e não exclusivamente no caso de um programa SOA, a regra é questionável e polêmica. Agilidade combina com flexibilidade. E regras escritas em pedra não combinam com flexibilidade. Está aí um tipo de princípio que não deveria ser adotado no nível da organização. Alguns projetos podem exigir o total atendimento dos requisitos apresentados. Neste caso, clientes e usuários podem concordar com uma flexibilização dos preços e prazos apresentados. A negociação do(s) ponto(s) de variabilidade do ‘trio de ferro’ deveria fazer parte do acordo inicial, seja ele um contrato ou um convênio. Ao contrário do que foi dito naquela thread do grupo de discussão, não deixo de ser ágil porque concordei com a entrega de todas as funcionalidades requeridas por um cliente. Mesmo que isso signifique algum atraso em relação aos prazos acordados anteriormente.

    Agora, quando se trata especificamente de uma iniciativa SOA, a fixação do escopo como o único fator variável do ‘trio de ferro’ pode ser um engano ainda mais nocivo. Um engano bastante comum que, segundo Todd Biske, deriva de uma mentalidade ‘schedule-driven’. Vou surrupiar seus argumentos:

    Muitas organizações com as quais trabalho têm a tendência de ser ‘guiadas pelos cronogramas’ (schedule driven). Ou seja, o elemento menos flexível do projeto é o cronograma. Assim, a coisa que mais ‘sofre’ é o escopo. Infelizmente, não se trata do escopo propriamente dito e sim da diferença entre o caminho mais rápido (tático) versus o melhor caminho (estratégico). Se você está tentando implementar uma SOA, saiba que esse tipo de governança de TI tornará sua vida bem difícil. Você está premiando o sucesso do cronograma, não o sucesso da arquitetura.

    Todd encerra dizendo que se trata de uma “grande mudança cultural”. É sim, particularmente onde impera o imediatismo. SOA deve, de alguma forma, ser vacinada contra esse mal. E isso não significa, de forma alguma, deixar de ser ágil.

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

  • Ativos: Ciclo de Vida e Processos

    Seqüência de “Ativos: O Cofre e o Guardião“, capítulo da série “Gerenciando Ativos de Software“.

    Foto de Bryan Furnace.

    Antes que possamos falar especificamente sobre processos de desenvolvimento e administração de ativos, é importante entender o seu Ciclo de Vida. Quando nos preocupamos exclusivamente com o reuso, percebemos apenas duas atividades principais : o desenvolvimento de ativos (dos serviços, em uma SOA); e o desenvolvimento dos produtos / aplicações (ou meta-aplicações em uma SOA), que utilizam os ativos como blocos de construção. No entanto, se a intenção é o completo gerenciamento dos ativos de software, o desenvolvimento de ativos e aplicações é só uma parte do trabalho. Porque devemos gerenciar todo o ciclo de vida dos ativos. E este ciclo é composto por 5 momentos bastante distintos :

    • Identificação: a necessidade ou o potencial de (re)uso de um determinado ativo é identificado. Requisitos e restrições são levantados e a viabilidade de sua produção é estudada. Em um programa SOA, identificamos serviços.
    • Produção: momento no qual um ativo é produzido. Como veremos posteriormente, um ativo pode ser produzido no contexto de um projeto ou em uma unidade destacada especificamente para este fim.
    • Consumo: o ativo é (re)utilizado na construção de aplicações ou meta-aplicações.
    • Manutenção: etapa de duração indeterminada, existe enquanto o ativo estiver disponível para consumo (no repositório) ou em uso por uma ou mais aplicações.
    • Aposentadoria: quando um ativo é descartado, na maioria das vezes sendo integralmente substituído.

    Para cada momento no ciclo de vida de um ativo de software há um processo específico. A lista abaixo apresenta os processos e suas principais responsabilidades :

    • Identificação
      • Coleta e Análise de Requisitos
      • Análise do Negócio
      • Avaliação Custo / Benefício
    • Produção
      • Desenvolvimento do Ativo (ou Aquisição e Customização)
      • Testes e Qualificação
      • Classificação (aplicação etiqueta RAS)
    • Consumo
      • Busca e Avaliação do Ativo
      • Integração (desenvolvimento da aplicação)
      • Relatório sobre o (re)uso
    • Manutenção
      • Cadastramento do Ativo (catálogo e repositório)
      • Suporte ao Ativo
      • Administração e Suporte ao Repositório
      • Gerenciamento de Mudanças nos Ativos
    • Aposentadoria
      • Análise de (re)uso, redundâncias e oportunidades de melhoria
      • Preparação para descarte do Ativo
      • Remoção do Ativo

    É interessante notar que, apesar de algumas semelhanças, os processos acima não sobrepõem nem podem substituir um processo de desenvolvimento tradicional. As atividades listadas extrapolam as fronteiras de um projeto. E devem compor um Programa de Gerenciamento de Ativos (que pode ser um sub-conjunto de um Programa SOA). O diagrama abaixo relaciona alguns dos processos listados com o RUP :

    Reparem que a produção de ativos pode ser parte de um projeto ou uma responsabilidade de outro grupo (na parte inferior do gráfico). No entanto, essa possibilidade não deveria ser aceita em iniciativas de reuso sistemático nem em programas SOA.

    No primeiro caso, por tranferir para um projeto um conjunto de atividades (e respectivos custos) que raramente se justificam. A pulverização das atividades de produção também pode comprometer a qualidade dos ativos. Para a implantação do reuso sistemático, parece ser mais indicado que um grupo seja criado para tratar exclusivamente das atividades de produção.

    Em programas SOA, o cenário sinalizado pelo diagrama acima parece ainda menos factível. A divisão entre o desenvolvimento de ativos (serviços) e aplicações é de certa forma arbitrária. O desenvolvimento de cada serviço deve ser visto como um projeto em si, independente de seu porte. E em um projeto para a construção de uma meta-aplicação (puro consumo de ativos / serviços), a inserção da construção de um serviço em seu escopo pode significar aumento da complexidade sem nenhum benefício que o justifique.

    Distribuindo Responsabilidades

    Como vimos no capítulo anterior, as atividades de administração e suporte ao repositório, cadastramento de ativos e manutenção do catálogo são de responsabilidade do GBA (Gestor da Biblioteca de Ativos). Esta pessoa ou grupo deve ficar subordinada ao comitê que administra os ativos ou o programa SOA. As atividades de Identificação, Manutenção e Aposentadoria de ativos (serviços) seriam uma responsabilidade deste comitê gestor. É lógico que o porte da iniciativa (principalmente o número de ativos), é que determinará o tamanho desta estrutura. As atividades de suporte e melhoria dos ativos podem ser tratadas como pequenos projetos, e delegadas para a equipe de produção.

    Como foi dito anteriormente, é indicado que a equipe de produção seja uma entidade autônoma, principalmente em relação àquelas que desempenham atividades de consumo de ativos. Seguindo um padrão que caracteriza os serviços em uma SOA, o ideal é que todas as equipes sejam “levemente acopladas”.

    Sendo assim, temos um desenho que apresenta três grandes grupos de pessoas:

    • Gerenciamento de Ativos
    • Produção de Ativos
    • Consumo de Ativos

    .:.

    Os próximos 3 capítulos falarão sobre os processos de cada um dos 3 grupos acima. Aumentei consideravelmente o escopo deste trabalho, e por isso o prazo de 11/jan foi sumariamente desconsiderado. Nesta semana mesmo publiquei um breve “desvio” da série, para falar exclusivamente sobre a criação de uma (necessária) base de conhecimentos. Não a considerei uma parte desta série, mas é provável que ela apareça (devidamente ampliada e remodelada) na compilação final. Compilação que eu espero publicar ainda em fevereiro. O desvio que fui obrigado a realizar foi bem maior do que o artigo citado mostra: mergulhei na disciplina “Engenharia de Requisitos” para adaptá-la para programas de reuso e, principalmente, SOA. No próximo capítulo mostro meus achados.

    .:.

    Referências:

    1. Objects, Components, and Frameworks with UML – The Catalysis Approach
      Desmond F. D’Souza e Alan Cameron Wills
      Addison-Wesley (1999).
    2. Asset Lifecycle Management for Service-Oriented Architectures
      Grant Larsen e Jack Wilber
      IBM / The Rational Edge (2005).
      * O artigo original fala de 4 workflows. Adaptei a terminologia e inseri o momento “Aposentadoria”. Justifico as alterações no próximo capítulo.
    3. Practical Software Reuse
      Michel Ezran, Maurizio Morisio e Colin Tully
      Springer (2002).