finito

Tag: UML

  • Use Case 2.0: Você precisa dele?

    Use Case 2.0: Você precisa dele?

    Ivar Jacobson liberou, agora em dezembro, um pequeno livro eletrônico chamado “Use Case 2.0: The Definitive Guide“. Como ele mesmo alerta, não se trata de uma atualização da ferramenta. Afinal, “casos de uso ainda são casos de uso”. Mas o texto propõe alguns novos elementos – novos artefatos de trabalho. Este artigo pretende avaliar as principais alterações sugeridas comparando-as com alternativas já conhecidas.

    ?

    Apesar de toda a má fama que a acompanha, a ferramenta Caso de Uso continua sendo apresentada por muitos, inclusive este que vos escreve, como a mais eficaz no apoio às atividades de “descoberta e descrição dos requisitos funcionais de um sistema”. Os mal ditos sobre os casos de uso têm origem bem identificada. Em dado momento, entre o final dos anos 1990 e início do novo século, tentaram sofisticar demais a ferramenta. Modelos rebuscados e divisões artificiais e redundantes (fluxo disso, fluxo daquilo…) deram enorme contribuição. A gota d’água veio daquela parte da população que tem preguiça de pensar e adora templates repletos de badulaques. Pronto, estava criada a fama – justíssima, dados os casos criados – de que casos de uso eram muito complicados, de difícil elaboração pelos analistas, incompreensíveis para os usuários, detestados e consequentemente ignorados pelos desenvolvedores e distantes demais dos testers (provavelmente os únicos que, se tivessem a chance, talvez gostassem daquilo. Porque era melhor que nada!)

    O advento do Manifesto Ágil quase nos fez crer que Caso de Uso era coisa do século passado. Mas o que seria do mundo se não fossem os teimosos? Alistair Cockburn nunca abandonou os casos. Nem Ivar Jacobson, o pai da criança que agora nos apresenta essa releitura (escrita a seis mãos com Ian Spence e Kurt Bittner, autores de “Use Case Modeling” – Addison-Wesley, 2002).
    O que ela traz de novo a ponto de merecer o “2.0”? Antes disso, qual a motivação para uma nova versão?

    Os autores defendem que o Caso de Uso 2.0 é: Leve, Escalável, Versátil e Fácil de usar. Fica implícita a intenção de oferecer a versão remoçada da ferramenta como alternativa para as User Stories. Apesar de ilustrarem sua utilização até em um processo baseado no modelo waterfall. A falta de um comparativo entre User Stories e Casos de Uso, a exemplo do que fizeram James Coplien e Gertrud Bjørnvig em “Lean Architecture“ (Wiley, 2010), reduz o impacto da proposta. Mas, afinal, qual é a proposta?

    Jacobson reforça uma mensagem que já apresentava em seus tempos de Rational¹: “casos de uso são a cola de todo o ciclo de vida do processo “. Ou seja, eles “suportam a análise, projeto, planejamento, estimativas, acompanhamento e testes de sistemas”, além da captura de requisitos, é claro.

    Um mapa conceitual nos ajuda a entender todos os elementos da proposta e as relações entre eles. Peço desculpas pela redundância mas vou reescrever as partes que representam as maiores alterações (e, tentarei mostrar, os problemas da proposta).

    Os interessados (stakeholders): i) são as fontes dos Requisitos; ii) estão envolvidos e priorizam Casos de Uso; e iii) se comunicam contando Histórias.

    Até aqui tudo bem, até porque o mapa informa que: iv) Requisitos são capturados na forma de Casos de Uso.  Agora, como falamos aqui no interior, a porca torce o rabo (e a proposta se enrola). Porque é colocado que: v) Casos de Uso são explorados através da narração de Histórias; e vi) seu escopo é gerenciado e endereçado como um conjunto de Fatias de Caso de Uso (Use-Case Slice); que, por sua vez, vii) são identificadas (ou têm sua identificação facilitada) pelas Histórias.

    Essas histórias, a princípio, não têm nada a ver com as conhecidas User Stories (não citadas no e-book). Mas é impossível não perceber a intenção de fazer com que elas sejam elaboradas e tratadas da mesmíssima maneira proposta por Kent Beck (em “Extreme Programming Explained” – Addison-Wesley, 1999) e amadurecida por Mike Cohn (“User Stories Applied” – Addison-Wesley, 2004). Uma História, segundo os autores, pode ser qualquer coisa: requisito funcional ou não funcional, um trecho ou fluxo(s) do Caso de Uso, um requisito especial (?) ou ainda um caso de teste. E elas, genéricas (e versáteis assim), ajudariam na identificação de Fatias de Casos de Uso.

    Essas Fatias, apresentadas como “o elemento mais importante do Caso de Uso 2.0”, justificariam-se porque, segundo os autores, “precisamos de uma maneira de dividir casos de uso em conjuntos menores”. Li e reli o documento e continuo não acreditando que o próprio cara que inventou a ferramenta e seus naturais mecanismos de quebra (extensão) e organização esteja propondo tamanha confusão. Talvez meus neurônios não tenham percebido o fim das férias, sei lá. O fato é que a proposta, particularmente suas Histórias e Fatias, não parece fazer muito sentido.

    Um Caso de Uso é uma maneira mais (ou menos) ESTRUTURADA² de se contar e registrar uma história, um causo. Ele sempre possui um Fluxo Principal (ou Básico), uma sequência natural de interação entre um Ator e um Sistema onde todos os passos são bem sucedidos. Todas as variações ou desvios desta sequência principal são capturados e registrados na forma de Fluxos Alternativos (ou Secundários). Está aqui o primeiro mecanismo natural de ‘quebra’ de um caso de uso. Considero-o natural porque ele reflete a forma do usuário pensar. Uma vez registrado o comportamento mais esperado, como Fluxo Principal, a história se desenrola, por exemplo, em uma sequência de “e se”: “e se o cliente não tiver crédito”, “e se não houver estoque disponível” etc³. Casos de uso são tremendamente eficazes na “descoberta e descrição de requisitos funcionais de um sistema” exatamente porque permitem que uma história seja narrada e estruturada da forma mais natural (e próxima do usuário) possível.

    Por que, então, precisaríamos de outros mecanismos de quebra e organização? Para termos elementos ainda menores, que caibam em uma iteração de duas semanas ou em um post-it? Coplien e Bjørnvig, no capítulo 7 do livro citado acima, já haviam dado a receitinha: “qual é a diferença entre a lista de desvios (Fluxos Alternativos) e uma lista de requisitos, features ou User Stories? Quase nenhuma quando olhamos de perto. Podemos formular cada item da lista na forma de User Stories se isso faz com que a gente se sinta mais Agile“. Bem antes deles, no já distante ano 2000, Alistair Cockburn (em “Writing Effective Use Cases” – Addison-Wesley, 2000) já havia sugerido a derivação de uma Lista de Trabalho a partir de um Caso de Uso e seus diversos fluxos (Work List, págs. 172 – 174). Com itens que cabem perfeitamente em um post-it ou, falando mais sério, “cabem” em iterações (sprints) e facilitam o acompanhamento e gerenciamento de um product backlog ou algo parecido. Enfim, Casos de Uso nunca foram monolitos nem nunca levaram a uma situação “tudo ou nada”. Repito: nunca!

    Casos de Uso também podem ser vistos ou utilizados como uma “cola que une todas as etapas de um processo de desenvolvimento” desde a criação da UML (1995-1997) e dos derivados do Processo Unificado (1998~). Não creio que serão as sugeridas Fatias que farão, agora, a mágica de viabilizar tal visão. Porque a verdade é que nós nunca (ou, para pegar um pouco mais leve) raramente utilizamos Casos de Uso em toda a sua plenitude. O faremos agora que ele ficou um pouquinho mais complicado?

    ?

    Observações:

    1. Lê-se a primeira frase destacada na apresentação “Common Chalenges in Use Case Modeling”, de autoria de Ivar Jacobson e com logo da Rational Software (sem data de publicação).
    2. E é esta propriedade fundamental, o fato do Caso de Uso ser uma história ESTRUTURADA, sua principal diferença em relação a outras propostas, particularmente as User Stories. Um Caso de Uso, por natureza, é um conjunto de requisitos que faz todo o sentido para um usuário ou cliente. Um conjunto estruturado. Um conjunto que “entende” sua relação com os demais componentes da solução. Naturalmente.
    3. Destaquei o primeiro (Fluxos Alternativos) mas não cito acima os demais “mecanismos naturais de quebras” dos Casos de Uso. Porque aqui a porca torce o rabo de vez e, preciso admitir, alguns mecanismos não são tão naturais assim (Extends e Includes devem ter passado pela sua cabeça). Para não deixar o tema no limbo preciso dizer que Cenários (combinações de passos dos fluxos principal e alternativos) e Casos de Testes são derivados ou componentes de um Caso de Uso e representam outras formas de “quebra”. Serão mais ou menos naturais dependendo da forma como são elaborados.
    4. Slice of a Pumpkin Pie, foto que ilustra este artigo, é de autoria de TheCulinaryGeek.

     

  • Arquitetura do Negócio

    Sequência de “(Pensando alto sobre) Arquitetura Corporativa“. Naquele artigo vimos que a arquitetura corporativa pode ser vista como um conjunto formado por quatro camadas: Arquitetura do Negócio, Arquitetura de Aplicações, Arquitetura de Informações e Arquitetura Tecnológica. Sugeri que sua elaboração só faz sentido se iniciada pela Arquitetura do Negócio. É sobre este desenho o texto de hoje.

    .:.

    A representação de um negócio, qualquer  negócio, na forma de modelos não é nada trivial. Mesmo quando pequeno e aparentemente simples, um negócio pode apresentar particularidades que dificultam o seu desenho. Não se engane: a elaboração da arquitetura do negócio é um trabalho árduo. Por isso precisamos justificá-la de maneira adequada. Quais são as principais motivações para este trabalho? Relaciono abaixo aquelas que considero mais sensatas:

    • Entender o negócio – compreender todos os seus principais componentes (recursos, processos e regras) e as forças que os definem e guiam (objetivos);
    • Avaliar a prontidão de TI – e assim justificar o desenho de toda a arquitetura corporativa. Queremos aqui mostrar o alinhamento (ou descobrir buracos) entre o negócio e todas as peças, trecos e trampos oferecidos pela TI.

    A primeira razão, “Entender o negócio”, pode ser tratada como uma iniciativa única ou espalhada em diversos projetos. Defendo que um analista de negócios entenda bem um negócio, pelo menos a parte afetada por um projeto. Só assim ele consegue contextualizar e, consequentemente, avaliar os requisitos aprendidos. Este *entendimento* se dá através de uma disciplina conhecida como Modelagem de Negócios. Se a empresa conhecer bem seu portfólio de projetos e planejar adequadamente o uso desta disciplina, ela pode elaborar gradativamente o que chamamos aqui de Arquitetura do Negócio. Devo admitir que nunca vi tal possibilidade sendo aproveitada. Sim, diariamente as empresas estão desperdiçando uma oportunidade de ouro.

    Por isso veremos um número considerável de projetos guiados pela segunda motivação acima, “avaliação da prontidão de TI”. Claro que o nome da iniciativa vai variar bastante. O termo aqui sugerido é pouco “pop” e muito comprometedor: “como assim, cara pálida, gastar dinheiro para avaliar se tu tá pronto pra me atender?!? Cê tá maluco?” O fato é que vimos surgir nos últimos tempos não só o termo e a necessidade, mas até um papel. Nasceu o arquiteto corporativo, o novo braço direito do CIO ou diretor de TI. E o que você acha que esse cara vai fazer?

    Sim, ainda são poucas (e grandes) empresas que demonstram preocupação com o tema. Mas acho que ele vai se espalhar. E isso é bom. Daí a motivação para estes dois artigos. Voltemos então ao que nos trouxe aqui: como desenhar a Arquitetura de um Negócio?

    Escrevi acima que o entendimento de um negócio significa o domínio das quatro partes principais que o definem: recursos (estrutura), processos (dinâmica), regras e objetivos. O diagrama ao lado exibe a visão de nível mais alto do “metamodelo” do qual derivamos todos os modelos de um negócio. Pois é, um negócio pode demandar vários modelos para sua correta demonstração e entendimento. Modelos ou conjuntos deles nos ajudam a montar visões, perspectivas diferentes. Podemos ter, por exemplo, um modelo que se preocupe exclusivamente com a estrutura de um negócio, seus recursos. Ou um conjunto de diagramas que trate apenas de sua parte dinâmica, seus processos.

    Recomendo o uso da EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios, para a elaboração desses modelos. Neste artigo mostro os principais diagramas que podem ser elaborados através desta linguagem. Quero dizer, então, que a Arquitetura de um Negócio é representada por um conjunto de diagramas. E que estes diagramas são estruturados em visões. Mas eu tenho um probleminha.

    Falta naquela proposta um diagrama-sumário, um modelo que represente em apenas uma página a visão geral do negócio. Normalmente eu desenho (e recomendo) um grande mapa de processos. Consigo representar neste tipo de diagrama todos os elementos fundamentais de um negócio. Mas eu não consigo explicar, não sem um certo esforço, o negócio em si. Aqui é importante lembrar o estágio em que se encontra esta disciplina que chamamos de Modelagem de Negócios. Ela está renascendo. De certa forma, podemos dizer que está sendo redefinida. Este artigo ilustra um pouco o surreal (e interessante) momento atual¹. Acontece que nenhuma das duas obras comentadas no artigo apresentam uma solução para meu probleminha. Relembrando: precisamos de um modelo que explique um negócio da mesma forma que um A3² explica e justifica um projeto, em uma folha apenas. Mas não se trata da concisão pela concisão. Esta “folha” deve ter uma lógica de leitura, uma estrutura bem definida. E deve, acima de tudo, explicar um negócio.

    Encontrei em outro livro “estranho” uma possível alternativa. Estou falando de “Business Model Generation”, de Alexander Osterwalder e Yves Pigneur (publicação própria, BusinessModelGeneration.com, 2010). Um dos elementos do método proposto no livro é o Canvas, que vou adaptar aqui para tabuleiro. Não é tradução e sim uma adaptação, ok? Tabuleiro porque é onde colocamos as peças do jogo. Em nosso caso, do jogo do negócio. O tabuleiro não é um metamodelo nem uma alternativa para a EPBE/UML. Trata-se apenas de um modelo. Mas não interprete mal o ‘apenas’. É um modelo que pode sintetizar ou até mesmo guiar a elaboração de outros modelos. Vamos dar uma olhada no tabuleiro vazio.

    No centro do tabuleiro colocamos a proposição de valor do negócio, o que ele está prometendo para seus clientes. No lado esquerdo colocamos as peças que os autores remetem ao lado esquerdo do cérebro – aquilo que deve ser otimizado. Estão ali seus parceiros, processos e recursos principais, além da estrutura de custos. Concluímos então que o lado direito do tabuleiro representa a mesma porção do cérebro, mais quente e subjetiva – mais criativa. Ficam ali as quatro áreas que completam o tabuleiro: clientes, relacionamento com clientes, canais e fontes de receitas.

    Conseguimos mostrar ou entender um negócio através do tabuleiro? Sim, e os exemplos do livro – mostrando empresas como Apple, Amazon, Google, Procter & Gamble e Gillette, dentre outras – não deixam dúvidas quanto a isso. A ferramenta parece ser útil tanto para o desenho ou redesenho de um negócio existente quanto para a elaboração de um negócio totalmente novo. No processo sugerido, o tabuleiro seria desenhado em um quadro branco ou equivalente e preenchido com post-it’s ou desenhos. Estou usando termos condicionais ou dizendo que “parece ser útil” porque, a exemplo do que ocorreu com o método do Pensamento Visual um ano atrás, ainda não tive a chance de testar a nova ferramenta. Testá-la em campo. Porque desenhei o modelo do finito em poucos minutos e me diverti bastante. Mas este tipo de teste não conta. Espero em breve poder transcrever aqui outros testes e explicar melhor o uso do tabuleiro.

    Por enquanto, como de costume, não posso deixar passar alguns “poréns” ou possíveis correções. No meu modo de entender não basta a fixação da proposição de valor de negócio. O entendimento de sua motivação é crucial. Por isso eu colocaria naquele espaço central a visão, os grandes objetivos do negócio (e respectivos prazos) e também a missão da empresa (caso não esteja redundante com a proposta de valor). Também é cara ao processo de entendimento uma classificação mínima dos processos principais. Quais são primários, de apoio ou de gestão? Aliás, me parece que o espaço dedicado para processos e recursos é muito pequeno. Mas, enfim, apenas um bom volume de testes pode confirmar a utilidade da ferramenta e possíveis correções ou adaptações.

    Agora devemos retomar o ponto principal: este desenho, o tabuleiro, pode representar a arquitetura do negócio? Pelo menos em parte, sim. E tal possibilidade é sugerida no livro, na seção “Outlook – Aligning IT with Business” (pág. 272). Em relação ao sanduíche sugerido no artigo anterior o livro só não considera a Arquitetura de Informações (pelo visto, combinando-a com a Arquitetura de Aplicações). É uma pena que o livro dedique apenas duas páginas ao tema. Mas, claro, não era seu foco. Fica com a gente então o trabalho de testar a sugestão e, se for o caso, implementá-la. Tentarei fazer minha parte aqui. Inté!

    .:.

    Observações:

    1. Surreal? Sim, tanto que o BABoK 2.0, lançado no ano passado, ignora por completo a existência de uma disciplina chamada Modelagem de Negócios. Todas as obras citadas neste artigo e artigos relacionados sinalizam o renascimento da disciplina. O que nos permite concluir que o BABoK comeu bola. Ou você acredita que o assunto não interessa aos analistas de negócios?
    2. O “A3” é uma ferramenta criada na Toyota para solução de problemas. O nome vem do tamanho do papel utilizado na sua elaboração. Oportunamente mostrarei como ele pode completar ou até mesmo substituir o documento de visão de um projeto.

  • (Pensando alto sobre) Arquitetura Corporativa

    Segunda parte da palestra “O Futuro não é mais como era Antigamente“. O título original desta seção era “O Cérebro Eletrônico faz (quase) Tudo”. Mas vou poupá-los do resumo da saga¹. Este artigo vai tratar especificamente do tema que não consegui articular como gostaria no Seminário Engenharia de Software. Vou escrever (ou pensar alto) sobre Arquitetura Corporativa – aquela coisa abstrata que normalmente vem acompanhada de uma piadinha: “parece cabeça de bacalhau; Todo mundo sabe que existe mas ninguém nunca viu”.

    .:.

    Arquitetura, segundo o Houaiss, é 1. “arte ou técnica de organizar espaços e criar ambientes para as diversas atividades humanas”, ou 4. fig. “conjunto de elementos de um todo; estrutura, natureza, organização”. Uma arquitetura corporativa deveria representar todos os elementos da organização. É esta última frase que bagunça o coreto. Como representar “todos os elementos de uma organização”? Seria a arquitetura corporativa um tipo de documentação, de representação de coisas que existem no mundo real? Se for a representação de *todas* as coisas, não espanta que ninguém tenha visto uma. Por isso peço sua atenção para a primeira definição acima. “Arte ou técnica” – 97,8% técnica, em nosso caso; “de organizar espaços e criar ambientes” – estruturando todos os elementos de um conjunto; “para as diversas atividades humanas” – para as atividades e fins de um negócio, se estamos falando sobre Arquitetura Corporativa.

    Lá nos idos de 40 a.C. um tal de Vitrúvio, arquiteto e engenheiro romano, cismou em fixar algumas regrinhas para construções. Pelo jeito fez um bom trabalho, já que é ensinado até hoje. Dos dez volumes que ele batizou “De Architectura” só nos interessa aqui uma pequena definição: a tríade vitruviana. Ela fixa três elementos fundamentais da arquitetura:

    • Firmitas: solidez e estabilidade;
    • Utilitas: conveniência e utilidade. (Funcionalidade!);
    • Venustas: beleza, gosto estético.

    Se um dia resolvemos trazer “arquitetura” para nosso meio (TI), deveríamos ter importado também um comprometimento com as três características listadas acima. Afinal, elas são peças fundamentais da disciplina que incorporamos. Portanto, uma arquitetura corporativa deveria ser sólida, estável, útil e bela. Agora, faça uma breve análise dos negócios que você conhece. Faça de conta de que existe uma radiografia que sintetiza a arquitetura de uma determinada organização. Ela passaria pelo teste da tríade vitruviana? Não precisa responder. A menos que sua resposta seja ‘sim’. Assim vou pedir referências, CNPJ, “nada consta” e RG de todos os envolvidos.

    Não se trata de um julgamento negativo demais e sim de um “choque de realidade”. Um negócio, qualquer negócio, é feito de muita adaptação e improviso. O dinamismo que só faz crescer desde o início do século passado impõe uma dificuldade que a arquitetura “clássica” nunca enfrentou. Pelo que sei, nunca foi solicitada uma edificação que: i) se adaptasse instantaneamente às mudanças em seu ambiente; ii) influenciasse seu ambiente; e iii) suportasse os usos e mal usos mais improváveis e inconsequentes.

    Devemos concluir então que esse papo sobre “arquitetura corporativa” é pura balela e ponto final? Acho que não. Equivocada é a intenção de documentar extensivamente a arquitetura total de um negócio. Mais bola fora ainda é a documentação pela documentação, mera burocracia. A primeira pergunta que deveria ser feita é: por que precisamos falar sobre arquitetura corporativa?

    Todo negócio é uma viagem. Claro que não no sentido pejorativo que ficou comum nos últimos anos. Um negócio é uma jornada sem fim (pré-determinado) que de tempos em tempos renova seu destino (sua Visão). Condições do tempo e do terreno, cada vez mais instáveis e movediços, tornam a viagem e seu planejamento cada vez mais difíceis. A arquitetura corporativa, se bem elaborada, pode funcionar como mapa e bússola. Mas, afinal, o que é arquitetura corporativa? Como ela é desenhada, se é que é desenhada?

    Uma busca na Internet pode lhe dar dezenas de boas sugestões. O Zachman Framework, por exemplo, sugere um consistente modelo para a elaboração da arquitetura corporativa. Aqui vou apelar para uma visão mais simples, para o que chamo de “básico do básico”. Gosto de ver o desenho de uma arquitetura como se fosse um belo sanduíche. Belo mas simples, um cheeseburger. Que é formado por quatro partes apenas:

    • Arquitetura Tecnológica: ou “o que eu tenho”. São os ferros (hardware) e caixinhas (software) que compõem a infraestrutura tecnológica da organização;
    • Arquitetura de Informações: ou “o que eu sei”. Trata de dados, informações e conhecimento explícito, aquele que está registrado de alguma maneira no negócio.
    • Arquitetura de Aplicações: ou “o que eu faço”. Compila todas as funcionalidades oferecidas ao negócio na forma de sistemas aplicativos.
    • Arquitetura do Negócio: ou “Por qual razão e pra quem?”. Dá sentido para as três camadas (arquiteturas) inferiores. Justifica (ou não) cada aplicação, informação e componente de infraestrutura.

    Esta visão de alto nível atende parte da definição de arquitetura que vimos no início do artigo. Os “espaços” estão organizados. A partir dela conseguimos entender “estrutura, natureza e organização” dos elementos que formam a arquitetura corporativa.

    O desenho permite até algumas elocubrações e provocações. Por exemplo: Nicholas Carr (aquele do “IT Doesn’t Matter”) defende no livro “A Grande Mudança” (Landscape, 2008) que é questão de tempo para as empresas se livrarem da camada mais baixa do sanduíche, a arquitetura tecnológica. Aqueles “serviços” seriam oferecidos por grandes empresas, em um modelo muito parecido com o das distribuidoras de energia elétrica. Sua tese faz um certo sentido, mas qual o impacto nas camadas de cima? Ah, elas seriam terceirizadas também.  Opa, elas já são. Mas em fatias verticais, da mesma forma como repartimos um sanduíche de verdade. Ofertas assim são conhecidas como BPO, ou Business Process Outsourcing. Deixando as infinitas possibilidades de lado, voltemos ao tema central.

    Como são formadas cada uma das arquiteturas? As três camadas técnicas – Arquitetura Tecnológica, de Informações e de Aplicações – podem ser representadas por um ou mais diagramas específicos. A UML, por exemplo, oferece diagramas que podem representar muito bem cada uma delas. Importante aqui é o bom senso para se limitar a representar apenas os elementos principais, fazendo vista grossa para detalhes finos (sic). Desafiadora aqui é a ligação entre as quatro camadas, as relações entre elementos de infra, informações, aplicações e do negócio. Desafiadora porque é aqui que encontramos incontáveis ligações ponto a ponto (macarrônicas), vergonhosas redundâncias e incômodos buracos negros. Mas não é por aqui, pelas três arquiteturas técnicas, que o trampo deve começar.

    As três camadas técnicas só existem para suportar um negócio. Parece lógico que o desenho de uma arquitetura corporativa comece pelo entendimento e delimitação da arquitetura do negócio. Como estourei meu limite de 1000 palavras, uma sugestão para o desenho desta arquitetura fica para o próximo artigo. Inté!

    .:.

    Observações:

    1. Ok, tá aqui o resumo da saga: Era uma vez… lá na nossa pré-história acreditávamos em um colossal e monolítico “cérebro eletrônico”. Décadas depois testemunhamos o esfacelamento e distribuição do “cérebro” em peças cada vez menores e em locais dos mais inusitados. O que nos traz para uma das cinco supertendências apontadas pelo ZapThink: a interoperabilidade profunda. Em poucas palavras: esses pequenos cérebros ou pedaços de cérebro devem aprender a interagir e conversar entre si da maneira mais natural possível. Talvez este não seja o principal desafio dos novos tempos, mas com certeza é o mais instigante: “Como assim, meu tênis vai conversar com meu carro, minha casa e meu iPod?!?”
      A pergunta que fiz e não respondi naquela palestra foi: nossas teorias e práticas (sobre Engenharia de Software) resistem ao confronto com as novas pessoas, tecnologias e arquiteturas?
    2. A imagem utilizada neste artigo foi desenhada para o trabalho “De Architectura”, de Vitruvius, e obtida na Wikipédia.

  • Morte e Vida UML

    Há exatamente um ano Ivar Jacobson “media a temperatura” da UML. Como um de seus criadores, Jacobson fez uma leitura honesta da moda (“espalhou como fogo em mato seco”), desilusão, críticas de acadêmicos e agilistas e do ressurgimento da UML. Concluiu pedindo um uso mais “esperto” (smart) da linguagem. Conclusão vaga e marketeira: ele mantém o “Smart Blog” que vende um “Smarter Way”. Muito smart e ambíguo para o meu gosto.

    O que não desvaloriza seu diagnóstico objetivo e claro do momento atual da UML. Sim, a UML ganha uma segunda vida. Ou deveríamos dizer segunda chance? Até a Microsoft, que parecia ter sugerido de forma um tanto ingênua que DSL’s (Domain-Specific Languages) seriam alternativas à UML, agora destaca seu amplo suporte como um diferencial da nova versão do Visual Studio¹. São diversos os sinais que indicam um tipo de renascimento da UML. O que fazer para evitar um novo ciclo de desilusões e abandono?

    Deveríamos começar por uma isenta avaliação de tudo o que fizemos de errado na primeira onda. Em primeiro lugar há nossa irritante mania de viver colocando a carroça na frente dos bois. A adoção da UML significou, para várias organizações, a aquisição de ferramentas caríssimas. Os fornecedores dessas ferramentas, cumprindo bem o seu papel, prometiam maravilhas. Particularmente em relação ao aumento da produtividade dos desenvolvedores. Ignoravam ou faziam vista grossa para um contexto mais amplo. A incorporação da UML normalmente fazia parte de um plano maior: a implantação de novos métodos de trabalho. Numa cumbuca mais sortida que feijoada baiana fica difícil apontar responsáveis diretos por ganhos ou perdas. E a UML acabou pagando muito mais do que devia. Tanto que até hoje encontramos pessoas que acham que UML é uma “metodologia”.

    Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro.

    Desconfio que a raiz do problema está na forma como UML é ensinada e aprendida. O ensino da UML através de uma ferramenta, qualquer ferramenta, é um grande erro. Tão sério quanto ensinar matemática com calculadoras. Os alunos não têm a chance de perceber a UML como ela é, como uma Linguagem. E as limitações das ferramentas, que não são poucas, acabam interpretadas como limitações da linguagem.

    Por exemplo, não é raro encontrar pessoas que dizem que o desenho ao lado é um erro. Para elas a UML seria um simples padrão de notação. E, como tal, estaria restrita às figurinhas oferecidas nas ferramentas. Considero este o mais sério e comprometedor problema que temos com a UML. Uma limitação que nos leva a utilizá-la da mesma maneira que um compositor de funk carioca utiliza a língua portuguesa.

    Como toda linguagem, do português ao C#, a UML é viva. É extensível. Podemos e devemos adaptá-la às nossas necessidades. Mas fizemos um serviço tão ruim neste ponto que existem aqueles que acham que a possibilidade de criar extensões como a EPBE (Eriksson-Penker Business Extensions) é gambiarra ou correção de bugs, não uma característica projetada da linguagem.

    Ao ensinar UML devemos abandonar toda e qualquer ferramenta automatizada. Lápis e páginas de caderno são tudo o que precisamos para ensinar e aprender UML. Um profissional que domine bem os conceitos da linguagem saberá tirar mais valor de qualquer ferramenta que lhe seja oferecida. E assim, talvez, aquelas promessas maravilhosas dos fornecedores de ferramentas se realizem.

    Grande Demais, Complexa pra Chuchu

    Não deveríamos ensinar português através da gramática e sim com Chico Buarque e Machado de Assis.

    São outras críticas comuns, que aparecem principalmente no discurso de alguns agilistas. Toda linguagem é naturalmente complexa. Ou, melhor colocando: toda gramática², em sua plenitude, é naturalmente complexa. O fato é que pouquíssimos de nós dominamos a gramática da língua portuguesa, por exemplo. Mas isso não impede que utilizemos a língua das mais diversas maneiras em nosso dia a dia. O mesmo precisa ser dito sobre a UML. Ninguém precisa conhecer de cor e salteado toda a especificação e o metamodelo da UML, sua gramática, para poder utilizá-la. Aliás, se quisermos espantar fregueses, basta apresentar a UML desta forma.

    A UML é grande por necessidade, não por pura encheção de linguiça. E parece complexa para todos que não entendem ou não aceitam sua proposição original, de ser uma Linguagem Unificada de Modelagem. Ela é perfeita? Claro que não – fomos nós humanos que a criamos. É boa? Sim, eu diria excelente. Mas talvez esteja aqui seu grande problema: não há nada que possa ser comparado à UML. Lá em meados dos anos 90 tínhamos dezenas de propostas de padrões de notação. A UML veio para acabar com aquela baderna. Mas seu sucesso e consequente aceitação universal – um tipo de monopólio – criou este problema. Ela não é pior nem melhor nem maior nem mais complexa que ninguém simplesmente porque não temos com o que comparar.

    UML não é Chacrinha

    O Chacrinha dizia que tinha vindo para “complicar, não para explicar”. O maior objetivo da UML é o oposto. E, de novo, tenho que apelar para o “L” de UML: toda linguagem criada pelo homem tem esse único objetivo, facilitar a comunicação. Mas não são poucas as organizações que destruíram esse propósito quando instituíram que UML era “padrão de documentação”. Quando passaram a exigir que esse ou aquele diagrama fossem elaborados com o único propósito de documentar determinado trecho de um projeto. Nada pode ser mais nocivo e criar mais antipatia a uma proposta do que a percepção de obrigatoriedade descerebrada ou insensata. Por isso não são poucos os que fazem cara de nojo quando ouvem as letrinhas U-M-L. Passa da hora de devolvermos à UML suas proposições originais: explicar, e não complicar; Facilitar a comunicação e interação, e não substituí-las.

    Confesso que a ficha do péssimo uso que fazemos da UML só caiu quando comecei a participar de alguns fóruns e a apresentar meus eventos para analistas de negócios. Cheguei a acreditar na realização da profecia sugerida na capa da Software Development de abril de 2001, apresentada acima. Mas aí vieram o artigo do Jacobson, debates mais ricos, empresas interessadas na ressurreição da UML e a onda do Pensamento Visual. Taí, a UML realmente tem sua segunda chance. Ou eu deveria dizer que nós temos uma segunda chance?

    .:.

    Observações:

    1. Na revista INFO de junho/2010 tem um anúncio do Visual Studio, apresentado na forma de uma entrevista com o gerente de produtos da Microsoft Brasil, Sr. Rodrigo de Carvalho. A primeira pergunta é: “Por que clientes devem migrar para a nova versão do Visual Studio 2010?”. Resposta: “Por várias razões, mas destacaria: suporte à modelagem UML…“. Sim, ele começou pelo suporte à UML. Quem conhece o histórico das idas e vindas da MS em relação à UML entenderá o meu destaque aqui.
    2. Gramática, segundo o Houaiss, é um “conjunto de regras que determinam o uso correto de uma língua”.
      Não exagero quando trato a especificação da UML como um tipo de gramática. E reitero objetivando a aceitação de que UML é de fato uma língua. E que, como tal, ela deve nos ajudar a atender três grandes objetivos: i) Organizar o conhecimento; ii) Representar o conhecimento; e iii) Trocar conhecimentos.

  • The Back of the Napkin

    Autor: Dan Roam é presidente da Digital Roam Inc., empresa que consultoria que já atendeu clientes como Google, eBay, GE, Boeing e Wal-Mart. Seu método já foi apresentado no Senado dos EUA e em canais de TV como CNN, MSNBC e Fox News, dentre outros.

    Editora: Portfolio (EUA, 2008).

    Do que se Trata: “Resolver problemas e vender ideias com figuras” (subtítulo do livro). Roam apresenta o Pensamento Visual, um método que se baseia na seguinte premissa: uma imagem vale mais que mil palavras. Aprendemos aqui que a imagem certa vale bem mais que mil palavras.

    A quem se destina: Todo mundo que resolva problemas e / ou venda ideias.

    Dê de presente para:

    • Analistas de Negócios e de Sistemas
    • Líderes de Projetos
    • Desenvolvedores
    • Executivos
    • Seu colega que fala e / ou escreve demais.

    Contra-indicações: Nenhuma. E Roam prova que todo mundo pode aprender a desenhar.

    Prós:

    • Leitura fácil e muito agradável.
    • Roam é muito didático. E os exemplos utilizados são bons.
    • A diagramação esperta evita idas e vindas.

    Contras:

    • A base da neurobiologia, relevante que é, não deveria estar no apêndice. O autor nos convida a visitá-lo várias vezes no início do livro. Aceite o convite.
    • Os exemplos são bons mas poucos. Por isso o autor se apressou em lançar um complemento, “Unfolding the Napkin” (mais sobre ele abaixo).
    • Quem já tem o costume de desenhar para entender ou explicar pode achar o livro meio “basicão”. Mas, inexplicavelmente, anda raro encontrar pessoas com tal hábito. Mais difícil ainda é encontrar quem o faça de maneira sistemática, amparado por um método consistente.

    Apresentação / Complementos:

    Trilha de Estudo:

    1. Obrigado pela Informação que Você NÃO me Deu!
      Normann Kestenbaum – Campus / Elsevier (2008).
      Apresentado anteriormente na biblioteca do finito.
    2. Unfolding the Napkin
      Dan Roam – Portfolio (2009).
      Um método “hands-on” – um workshop de 4 dias com vários exemplos e exercícios. Complemento obrigatório de “The Back of the Napkin”.
    3. Business Modeling with UML
      Hans-Erik Eriksson e Magnus Penker – Wiley (2000).
      Aqui pisamos em solo pedregoso. Livro indicado apenas para quem quer megulhar de cabeça no uso da UML para a modelagem de negócios. Para analistas de negócios, considero um caminho inevitável. É interessante notar que, a exemplo do que acontece no FAN, o método de Dan Roam facilita bastante esta viagem. Dois artigos de minha autoria mostram um pouco deste ‘casamento’:
      Modelagem de Negócios: Uma Sugestão
      Modelagem de Negócios: Os Diagramas
    4. Business Modeling – A Practical Guide to Realizing Business Value
      David M. Bridgeland e Ron Zahavi. Morgan-Kaufmann (2009).
      Citado anteriormente por aqui. Não concordo nem um pouquinho com as sugestões dos dois autores: 4 linguagens ou padrões de notação diferentes para cada aspecto do negócio (BPMN se encaixa aqui). Prefiro o uso de uma única língua, UML. Mas preciso dizer que é um caminho alternativo para analistas de negócios e afins.

    .:.

    PS: Eu prometi uma trilha por mês. E falhei em abril. Portanto, aguardem outra entrada em nossa Biblioteca ainda em maio.

  • BABoK: Uma Leitura Crítica

    Antes de mais nada, um alerta: se seu interesse pelo BABoK limita-se à obtenção da certificação, então este artigo não vai ajudá-lo muito. Poupe seu tempo. Eu sei, é chato, mas este artigo também merece um prólogo-escudo: não tenho interesse nenhum em depreciar o IIBA (International Institute of Business Analysis) ou seu principal produto, o BABoK® Guide (A Guide to the Business Analysis Body of Knowledge). Há tempos apresento, aqui e ali, críticas àquela que deveria ser a principal referência para a formação de analistas de negócios (AN’s), o BABoK. Meus objetivos sempre foram apenas dois: i) ajudar os AN’s em seu processo de formação; e ii) contribuir para a evolução do BABoK. Ressalvas e alertas devidamente colocados, vamos ao que interessa. Este artigo trata da última versão do BABoK, a 2.0, publicada em 2009.

    A Estrutura do BABoK

    Alguma coisa muito estranha aconteceu entre a liberação da versão para revisão pública, em março/2008, e a versão definitiva publicada agora. A estrutura básica do BABoK foi mantida, com suas 6 disciplinas (KA’s ou Knowledge Areas), mas a ordem de apresentação sofreu consideráveis alterações. Se alguma justificativa para tal foi apresentada, não percebi. O fato é que complicaram a leitura. Em meu entendimento, desnecessariamente.

    Na versão 2.0 liberada para revisão as duas primeiras disciplinas apresentadas eram aquelas de perfil mais gerencial e tático: “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”. Era uma alteração necessária em relação à versão anterior, a 1.6, que começava pela “Análise da Organização” (ou “Enterprise Analysis”). Necessária por agrupar, mesmo que de maneira implícita, as disciplinas cuja aplicação se diferencia substancialmente das outras quatro. (Mais sobre elas no decorrer do artigo).

    A versão atual do BABoK inseriu “Elicitação” entre as duas, comprometendo uma certa lógica de leitura. E a “Análise da Organização”, que um dia foi a primeira disciplina apresentada, agora aparece apenas no quinto capítulo. Uma estrutura que parecia bem resolvida, como ilustra o gráfico abaixo, virou um diagrama de difícil entendimento.

    As disciplinas no BABoK 2 (public review)
    As disciplinas no BABoK 2 (public review)
    A nova estrutura do BABoK
    A nova estrutura do BABoK

    No primeiro diagrama percebemos claramente uma sequência lógica de 4 disciplinas, além da informação de que outras duas guiam e/ou dão suporte à análise de negócios. O segundo desenho quebra essa lógica e não faz nada mais do que confundir. Realmente é incompreensível a mudança.

    Além disso, ainda sobre a estrutura do BABoK, é preciso dizer que a forma como as disciplinas são apresentadas é boa. Destacam-se as entradas, tarefas e saídas principais de cada disciplina. Depois, para cada tarefa, são descritos: entradas, elementos (que são específicos para cada tipo de tarefa), técnicas, partes interessadas (stakeholders) e saídas. A sequência é lógica e didática, apesar dos deslizes que serão discutidos abaixo.

    Armadilhas

    Saca aquele sujeito que, aéreo e desastrado, acaba caindo em armadilhas que ele próprio armou? Essa imagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia do IEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definição de requisitos. Logo depois, ainda no capítulo 1, alerta que “é vital que o termo ‘requisito’ seja compreendido no mais amplo sentido possível”. Ao tentar ilustrar o que seria essa amplitude toda, confundem: “em uma iniciativa BPM, requisitos podem ser uma descrição dos processos de negócio atualmente em uso pela organização”. Além de comprometer a definição do IEEE utilizada na página anterior, criam um tipo de saco sem fundo onde tudo é ou pode ser um requisito. Armadilha armada no primeiro capítulo faz vítimas no decorrer de todo o BoK. Quando apresentando a técnica de “Análise de Regras de Negócios”, por exemplo, é dito que “regras de negócios devem ser separadas de outros requisitos…”. Ou seja, dão a entender que regras de negócios também seriam um tipo de requisito.

    Um analista de negócios deve aprender cedo que a distinção entre elementos do negócio (recursos, processos, eventos e regras) e elementos da solução (requisitos) é crucial para o bom desenvolvimento de seu trabalho. Ele sabe que há uma única interseção entre esses dois conjuntos e ela atende pelo nome de Requisitos do Negócio. O BABoK os define corretamente, como “grandes objetivos, metas e necessidades de um negócio”. De tão importantes, mereceram uma disciplina só para eles, a “Análise da Organização”. O que torna ainda mais indecifrável a bagunça apontada no parágrafo anterior.

    A segunda armadilha bastante notável no BABoK é a necessidade de manutenção de uma certa “compatibilidade retroativa”. O BABoK tenta colocar e manter os pés em dois mundos muito distantes. Ele os chama de “Plan-driven” e “Change-Driven” – nomenclatura criativa usada para diferenciar o mundo clássico¹ de projetos daquele universo que surgiu após o big-bang do Manifesto Ágil. Se num primeiro momento – no capítulo 2, que trata do “Planejamento e Monitoramento da Análise de Negócios” – ele se mostra muito atencioso com o enfoque “change-driven”, na parte que seria mais cara e necessária tal atenção evaporou. Em “Gerenciamento e Comunicação de Requisitos” (capítulo 4), por exemplo, quase nada é falado sobre a forma como requisitos são gerenciados quando é adotado um processo ágil qualquer (Scrum, XP etc).

    O referido capítulo é repleto de  procedimentos para revisão e aprovação de requisitos, baselines, documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar de clássico. Se mantido o mesmo balanceamento (de preocupações) apresentado no capítulo 2, aqui deveríamos ver no mínimo uma vez a expressão “software rodando”, ou “solução rodando” ou algo do tipo. Não vemos. O que permite dizer que o BABoK firma o pé mesmo é no mundo clássico, a exemplo de seu primo não muito distante, o PMBoK. E por falar nele…

    O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos  duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

    Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e muito menos do gerente de projetos. Deveria ser só do arquiteto e ponto. Mas isso é tema para outra hora. Aliás, atenção piratas! Vou lançar o FAS – Formação de Arquitetos de Soluções. Preparem suas copiadoras! hehe..

    Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crítica ao BABoK é o fato dele ignorar por completo a disciplina conhecida como Modelagem de Negócios. O problema se torna mais perceptível na versão 2.0. Porque de fato ele não ignora a necessidade da modelagem. Sugestões para o uso de técnicas de modelagem aparecem a todo momento, em diversas disciplinas. Mas elas surgem de forma tão solta e desestruturada que é difícil imaginar que sejam utilizadas em sua plenitude. Pior: é difícil imaginar que gerem algum valor. Aos fatos.

    Ainda na primeira disciplina, “Planejamento e Monitoramento da Análise de Negócios”², são apresentadas como técnicas gerais a “Modelagem da Organização” e a “Modelagem de Processos”. Em “Análise da Organização”, o 5º capítulo, são elencadas as técnicas “Benchmarking”, “Análise de Regras de Negócios”, “Decomposição Funcional” e “Análise SWOT”. No sexto capítulo, “Análise de Requisitos”, o assombro: além de diversas das técnicas acima, sugerem inclusive o uso de “Diagramas de Fluxo de Dados” na tarefa que deveria ser apenas “Organizar Requisitos”. Dentre os elementos desta tarefa aparece uma breve explanação sobre cada um dos 5 conceitos que, segundo o BoK, “garantem a total cobertura do domínio do negócio”. Aliás, os 5 conceitos são: 1) Classes de Usuário, Perfis e Papéis; 2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.

    Nada mais é necessário para confirmar que a Modelagem de Negócios é fundamental para o entendimento de um negócio. Colocando de outra maneira: é fundamental para a Análise de Negócios. O BABoK sabe disso. Acontece que, ao invés de tratá-a como uma disciplina – como um corpo – preferiu esquartejá-la e distribuí-la em pedacinhos em diversas de suas KA’s. É grave quando percebemos que a Análise de Requisitos, uma disciplina por si só complexa e crítica, vira uma espécie de monstro de Frankestein no BABoK.

    Essa armadilha se torna mais visível quando percebemos que em outros pontos do BoK é apresentada como entrada para determinadas tarefas uma tal “Arquitetura Corporativa” (um documento que, segundo o BABoK, “descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos de negócio, sistemas, informação etc”). Esse input já existiria de alguma maneira na organização. Duas coisinhas: 1) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é factível supor que seu desenvolvimento e manutenção, mesmo que parcial,  sejam atribuições dos analistas de negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na Análise de Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a compor uma “Arquitetura Corporativa”. Vai entender…

    Conclusão

    No final das contas o grande problema com o BABoK é esse: entendê-lo. Se por um lado sua estrutura geral é desenhada com esse fim, e é bem desenhada, por outro o conteúdo ainda apresenta inconsistências demais. Pouco adianta o reuso de conhecimentos bem consolidados, como definições do IEEE e diagramas UML, se eles são contraditos ou diluídos de tal forma que perdem seu sabor e valor.

    Joe Gollner publicou em julho último um artigo chamado “O Curioso Caso da Análise de Negócios“. Brinca com o título do filme estrelado por Brad Pitt, “O Curioso Caso de Benjamin Button”. Joe erra feio ao dizer que não estaríamos prontos para definir um corpo de conhecimentos para a análise de negócios. Tenho certeza de que já temos conhecimento e maturidade suficientes para delinear um BoK. Mas ele acerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.

    A necessidade de manutenção de uma “compatibilidade retroativa” é, sem sombra de dúvidas, a grande culpada. Como justificar, em 2009, o uso de técnicas como a elaboração de DFD’s e diagramas de contexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim o BABoK só faz confirmar uma fama dos AN’s: seriam consumidores vorazes de papel. Não digo com isso que ele deveria se ater aos princípios pregados no Manifesto Ágil. Afinal, a análise de negócios não se limita a projetos de software. Mas é imperdoável que um BoK para análise de negócios se lembre de DFD’s e ignore por completo balanced scorecards, mapas estratégicos, conceitos Lean etc etc etc.

    Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obtenção da certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar o BABoK. Além de ter boa experiência prática. Mas o analista deve ter consciência de todas as armadilhas e inconsistências que o BABoK apresenta em sua versão atual. Para não correr o risco de comprometer seu trabalho e até sua carreira.

    .:.

    Nota aberta ao IIBA

    A lei de imprensa morreu, o finito não é imprensa, mas ética e educação não precisam ser regidas por leis. Caso o instituto julgue necessária uma resposta ao artigo acima, eu garanto o mesmo espaço e mesmo destaque. E reafirmo: não tenho interesse nenhum em criticá-los por criticar. Muito pelo contrário. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com um BABoK forte e consistente. Todos sabemos que um debate franco e aberto é o melhor caminho para a realização desses objetivos.

    .:.

    Serviço:

    Outras Notas:

    1. Entenda como “Mundo Clássico de Projetos” aquele que brotou e cresceu no século passado. Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ou waterfall e que sustenta seus métodos e práticas em diferentes níveis de comando e controle. Não há nada de pejorativo nessa definição. E não há nada de errado com esse modelo, desde que ele não seja utilizado em projetos de software.
    2. O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de  suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework do SEI?

  • Modelagem de Negócios: Os Diagramas

    Sequência obrigatória de “Modelagem de Negócios: Uma Sugestão“. Como prometido, apresento neste artigo um conjunto básico de diagramas que um analista pode desenvolver para entender um negócio. Opa… vale repetir o mantra: Modelamos um negócio para entendê-lo. Este é o principal objetivo da disciplina conhecida como modelagem de negócios. Assim como o principal alvo da engenharia de requisitos é a compreensão dos desejos, necessidades e restrições dos usuários.

    Portanto, por favor, utilize as sugestões abaixo com moderação. Traduzindo: não é para sair desenhando tudo quanto é diagrama sugerido aqui! Apresento uma variação do “Codex” de Dan Roam (autor de “The  Back of the Napkin”) exatamente para facilitar a escolha de determinado tipo de diagrama, dependendo do problema em questão. Como ainda se trata de uma versão beta, críticas e sugestões serão muito bem vindas. Desde já agradeço.

    O 'Codex' da Modelagem de Negócios
    O 'Codex' da Modelagem de Negócios

    O gráfico acima representa nosso ‘Codex’ – um guia que nos ajuda a definir o diagrama ou artefato mais indicado para o entendimento ou apresentação de determinado problema ou solução. O desenho é grande demais para o espaço aqui. Clique na imagem para ver uma versão ampliada. Podemos seguir?

    As linhas representam as 3 visões – do Negócio, da Estrutura e dos Processos – e suas respectivas perguntas. As colunas representam as 5 decisões SQVID. Lembrando: Simples ou Elaborado; Qualitativo ou Quantitativo; Visão ou Execução; Individual ou Conjunto; e Mudança (to-be) ou estado Atual (as-is). Nas células aparecem ícones que representam um tipo de diagrama ou artefato. Quando a célula estiver vazia é porque aquela pergunta, naquele seletor, não faz sentido.

    Abaixo, na sequência das visões, são apresentados todos os diagramas ou artefatos sugeridos.

    Visão do Negócio

    Aqui tentamos responder uma única questão: Por quê? Ou seja, quais são as motivações do negócio? Quais são os grandes requisitos do negócio? Afinal, quais necessidades do negócio esse projeto ou demanda deve satisfazer? Três ícones apareceram no desenho acima:

    0documentoO documento é a única representação não desenhada de todas as sugestões do ‘Codex’. É algo que foi antecipado por Eriksson e Penker em “Business Modeling with UML”. Algumas informações obtidas neste momento simplesmente não fazem sentido de outra forma que não seja texto puro. Mas, antes de abrir seu editor de textos, entenda que essas informações podem estar estruturadas em sofisticados formatos, como Mapas Estratégicos, Balanced Scorecards, matrizes SWOT etc. Podem representar também a declaração de Missão ou Visão da empresa. E ainda, num cenário mais pobrezinho, uma lista com os principais requisitos do negócio.

    0mapa_processosO mapa de processos (neste momento, um ‘modelão’ conceitual) pode ser uma alternativa ao texto puro – uma alternativa mais elaborada. Se estivermos lidando com milhares de palavras, então o desenho pode ser uma boa opção. Afinal, modelamos para simplificar – para facilitar o entendimento. Seu uso também é util para explicar a execução – o meio pelo qual a organização espera realizar a visão, seus objetivos. Como mostra o ‘codex’, este mapa pode ser utilizado tanto para ilustrar o ‘as-is’ como o ‘to-be’, ou seja, como a empresa se vê após a realização de seus objetivos.

    0grafico_simplesQuando lidando com  números, quantidades, não há representação melhor que um belo gráfico – de preferência de barras, que além de muito legível é mais fácil de ser desenhado à mão. Quando utilizado na elaboração da visão do negócio, este gráfico representa grandes números que explicam ou justificam os requisitos do negócio. Estamos falando de aumento de receitas? Ou de redução de custos? Sempre que requisitos assim são apresentados, um gráfico pode ajudar em sua visualização e divulgação.

    A construção da visão do negócio é uma tarefa que normalmente não dura mais que poucos dias ou até mesmo horas. O que não significa que ela não seja importante, pelo contrário. Muitos projetos falham porque, a partir de determinado momento, a equipe simplesmente esquece a principal razão pela qual aquele empreendimento foi iniciado. A visão do negócio representa os principais requisitos do negócio. Portanto, ela não é nada menos que fundamental. E todo projeto deveria começar por ela.

    Visão da Estrutura

    Por estrutura devemos entender todos os recursos que compõem uma organização ou se relacionam com ela de alguma maneira. Três questões devem ser colocadas para a elaboração da visão da estrutura:

    • Quem / O Quê? – para identificar partes interessadas (stakeholders) ou recursos envolvidos em determinada situação. Esses recursos podem ser produtos, serviços, máquinas, documentos etc. Ou seja, qualquer tipo de recurso físico, abstrato ou de informação.
    • Quanto? – para entender e tratar todas as informações numéricas: volume de vendas, número de colaboradores, salários, giro de estoques, quantidade de clientes etc etc. Enfim, separamos com essa questão todos os dados quantitativos sobre os recursos elencados na pergunta anterior.
    • Onde? – agora uma questão para localização, para posicionamento dos recursos na organização ou em seu macro-ambiente (nicho, mercado ou cadeia de valor).

    São 4 os diagramas principais usados para elaboração da visão da estrutura:

    0classes_simplesO diagrama de classes é quase onipresente nesta visão. Não é uma questão de falta de opções, mas sim de uma grande versatilidade desta ferramenta. No entendimento das questões de identificação (quem / o quê), o diagrama de classes pode ser utilizado para representar organogramas ou a composição de produtos ou serviços, por exemplo. Na pergunta que trata de localização (onde), este diagrama pode representar departamentos, seções, filiais, franqueados etc. No ‘codex’ aparece também uma outra versão deste diagrama, simplesmente para indicar a possibilidade de confecção de desenhos mais elaborados e extensos.

    0estadoQuando é necessário analisar um recurso específico o diagrama de estado pode ser de grande utilidade. Os estágios no ciclo de vida de um contrato ou uma apólice, o status de uma ordem de compra, os estados de determinado equipamento etc. No livro “Business Modeling with UML”, este diagrama é usado na construção da visão do comportamento, opção que não está contemplada nesta sugestão. Independente do nome ou perspectiva, o importante é saber que podemos contar com esta ferramenta sempre que um recurso relativamente complexo exigir um estudo e representação mais detalhados.

    0grafico_elabPois é, como já foi citado na visão anterior, não existe representação visual melhor do que um gráfico (de barras, preferencialmente) para as respostas da questão “quanto”. Repare no ‘codex’ que este é o único artefato gerado em todas as variações oferecidas no seletor. Mas é importante colocar que algumas organizações podem apresentar essas respostas em outros formatos. Um balanced scorecard, por exemplo, obrigatoriamente apresenta metas quantitativas para todos os indicadores apontados. O bom analista evita redundâncias.

    0fluxo_swinlanesO artigo anterior chamou a atenção para o fato de alguns diagramas ultrapassarem os limites de uma visão. Eis aqui um diagrama de atividades (ou fluxograma), natural da visão dos processos. Aqui, na visão da estrutura, ele aparece em uma única célula: quando precisamos ver a execução (2ª opção da terceira coluna do ‘codex’) em resposta para a pergunta “onde?”. Colocando de outra maneira, este diagrama pode ser utilizado para explicar onde determinadas atividades ocorrem ou devem ocorrer.

    A visão da estrutura é sumariamente ignorada no padrão de modelagem da moda, a BPMN. Claro, não é uma culpa da notação. O problema é que muitos profissionais ainda misturam e chacoalham bolas, acreditando ser possível a utilização da BPMN para a modelagem (o *entendimento*) de negócios. Não é.

    Visão dos Processos

    Finalmente, a visão que trata da parte dinâmica de uma organização. Todas as tarefas, atividades e processos executados por uma empresa são capturados e analisados através dos artefatos que compõem esta visão. Duas perguntas nos levam até eles:

    • Quando? – nos ajuda a  posicionar ações em uma linha de tempo. Quando tal problema ocorre? Quando aquele evento deve ser disparado? Qual é o deadline daquela tarefa? E assim por diante.
    • Como? – por fim, a última e mais complicada questão. Como tal atividade acontece? Como aquele processo deve ser executado? É a questão que guia o mapeamento e modelagem de processos e atividades de negócio.

    Não por acaso, é nesta visão que temos um conjunto maior de diagramas. São 8 tipos principais, listados abaixo:

    0processo_seqMapas de processos nos ajudam a responder tanto o “quando” quanto o “como”. Geralmente formam o melhor ponto de partida para o desenho das respostas para as duas perguntas desta visão. São particularmente úteis quando os envolvidos não têm um entendimento comum sobre os processos envolvidos em determinado problema. Todos os outros artefatos gerados na construção desta visão, de certa forma, derivam deste.

    0processoO mapa, apresentado acima, é na realidade um conjunto de diagramas de processos. Para desenhá-los deveríamos seguir um pattern sugerido em “Business Modeling with UML”. Um padrão que vem de outra notação, a IDEF0. É simples: à esquerda do processo ficam as entradas; na direita as saídas; abaixo, todos os recursos utilizados na produção das saídas; e acima os recursos usados no controle do processo. Este diagrama, que à primeira vista parece simplista e desnecessário, pode dar origem a artefatos mais avançados, como mapas de avaliação (nome tropicalizado para “System Maps”, apresentado por Ralph Smith em “Business Process Management and the Balanced Scorecard”). Outro artefato derivado deste é o diagrama de linha de montagem, que veremos posteriormente.

    0fluxo_cronogramaAnalistas de O&M (eles ainda existem?) vão se lembrar da figurinha ao lado. É o velho ‘fluxo-cronograma’. Trata-se do diagrama de atividades da UML acrescido de informações sobre tempo, apontadas em swinlanes ou de alguma outra maneira – isso não importa muito. Uma alternativa é o uso do diagrama de Timing (linha de tempo), que foi introduzido na UML 2. Mas o uso de uma variação do diagrama de atividades deve fazer mais sentido na maioria das vezes, já que o analista reutilizaria um diagrama já elaborado, adicionando apenas informações sobre a duração de atividades e tarefas.

    0fluxo_swinlanesAliás, a base para o diagrama sugerido acima é esse aqui, o diagrama de atividades (ou fluxograma, como queiram). Quando detalhamos um processo, este é o formato. Podemos nos limitar a um nível mais alto – as atividades, ou descer ao menor nível de detalhamento possível – as tarefas. A ferramenta pode ser sexagenária ou centenária. Se dura tanto é porque ninguém inventou nada melhor, certo? Como eu disse em um artigo anterior, a BPMN nada mais é do que uma revisão (3.0?) deste velho conceito. Aliás, quando no domínio da solução (to be) e tendo como base algum produto BPMS, o analista pode substituir este diagrama por modelos BPMN. Aliás, deve. Mas, em todos os outros casos, particularmente quando ainda estiver *entendendo o negócio*, ele deveria evitar a BPMN. E utilizar UML.

    0sequenciaUma alternativa ao diagrama de atividades é o diagrama de sequência. Atenção: é uma alternativa. O analista desenvolve um ou outro para estudar ou representar determinado processo ou atividade. Quando interações entre as partes envolvidas e uma noção de duração das atividades forem muito importantes, então o diagrama de sequência pode ser mais útil que o de atividades. Quando o analista tiver à sua disposição uma ferramenta CASE, ele ganhará um diagrama quando desenvolver o de sequência – o diagrama de comunicação é gerado automaticamente. E pode ser útil na análise das interações entre as partes interessadas – para identificar gargalos, por exemplo.

    0assembly_lineO diagrama de linha de montagem é uma variação do diagrama de processo. Serve para análise específica de recursos que apoiam a execução de um processo (como vimos, esses recursos são desenhados abaixo do processo). É especialmente útil quando esses recursos, representados por linhas de montagem (pacotes da UML), são sistemas de informação. O diagrama ilustra todos os dados lidos e gravados em sistemas, demonstrando como eles viabilizam (ou impactam) um processo de negócio.

    Repare que o artefato acima é o primeiro que trata especificamente de sistemas. Todos os outros apresentados até aqui são utilizados exclusivamente para o entendimento ou demonstração do negócio e seus diversos aspectos. Vale ressaltar que o diagrama de linha de montagem é particularmente útil quando ainda estamos no domínio do problema. Tanto que ele é apresentado como uma alternativa para responder o “como” é hoje (as-is, última coluna do ‘codex’).

    Mas, quando o analista começa a entrar no domínio da solução – capturando requisitos das diversas partes interessadas – quais artefatos ele pode gerar? Abaixo são apresentados dois diagramas que aparecem apenas na coluna D (to be) do ‘codex’:

    0PucsO diagrama PUCS (Process Use-Case Support) é mais um belo exemplo de toda a versatilidade da UML. Ele é a combinação de dois diagramas, de atividades e de casos de uso. O diagrama de atividades, descrito acima, é a base para a elaboração de um PUCS. O analista pode utilizá-lo para iniciar e facilitar os trabalhos de identificação de casos de uso, ou seja, de descoberta e descrição de requisitos funcionais. No PUCS indicamos explicitamente quais atividades ou tarefas do negócio serão suportadas (incrementadas ou impactadas) por determinados casos de uso. Nenhuma imagem representa melhor o ato de ‘embarcar’ sistemas em um processo de negócio.

    0use_caseChegamos então ao último artefato de nossa listinha, o mal falado e mal entendido diagrama de casos de uso. Ele pode ser extraído de um PUCS ou ser desenhado do zero, dependendo das necessidades de entendimento do analista. Suspeito que muitos não concordem, mas desconheço outra representação gráfica que ilustre tão bem todo o escopo funcional de um projeto. Além do pouco tempo gasto em sua elaboração, outra vantagem desse tipo de diagrama é sua legibilidade.

    Deve ter ficado claro pela listinha acima que a elaboração da visão dos processos é a mais complicada – aquela que exigirá mais do analista. O mais perigoso engano que deve ser evitado a todo custo é o desenvolvimento deste estudo numa tacada só, como se fosse uma fase de um projeto. Devemos brigar pelo pleno uso de um processo que seja iterativo e incremental. Com exceção da visão do negócio, desenvolvida na primeira iteração, todas as outras são maturadas e desenvolvidas durante todo o projeto. Mas isso já é assunto para outra hora, né?

    E as Regras de Negócio, onde ficam?

    Como citei no artigo que deu origem a esta série, “Modelagem de Negócios: A Encruzilhada“, David Bridgeland e Ron Zahavi defendem em seu livro, “Business Modeling – A Practical Guide to Realizing Business Value”, que as regras de negócio tenham sua própria disciplina. Até aí, tudo bem. O problema começa quando tentamos buscar algum tipo de representação que seja específico para as regras. Cria-se muita confusão desta maneira. Devemos nos lembrar que a motivação para a modelagem é a simplificação.

    Regras de negócio podem aparecer, definindo ou restringindo, em qualquer outro elemento básico de um negócio (leia-se: objetivos, recursos e processos). Portanto, parece ser um grave engano a definição de um padrão de apresentação específico para regras. Seu repositório natural deveria ser aquele artefato que estava sendo elaborado quando a regra surgiu. Ou, dependendo do caso, um anexo deste artefato. Por exemplo: a regra apareceu quando desenhávamos um diagrama de atividades. Por que não registrá-la ali mesmo, na forma de uma nota? (a UML tem o recurso ‘nota’ para a colocação de comentários em diagramas. As notas podem inclusive ser ‘ancoradas’ em elementos específicos de um diagrama. E são utilizadas em qualquer tipo de diagrama).

    Claro, existem regras muito complexas – extensas pra chuchu. Uma fórmula de cálculo de seguro, por exemplo. Não faz nenhum sentido que uma fórmula de trocentas páginas seja comprimida em um diagrama, certo? Custa grampear a fórmula no diagrama, indicando com um código bobo o local onde ela se aplica? O tema é importante demais para ficar só aqui, no rodapé deste artigo. Voltarei ao tema.

    .:.

    Agora, para encerrar este longo artigo, apenas um breve comentário sobre a disciplina em questão, a Modelagem de Negócios. O que antes era uma suspeita caminha agora para a certeza absoluta: quase ninguém pratica a modelagem de negócios. E, se depender de iniciativas recentes como o BABoK, a situação pode piorar bastante. Por que isso é um problema? Porque o entendimento do negócio é fundamental para o sucesso de um projeto. E ainda não inventaram disciplina mais eficaz que a modelagem de negócios para a obtenção desse entendimento.

    Mas sou teimoso e um incurável otimista. Livros publicados recentemente, particularmente “The Back of the Napkin” (Dan Roam. Portfolio, 2008) e “Business Modeling – A Practical Guide to Realizing Business Value” (David M. Bridgeland e Ron Zahavi. Morgan Kaufmann, 2009) provam que a displina pode ganhar um novo impulso. Eu espero que minhas contribuições mereçam 2 centavos. E um pouquinho de sua atenção. Inté!

    .:.

    Nota:

    • Mais uma imagem surrupiada de Kelbv, agora a flikr0679. É aquela enigmática e colorida figura do topo do artigo. Tudo a ver com modelagem, certo?

  • Modelagem de Negócios: Uma Sugestão

    Finalmente a prometida sequência de “Modelagem de Negócios: A Encruzilhada“. Justifico a demora: passei os últimos meses envolvido em serviços de treinamento e consultoria para 3 grandes empresas. Nelas tive a oportunidade de experimentar e validar a sugestão que apresento neste artigo. Trata-se de um teste ao qual são submetidos todos os métodos e práticas que formam o programa FAN: a aplicação real, em empresas e projetos de verdade.

    Encerrei o último artigo prometendo um ‘remix’ do método proposto por Dan Roam em “The Back of the Napkin” com a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para a modelagem de negócios. Essa é a sugestão apresentada neste artigo.

    .:.

    A principal ferramenta do método proposto por Dan Roam é a sequência de 6 perguntas conhecida como “6 W’s”. As questões são: Quem / O quê (who/what); Quanto (how much); Onde (where); Quando (when); Como (how) e por quê (why). Como vimos no artigo anterior, há um tipo de desenho mais indicado para cada pergunta.

    A modelagem de negócios compreende a elaboração de visões. Cada visão é formada por um conjunto de diagramas. Há sempre uma visão mais indicada, dependendo do objeto que está sendo modelado / analisado. No trabalho que lançou a EPBE, “Business Modeling with UML”, são apresentadas 4 visões: do Negócio, da Estrutura, dos Processos e do Comportamento. Hans-Erik Eriksson e Magnus Penker, os autores, lembram que podem ser criadas outras visões, dependendo da necessidade do analista e do projeto. As visões Econômica, de Sistemas de Informação e de Recursos Humanos são alguns exemplos.

    Visões

    Foi necessário um pequeno (mas sensível) ajuste na ordem das perguntas sugerida por Roam. Todo projeto ou estudo deve começar com o entendimento da motivação do negócio. Ou seja, “por quê?” não é a última e sim a primeira questão. Claro, ela também pode ser executada no final do ciclo. Serviria assim como um tipo de teste, uma validação dos trabalhos de modelagem e análise do negócio. A resposta para o “por quê” determina aquilo que na EPBE chamamos de Visão do Negócio. Trata-se da apresentação dos requisitos do negócio que, dependendo do projeto, podem incluir a transcrição da Missão e Visão – seus mais altos objetivos.

    As três primeiras perguntas de Roam – “Quem / O Quê”, “Quanto” e “Onde” – nos levam a construir a Visão da Estrutura. Vale lembrar que essa visão trata de todos os recursos que pertencem ao negócio ou que se relacionam com ele de alguma maneira. Estamos falando de recursos físicos (instalações, máquinas, veículos, computadores etc), humanos (colabodoradores, clientes, parceiros etc), de informação (sistemas, bancos de dados, documentos etc) além de outros não menos relevantes como produtos, serviços, concorrentes etc.

    Por fim, as duas questões  que fecham os “6 W’s”: “Quando” e “Como”. Suas respostas geram os modelos que formam a terceira perspectiva, a Visão dos Processos. Dan Roam, mesmo num contexto que é muito diferente da modelagem de negócios ‘pura’, avisa que a resposta para o “como” é a mais difícil. De certa forma ela consolida e valida tudo o que foi respondido anteriormente.

    Cabe aqui uma comparação com um tipo de modelagem mais conhecido pela maioria dos leitores do finito. A modelagem de sistemas envolve a construção de diagramas que representem dois aspectos: estrutural (diagrama de classes, por exemplo) e dinâmico (diagrama de sequência, por exemplo). Neste ponto a modelagem de negócios é idêntica. Também temos a visão da estrutura e da dinâmica (processos). A grande diferença é a existência de uma visão maior, a Visão do Negócio, que deve justificar e dar sentido para todas as outras.

    Outra observação sobre o diagrama acima: as interseções existem de fato. Há diagramas que ultrapassam as fronteiras de uma visão. O diagrama de linhas de montagem, por exemplo, combina recursos (as linhas, que podem representar sistemas de informação) que pertencem à Visão da Estrutura, com processos de negócio. A UML, de uma maneira geral, facilita a criação desses cruzamentos.

    SQVID

    Outra ferramenta apresentada em “The Back of the Napkin” é o SQVID, um seletor que nos ajuda a configurar um diagrama. Cada letra representa uma decisão que o analista deve tomar antes de começar o desenho. A lista abaixo apresenta as alternativas:

    • imples ou Elaborado: o diagrama deve ser simples ou mais completo, mais elaborado. Dan Roam lembra que o oposto de simples não precisa ser complexo.
    • ualitativo ou Quantitativo: o que é mais importante para aquele determinado diagrama, os aspectos qualitativos (e, de certa forma, subjetivos) ou quantitativos?
    • isão ou Execução: mostraremos apenas o destino (a Visão) ou é importante que o diagrama mostre como chegamos / chegaremos lá (a Execução)?
    • ndividual ou Comparativo: o diagrama tratará apenas um item ou todo o conjunto?
    • elta (Mudança – to-be) ou Como é (as-is): por fim, o diagrama mostrará o estado futuro daquilo que estamos modelando ou seu estado atual?

    Uma curiosidade sobre o SQVID. Segundo Dan Roam, sua configuração default (que forma a sigla) nos levaria a utilizar o lado direito do cérebro – ou seja, aquele que é mais “quente”, abstrato, visionário e emocional. Consequentemente, a outra configuração do seletor forçaria um raciocínio mais “frio”, objetivo, analítico, quantitativo e orientado à execução – características do lado esquerdo do cérebro. Como eu já disse no artigo anterior, Roam ampara suas sugestões em estudos da neurobiologia. Me limito a afirmar que o seletor SQVID é de uma utilidade impressionante. Ele deve ser configurado antes que uma linha seja traçada. Desta forma o analista fixa os objetivos daquele modelo, levando em consideração o perfil das pessoas que farão uso dele e o tipo de problema que pretende entender ou resolver.

    Relembrando: cada uma daquelas 6 perguntas apresentadas anteriormente nos leva a elaborar um ou mais diagramas. O SQVID nos ajuda e configurar um diagrama ou a selecionar um determinado tipo de diagrama. Cruzando essas duas variáveis geramos uma matriz, o Visual Thinking Codex, que foi apresentado no artigo anterior. Fazendo uma ‘conta de padaria’, podemos dizer que teríamos 60 tipos de diagramas diferentes (6 perguntas X 5 seletores X 2 alternativas). Não precisamos de tanto, mas o número de diagramas à nossa disposição pode ser bem maior do que aquele proposto por Dan Roam, que fixa apenas um tipo para cada questão.

    .:.

    No próximo artigo, que não demorará outros 4 meses, apresentarei as sugestões de diagramas para cada pergunta e cada opção SQVID. Inté!

    Atualização: O artigo já foi publicado – “Modelagem de Negócios: Os Diagramas“.

    Nota:

    • A imagem utilizada no topo deste artigo, flikr0627, é do flikr ou Kelbv, fotógrafo profissional que também elabora criativos desenhos (diagramas?). A variação 0627 acima foi escolhida por um simples motivo: olhares atentos perceberão 2 pessoas no centro do desenho, um AN atendendo seu cliente. Duvida? Então olhe a imagem de novo. Ou veja o destaque no Flickr.

  • Modelagem de Negócios: A Encruzilhada

    Se não vai no atacado, vai no varejo mesmo!1 Há tempos ameaço retomar a publicação de artigos técnicos aqui no finito. Tardei. Espero não falhar.

    Já comentei por aqui: a modelagem de negócios é, entre todas as disciplinas que dão forma para a engenharia de software, a menos compreendida. Consequentemente é pouco e mal utilizada. No entanto, surgem evidências e suspeitas de que esta situação deve mudar. Iniciativas SOA, BPM e de Arquitetura Corporativa, em níveis diferentes, exigem a existência ou a criação de modelos de negócios. Mas não se trata de outra demanda ‘falsa’, parida exclusivamente nos domínios de TI. O pessoal do mundo do negócio também começou a perceber os benefícios de bons modelos de negócios. O que nos traz para a encruzilhada do título. Neste artigo vou apresentar duas alternativas de modelagem, uma bem TI e outra bem “negócio”. Ambas foram apresentadas em livros lançados recentemente. E indicam um momento crítico para a evolução da disciplina.

    Encruzilhada

    Modelando Negócios, segundo TI

    Acabou de sair, pela Morgan Kaufmann/OMG (Object Management Group), o livro “Business Modeling – A Practical Guide to Realizing Business Value“, de David M. Bridgeland e Ron Zahavi. Como obras que tratam exclusivamente a modelagem de negócios ainda são raríssimas, este lançamento merece destaque. E vai receber. Repare, não se trata de um livro sobre BPM e afins. O papo aqui é apenas sobre modelagem. Os autores, otimistas, começam mostrando que a tendência é de uma crescente adoção da disciplina. E apostam que por volta de 2011 ela atingirá “massa crítica”2. Justificam suas apostas de forma simples: “a Modelagem de Negócios se tornou mais popular porque transformações em negócios se tornaram mais comuns“. E explicam que “modelos ajudam na implementação de mudanças. Se nada muda, você não precisa de modelos, assim como não precisa de mapas se não pretende viajar para lugar nenhum“.Business Modeling

    Os autores mostram que a modelagem pode gerar valor para o negócio de oito maneiras: i) Comunicação entre pessoas; ii) Treinamento e Aprendizado; iii) Persuasão e Vendas; iv) Análise de alguma situação do negócio; v) Gestão de Conformidade; vi) Desenvolvimento de Requisitos de Software; vii) Execução direta dos modelos através de mecanismos de software; e viii) Gestão do Conhecimento e Reuso.

    A lista, apesar de extensa, me parece incompleta. Neste ponto os autores não citaram a possibilidade de simulação e experimentação de novas ideias e a identificação de oportunidades de outsourcing de processos (BPO), por exemplo. Mas as omissões são relativamente pequenas. O que me preocupa de verdade são as sugestões apresentadas no livro.

    Bridgeland e Zahavi partem do princípio de que não há um padrão completo para a modelagem de negócios. E não deixam de reclamar em diversos momentos do texto a total ausência de ferramentas que contemplem uma “completa” modelagem. Eles apresentam a modelagem como um conjunto de 4 disciplinas: Modelagem da Motivação do Negócio, da Organização, dos Processos e das Regras. Completo, na visão deles, seria um padrão que possibilitasse a criação de modelos das 4 disciplinas. Eu acredito que o problema foi criado pelos próprios autores, no “quebra-cabeças” de padrões que eles selecionaram.

    Para a modelagem da motivação do negócio eles optaram por um novíssimo e único padrão existente, o BMM (Business Motivation Model), um trabalho do BRG (Business Rules Group) aceito pelo OMG em agosto de 2008. Como os próprios autores acusam, o OMG cometeu grave pecado ao aceitar e liberar o padrão antes de definir seu perfil visual – um padrão para os diagramas. O BMM cuida da visão (fim) e da missão (meios) de um negócio, de maneira abrangente e consistente. Mas parece uma ilha isolada do resto do mundo. Não se relaciona com nenhum padrão existente. Talvez o OMG tente incorporá-lo futuramente a algum metamodelo. No entanto, quando o assunto é o OMG e seus constituintes, tudo é incerto.

    Há tempos eu joguei todas as minhas fichas na EPBE (Eriksson-Penker Business Extensions). E sempre reconheci que a forma como essa extensão trata dos objetivos (motivações) do negócio é fraca. Por isso apresento mapas estratégicos e BSC’s (Balanced Scorecards) como complementos. Como a EPBE é extensível como sua base, a UML, não tive nenhuma dificuldade em incorporar a ela o BMM. Oportunamente eu falo mais sobre BMM e EPBE. Mas se você não aguenta de curiosidade, relembre aqui o metamodelo EPBE e obtenha aqui uma visão geral (bem alto nível) do BMM.

    O problema dos autores aumenta quando eles entram em sua segunda disciplina, a Modelagem da Organização. Eles afimam que não haveria um padrão para a construção desses modelos. Quem diria, nossos velhos e bons organogramas carecem de um padrão. Mas a questão não é só essa. Bridgeland e Zahavi ignoram outros recursos, outros elementos da estrutura de um negócio. Não citam, por exemplo, a necessidade de modelagem de produtos, serviços etc. A EPBE fala em Visão da Estrutura, não de Modelagem da Organização. A EPBE contempla, portanto, a modelagem de qualquer tipo de recurso.

    É fácil entender a omissão ao vermos o padrão que eles selecionaram para a Modelagem de Processos. Sim, eles optaram pela BPMN. Um padrão cheio de promessas e com um futuro promissor, mas que entrega muito pouco quando o assunto é *Modelagem de Negócios*.Sigo aguardando ansioso pelo dia em que uma boa alma apareça dizendo: “gente, BPMN é só um fluxograma 3.0 – um falso padrão3 sacaneado por ilustres fornecedores que deveriam defendê-lo. Um falso padrão que tem pouco ou nenhum valor quando nossa preocupação é entender um negócio“.

    Os autores justificam sua não opção pela UML dizendo que esta é muito ‘complicada’ para usuários finais. Concordo. Mas, apesar deles citarem o trabalho de Eriksson e Penker, “Business Modeling with UML“, ignoram por completo a EPBE. Ao relacionarem UML exclusivamente com o diagrama de atividades, demonstram desconhecer todas as outras opções de diagramas apresentadas no trabalho da dupla escandinava. Sigo desconfiado de que é este pequeno detalhe geográfico que segue fazendo da EPBE uma ilustre desconhecida.

    Problema dos autores, que tiveram que se revirar ainda mais no momento de fixar um padrão para sua última disciplina, a Modelagem de Regras. Acertam na escolha do SBVR (Semantics of Business Vocabulary and Business Rules), outro padrão adotado pelo OMG em 2008. Mas não conseguem deixar de mostrar a fragilidade das ligações desta com as outras 3 disciplinas que formam sua proposta. Eles reclamam muito da deficiência de ferramentas. O buraco é mais embaixo: os 4 padrões sugeridos pelos autores carecem de um alicerce único, de um metamodelo. Ao jogarem todas as suas fichas em padrões do OMG, implicitamente os autores apostam que esta entidade será capaz de suprir essa imensa necessidade. Ao ver os probleminhas que o OMG tem enfrentado só com a BPMN 2.0, sou obrigado a ‘mineiramente’ desconfiar. Com seus passos de cágado, talvez lá em 2037 o OMG apresente uma bela sugestão de metamodelo para uma completa modelagem de negócios. Vamos esperar sentados?

    O Negócio pelo Negócio

    É um livro de modelagem?!?Aí vem aquele “velho” cara de negócios e pergunta: “meu caro, diz aí, o tal OMG entende de negócios?” Antes que uma resposta (ou desculpa) pinte em nossas cabeças, o velho saca de sua estante um estranho livro quadrado: “The Back of the Napkin“, de Dan Roam (Portfolio – 2008). O velho nos diz: “Parece que o tal do Dan aí entende de negócios, e presta serviços de consultoria para empresas como Google, eBay, GE, Wal-Mart…”

    Se o livro de Dan Roam usou o termo “modelagem” em algum momento passou despercebido. Ele prefere o termo “Pensamento Visual”. Mas seu livro é só sobre isso: Modelagem de Negócios. Saca só o subtítulo: “Resolvendo Problemas e Vendendo Ideias com Figuras”. Não espere ver nada sobre UML, BPMN e coisinhas afins. Dan é um cara de negócios. E, por isso mesmo, insiste que devemos fugir de ferramentas informatizadas: “mão, caneta e guardanapos são suficientes para resolvermos qualquer problema de negócio!” Radical? Não, prático e pragmático mesmo. E, preciso dizer, ágil!

    Dan apresenta uma metodologia completa, formada por 4 elementos. Ele a apresenta como um “canivete suiço”. Sua primeira parte é formada por “3 ferramentas básicas para o pensamento visual”: nossos olhos, mente e mãos. Na sequência ele apresenta as 4 fases do pensamento visual: Ver, Observar, Imaginar e Mostrar4.Aí vem o SQVID5, uma série de 5 perguntas que “nos ajuda a abrir os olhos da mente: simples ou elaborado, qualitativo ou quantitativo, visão ou execução, individual ou comparações, mudança ou ‘as-is’?” Por fim as 6 formas como enxergamos que também são as formas como deveríamos mostrar, os 6W’s: “Who/what, hoW much, Where, When, hoW e Why”. Parece bobinho, não? Se você não reparou, até a sequência como o “canivete” é apresentado é “simplificadora”: 3 (ferramentas básicas), 4 (passos), 5 (perguntas) e 6 (formas de ver/mostrar).

    Parece bobinho, mas Dan escora suas sugestões em bases muitos fortes, como pesquisas muito recentes no campo da neurobiologia. Os 6 W’s, por exemplo, realmente representam a sequência pela qual nossos olhos passam informações para o cérebro. Por isso seriam intuitivas, naturais. Logo no início do livro o autor se preocupa em “escorar” suas sugestões. Em três páginas quase consecutivas ele nos convida a visitar o apêndice A, “A Ciência do Pensamento Visual”. Justamente para derrubar nossas possíveis desconfianças e mostrar que, apesar de simples, suas propostas são sérias. Aliás, a simplicidade é uma grande qualidade de seu trabalho. Porém, mais que o alicerce científico, são os casos reais apresentados que atestam a utilidade e força de seu método.

    O ‘Codex’ do Pensamento VisualAcontece que, a primeira vista, as sugestões de Dan Roam parecem totalmente incompatíveis com a disciplina que conhecemos como Modelagem de Negócios. Em nenhum momento ele cita o OMG ou coisinhas mais ‘pop’, como BPMN. Trata-se realmente de outro mundo.

    O diagrama acima mostra do “CODEX” do Pensamento Visual, uma grade que cruza os 6 W’s com as 5 decisões que tomamos no SQVID. Repare que, para cada W, Dan sugere apenas um tipo de desenho: retrato para o “quem/o que”; gráfico de barras para o “quanto”; mapas para o “onde”; cronograma ou linha de tempo para o “quando”; fluxograma para o “como”; e um gráfico comparativo (plot) para o “porque”. O SQVID ajuda a definir uma versão diferente para cada tipo de desenho.A única sugestão de Dan que se aproxima minimamente de nosso mundo é o fluxograma. Todos os outros desenhos parecem distantes de tudo que conhecemos para a modelagem de negócios: retratos, mapas, gráficos de barras…

    Precisa ser assim? Digo, TI e negócio precisam ser tão distantes até nisso, numa disciplina que deveria ajudar um a compreender melhor o outro? O mundo de TI precisa seguir insistindo em padrões lentamente definidos e sistematicamente desrespeitados?

    Como a Modelagem de Negócios é uma disciplina ainda em fase de definição, acho que é hora de revermos alguns caminhos, particularmente aqueles trilhados pelo OMG e fornecedores de ferramentas como SAP, IBM e Oracle.

    Em paralelo, os Analistas de Negócios, principais usuários da Modelagem de Negócios, devem procurar uma base que combine o melhor dos dois mundos. No próximo artigo apresentarei uma sugestão, um ‘remix’ das ideias de Dan executado na vitrola da EPBE/UML. Inté!

    Notas:

    1. O “atacado” seria o livro, que já toca neste assunto (com outras palavras. Aliás, muito mais palavras e figuras). Mas, como eu já disse em um pequeno post-agenda, não se trata apenas de um livro, mas também de um novo negócio e um sistema. Adiei o lançamento para costurar melhor todas as partes. Conto com a compreensão e paciência de todos.
    2. Em dinâmica social, massa crítica é a mentalidade de um grupo que é suficiente para, em quantidade e qualidade, permitir, propiciar e sustentar determinada ação ou comportamento. (Wikipedia).
    3. Digo que BPMN é um falso padrão porque ele não é respeitado por quase ninguém. Grandes fornecedores, como IBM, Oracle e SAP, insistem em ter seu “sabor” do padrão. Claro, assim eles dificultam a debandada de clientes insatisfeitos. Nada de novo no front de TI: SQL, HTML, COBOL e várias outras coisinhas também nasceram um dia para serem “padrões”.
    4. Minha tradução livre para Look, See, Imagine e Show.
    5. SQVID é uma sigla estranha mas de fácil compreensão: Simple, Quality, Vision, Individual e Change (D é de delta, mudança). O SQVID é apresentado como um seletor ou equalizador. O nome indica as primeiras opções. O contraponto, na mesma sequência, é: Elaborate, Quantity, Execution, Comparison e As-is.  Como o gráfico acima ilustra, para cada um dos 6 W’s escolhemos um lado do SQVID. Simples ou Elaborado, por exemplo.

    A foto utilizada neste artigo é de Kevin Slavin (Flickr). Aliás, vale a pena olhar o curioso jogo “Crossroads” que ele montou com GPS, usando Manhatan como tabuleiro.

  • Um Roadmap para Analistas de Negócios

    Quem tem acompanhado nosso pequeno mas agitado Fórum deve ter reparado: ainda há muita indefinição em torno do currículo e do job description de um Analista de Negócios. Os últimos debates, particularmente com o Ronan Lúcio e o Leandro Mendonça, me deram uma grande ajuda em uma decisão: qual item deveria sair de meu backlog (de artigos e temas represados – haha) e vir para cá, para o blog. Há tempos adio esta publicação, com a falsa esperança de conseguir desenhar um mapa completo que mostre os caminhos para a Formação de um Analista de Negócios (AN). Passou da hora dessa discussão se tornar pública. Ao mapa (versão Beta):

    Um Roadmap para Analistas de Negócios

    Antes, os créditos: foi o André Wolff quem deu a sugestão de usar um desenho parecido com aqueles mapas que apareciam nos livros da Wrox. E algumas caixinhas acima só apareceram por causa de depoimentos (e desejos) dos colegas Leandro e Ronan.

    Talvez o meu rabisco não dê esta impressão, mas ainda há muito espaço a ser preenchido ali. Tentei destacar o fundamental, inclusive no tópico ‘Formação Complementar’. E, claro, não contemplo nenhum treinamento de ‘Habilidades Sociais’ (Soft Skills). O desenho trata exclusivamente de ‘Habilidades Técnicas’ (Hard Skills). Cabe uma breve descrição de cada caixinha:

    FAN – Entendendo o Negócio é o programa que ‘roda mundo’ há pouco mais de um ano. Sua versão ‘oficina’ (workshop – 7 horas) dá uma visão geral de tudo que está inserido no tema “Modelagem de Negócio”. O curso (35 horas) permite o detalhamento e prática de alguns temas, particularmente a modelagem de negócios com UML e sua extensão EPBE (Eriksson-Penker Business Extensions).

    A relativa complexidade da EPBE e, principalmente, da Modelagem de Negócios, justifica a existência de um módulo avançado, o FAN – Modelando Negócios com UML/EPBE. Imagino um curso 100% prático, com a modelagem de um negócio “inteiro”. Teria algo entre 32 e 40 horas. Imagino… teria… Sim, por enquanto este módulo é só uma idéia.

    FAN – Business Patterns  segue no mesmo caminho. Só o livro de Eriksson e Penker apresenta algumas dezenas de patterns. Debatê-las e praticá-las em um treinamento faz todo o sentido. O problema aqui é nosso nível de maturidade quando o assunto é modelagem de negócios. Ou seja, é idéia para a próxima Copa do Mundo. E olhe lá!

    Apesar de meu “apego” à EPBE, não posso ignorar a crescente demanda por profissionais que dominem a Modelagem de Processos de Negócios com BPMN. Não tenho condições de oferecer tal treinamento. Por isso este módulo não tem a marca “FAN”. É o mesmo caso do Modelagem com Aris/EPC.

    Destaquei dois módulos em Formação Complementar que estão diretamente relacionados com a Modelagem de Negócios: i) Balanced Scorecards & Mapas Estratégicos, ferramentas que enriquecem consideravelmente um modelo de negócios – facilitando o entendimento de objetivos, metas, oportunidades e problemas; e ii) BPM (Business Process Management), um universo em si. Tanto que, neste ponto, imagino apenas um treinamento de introdução ao BPM. Reparem, BPMN está em outro canto.

    Segurei a tentação de colocar caixinhas SOA e Arquitetura Corporativa aqui por dois motivos: estamos tratando da Formação de Analistas de Negócios. Lotar o módulo Formação Complementar pode gerar muita dispersão de atenção. Mantive o básico. Pelo menos, enquanto as duas áreas de cima não estiverem melhor resolvidas. Vamos então ao amplo e “polêmico” módulo Engenharia de Requisitos:

    FAN – Entendendo o Usuário também faz parte do programa que tenho apresentado. A oficina (7 horas) trata do básico, com ênfase no Desenvolvimento de Requisitos. O treinamento de 35 horas permite uma maior exploração de algumas técnicas, particularmente a especificação de casos de uso e a realização e facilitação de entrevistas, sessões JAD etc.

    Como temos visto no fórum, o tema ‘Casos de Uso’ é mais cabeludo e incompreendido do que imaginamos. Por isso ele merece um módulo adicional, Escrevendo Casos de Uso, que desenvolvo há 2 meses. Deve se transformar em um curso prático, de 40 horas. Isso tudo? Sim, pelo que descobri, o tema merece. Mas deve existir uma versão oficina (7 horas) também.

    E faz todo o sentido que o roadmap contemple também o módulo Escrevendo Users Stories. É uma alternativa aos casos de uso. Tenho lá minhas restrições, mas não posso ignorar sua adoção e eficácia em alguns projetos. Só não me habilito a formatar e oferecer tal treinamento.

    Assim como, por enquanto, me manterei relativamente distante do Gerenciamento de Requisitos. É importante destacar que quando falo Gerenciamento de Requisitos estou falando também de Gerenciamento de Mudanças.Coloquei aqui apenas dois módulos: No OpenUP e No Scrum. (Obs: “No” não está em inglês, ok?).

    Derivam deste último módulo duas sugestões para a formação complementar: Gerenciamento de Projetos e Scrum. Não é para o AN se bandear para o gerenciamento de projetos, please! Acontece que suas atividades se entrelaçam demais com aquelas de um gerente de projetos. É legal que ele conheça a disciplina de uma forma mais ampla.

    Por fim, abri um módulo que é meu “xodó” mais recente: uma oficina que exercite exclusivamente as diversas técnicas de descoberta, aprendizado e descrição de requisitos: Entrevistas, JAD, 6 Hats…  Xodó meu, não sei se há demanda. Quero crer que sim. É outro item de meu backlog que anda clamando por atenção. Sua aparição aqui pode dar o empurrão necessário.

    Aliás, a grande motivação para este post é exatamente essa: empurrões! Algumas definições & idéias! E, claro, uma deixa-provocação: será que alguém (alguma instituição) consegue oferecer todo esse roadmap como um programa único? Alguém aí quer tentar preencher as caixinhas não assinadas? E colocar novas caixinhas? É isso. Inté!