EPBE: Quem usa?
Desde a semana passada estou envolvido em debates sobre a EPBE (Eriksson-Penker Business Extensions), uma extensão da UML para modelagem de negócios. O provocador das discussões foi o mesmo, José Augusto Agnello. O primeiro debate, no grupo UML-BR, começou com BUC's (Business Use-Cases). Já no grupo BPM o Agnello foi direto: alguém usa? Como ela se compara com BPMN?
Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN's e da EPBE em um grupo "pesado", o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro "brinde" veio hoje: a "desconfiança" de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.
Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro "Business Modeling with UML". Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha "tese". Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: "caramba, ninguém usa isso!".
Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: "que p**** é essa?". Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma - caramba, é uma linguagem! - ela é muito nova. Por outro - pô, informática! - ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?
Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: "a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas". Seria outro caso de uma boa idéia carente de um bom marketing.
Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro "Business Modeling with UML" no site da Amazon. Surrupiarei alguns trechos:
"The 'Eriksson-Penker extensions for business modelling' are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read."
- A.K. Johnston
"Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models."
- J. Chong
Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.
Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar "analistas-programadores"; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.
Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:
Observações:
* Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.
** Adjetivos pouco nobres (como o "capenga" acima) vivem me criando problemas. Um dia foram as "bullshitagenzinhas ágeis". Hoje foi o BPMN "bonitinho". Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora - na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.
No UML-BR, "brigando" com o MT na questão "BUC's X EPBE", eu usei "fraquinho" no lugar do "capenga". É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.
Mas aqui cabe uma explicação: sou fã do Jacobson. Seu "The Object Advantage - Business Process Reengineering with Object Technology" é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.
Dica levemente acoplada: não percam o artigo de hoje do Philip "Shoes" Calçado, no Fragmental.
Sem querer o Agnello me possibilitou duas coisas: validar a recepção dos AN's e da EPBE em um grupo "pesado", o UML-BR. Poder debater e trocar idéias com José Paulo Papo, MTierno, Juan Bernabó, Rodrigo Yoshima e outros é sempre enriquecedor. O outro "brinde" veio hoje: a "desconfiança" de que ninguém utiliza a EPBE. O grupo BPM tem 500 e poucos participantes. Há duas horas eu só penso nisso.
Caramba, baseei boa parte do meu trabalho para formação de analistas de negócios na EPBE e nos conceitos apresentados por seus idealizadores, Hans-Erik Eriksson e Magnus Penker, no livro "Business Modeling with UML". Nessa altura do campeonato, na reta final e de certa forma cansado do tema, a última coisa que eu preciso é de dúvidas sobre uma das partes principais de minha "tese". Não estou falando das dúvidas e críticas dos outros. Estou falando que eu não posso duvidar de minhas sugestões. Mas, no cansaço e com um probleminha chato nas costas, confesso que hesitei por alguns minutos: "caramba, ninguém usa isso!".Me lembrei que já passei por isso antes. No final de 98, por exemplo, quando falava que ia utilizar UML em um grande projeto, um monte de gente me olhou com cara de interrogação, tipo: "que p**** é essa?". Dali até os primeiros diagramas de seqüência com algum sentido passou um certo tempo. Dali até uma certa aceitação da UML foi outro tanto de tempo. Mês que vem a UML completará 10 anos de existência. Sob um prisma - caramba, é uma linguagem! - ela é muito nova. Por outro - pô, informática! - ela é velha. Mas a EPBE é do ano 2000. E parece não ter aceitação nenhuma*! O que pode estar errado?
Richard Lingner, em sua participação na thread do BPM, apresentou algumas razões: "a EPBE não é mantida pelo OMG e também não é difundida ou suportada por empresas e ferramentas". Seria outro caso de uma boa idéia carente de um bom marketing.
Mas quem a considera uma boa idéia? Definitivamente, eu não estou sozinho. Vejam, por exemplo, as avaliações que os leitores do livro "Business Modeling with UML" no site da Amazon. Surrupiarei alguns trechos:
"The 'Eriksson-Penker extensions for business modelling' are important because several UML-based case tools have now implemented them as an emerging standard for business process modelling with UML. If you want to fully understand how these work, this is the book to read."
- A.K. Johnston
"Sometime ago I have been wondering if somebody will try to bridge the gap between business modeling (the one used by consultants) and software engineering. It would certainly make it easier for people to understand and explain business operations. This book is an application of the UML into the realm of business modeling. It is very good in the sense that it explains and goes through the patterns that form business models."
- J. Chong
Claro, tem também algumas críticas negativas (ao livro). Mas sua média é 4 estrelas! As avaliações que citei são de 2003 e 2000, respectivamente. E, sabe-se lá a razão, parece que pouquíssimos conhecem a EPBE.
Suspeito que o buraco é mais embaixo. Como eu disse no post anterior, a análise e modelagem de negócios é a disciplina mais ignorada em nossos projetos. E quando ela aparece, em modelos RUP-like, é meio capenga**. Se a disciplina é negligenciada, o que esperar das ferramentas que devem suportá-la? Correndo o risco de ser (muito) chato, vou reforçar minha suspeita: currículos, processos e metodologias dão atenção desproporcional para o domínio da solução; Parecemos adorar "analistas-programadores"; Esquecemos que sem o correto domínio do problema podemos gerar falsas e caras soluções.
Essa questão me preocupa bem mais que a aceitação ou não da EPBE. A EPBE é só uma extensão de uma linguagem. É só uma ferramenta. Ferramentas passam. Mas eu acho que o OMG e todos os fornecedores de ferramentas CASE que ignoram a EPBE estão perdendo uma bela oportunidade. O OMG, por exemplo, poderia incorporar a extensão e adicionar a opção BPMN à ela. Reforçariam assim a UML, expandindo consideravelmente o seu público. Sendo chato (de novo!), reforço as motivações para sua utilização:
- UML já é uma linguagem madura e consolidada;
- Utilizada amplamente no domínio da solução;
- Por que não utilizá-la também para a modelagem do problema?
- Assim, TI e negócio teriam pela primeira vez em sua história uma mesma língua - mesmo que ela seja "só" para modelagem.
.:.
Observações:
* Os workshops para formação de analistas de negócios já contaram com mais de 150 participantes. A EPBE é apresentada neles, mas de forma breve. Então, só depois do treinamento que ocorre agora em novembro poderei dizer se a EPBE ganhou novos adeptos.
** Adjetivos pouco nobres (como o "capenga" acima) vivem me criando problemas. Um dia foram as "bullshitagenzinhas ágeis". Hoje foi o BPMN "bonitinho". Não adianta, não me livro deles. Não acho sinônimos que passem exatamente o que quero expressar naquele momento. Até me arrependo depois. Mas, na hora - na lata, não edito não. Também não edito depois, a menos que alguém se diga ofendido. Nunca aconteceu.
No UML-BR, "brigando" com o MT na questão "BUC's X EPBE", eu usei "fraquinho" no lugar do "capenga". É a mesma coisa. Fica feio do mesmo jeito. Peço desculpas.
Mas aqui cabe uma explicação: sou fã do Jacobson. Seu "The Object Advantage - Business Process Reengineering with Object Technology" é fonte frequente de consulta para desenvolvimento do meu material. Mas, definitivamente, casos de uso de negócio e modelos de objetos de negócio não são ferramentas legais para a análise e modelagem de negócios. Probleminha básico: assim como a BPMN, são incompletos. A arquitetura de um negócio é descrita em quatro visões: Negócio, Estrutura, Processos e Comportamento. Qualquer proposição que vise a análise e modelagem de negócios deve cobrir as 4 visões. Ponto.
.:.
Dica levemente acoplada: não percam o artigo de hoje do Philip "Shoes" Calçado, no Fragmental.
.:.
Marcadores: analista_de_negócios, epbe, modelagem_de_negócios, uml
terça-feira, 23 de outubro de 2007 |
Assine o finito
Lista completa no del.icio.us
Paulo, dá para entender o seu desalento com a quase incipiente adoção de uma prática que poderia trazer um enorme ganho através da aproximação dos negócios com a TI através de uma linguagem unificada de modelagem.
Não vou fazer de conta que estou no grupo das pessoas que utiliza EPBE, na verdade vou comprar o livro e ir atrás disso pois sinto falta à tempos. Até o momento minha unica ferramenta de união entre negócio e TI são os casos de uso sumários onde sistema em design é a empresa, ou seja, os conhecidos casos de uso de negócios (casinha pretinha e nuvem, como ensinou o professor Cockburn).
As vezes simplesmente não dá para entender porque os profissionais não utilizam as ferramentas disponíveis. Parte é por desconhecimento, a outra parte é mais difícil de explicar.
Vejamos um exemplo extremo. Infecção hospitalar. É um problema horrível, faz com que pessoas já doentes passem mais tempo no hospital e até mesmo venham a falecer devido à ela.
Na luta contra a infecção hospitalar podemos utilizar muitas ferramentas. A medicina avançou muito nos últimos tempos e podemos matar bactérias com incríveis antibióticos e até nano tecnologia.
O problema é que essas ferramentas são para os casos extremos e custam muito. A ferramenta mais eficaz contra a infecção hospitalar é a lavação das mãos e sabemos disso desde Pasteur.
Agora me explique porque os profissionais de saúde parecem ignorar isso e continuam agindo como se suas mãos fossem estéreis sem que pudessem servir de transporte para as bactérias e outros bichinhos que podem matar seus pacientes?
É tão absurdo que faz a questão do alinhamento da TI com o negócio parecer banal.
Minha teoria está na distância entre nossas ações e suas conseqüências. Tanto no hospital quanto nas empresas, as conseqüências do que fazemos, apesar de grandes parecem estar distantes e afetar os outros. Isso tira o senso de responsabilidade.
Focamos na tecnologia mais interessante, no último lançamento e esquecemos que no final trabalhamos por um paciente ou por um negócio. Utilizar uma nova tecnologia revolucionária para fazer algo sem função para o negócio é tão absurdo quanto utilizar um equipamento de milhões de reais para efetuar um procedimento cirúrgico e colocar mãos sujas dentro do paciente.
A má gestão parece ser tão invisível quanto as bactérias, e tão letal quanto também.
Gente... foco e alinhamento traz sentido para nossa vida e benefícios para quem vive ao nosso redor.
Com as facilidades que possuímos hoje para o desenvolvimento de software (ferramentas, linguagens de alto nível, frameworks e novos conceitos), está sobrando cada vez mais tempo para os profissionais (?!) de T.I se tocarem que o cliente não sabe muito bem o que quer, sendo nossa função apresentar as possíveis soluções e seus impactos, deixando a decisão final nas mãos do cliente.
Atualmente grande parte das empresas trabalham para manter dois sistemas: o sistema do cliente (baseado não-misticamente no negócio propriamente dito) e o sistema utilizado para manter essas informações.
O sistema do cliente é cego, surdo e mudo, o sistema/arcabouço gerado pela empresa que desenvolveu o software está pra lá de Frankenstein. Quando são harmonicos ainda vá, mas parece que o pessoal gosta mesmo é de dissonância pura e aplicada (falta de instrução musical na infância).
Rezo para que o EPBE pegue, é uma peça chave para limpar o nome sujo dos profissionais de T.I.
Paulo, como está a adoção do EPBE no exterior?
Olá Kerber e Dimas,
agradeço os comentários e peço desculpas pela demora de meu retorno. Anda corrido.
Dimas, a adoção me parece só um pouquinho maior do que a que vemos aqui. Ou seja, mínima mínima para dizer o mínimo, hehe. Uma busca no Google por "epbe eriksson" retorna apenas 93 links! Reparei que em uma parte deles tem o meu dedo...
Eu sei, é triste. Mais ainda se lembrar (de novo!) que o uso da UML para modelagem de negócios também é muito pequeno. Mas o fato é que a gente não modela negócios. Repito: é a disciplina mais ignorada em projetos de TI.
Então, não me espanta que EPBE e UML sejam sumariamente ignoradas.
Abraços
Pois é Paulo, o primeiro parágrafo do seu último post passa bem a idéia da sua rotina recente.
Sobre EPBE, como você disse, não "Chororô só não basta", então já estou como livro na mão.
O objetivo é quando eu participar de um evento seu no futuro, ser um dos que levantam a mão quando você pergunta se alguém conhece.
Sobre as comparações que eu fiz com a metodologia adotada, posso adiantar, mesmo antes de ler o livro, que me equivoquei. As coisas são parecidas, mas não são iguais.
Utilizar UML para modelar entidades com relação próxima com o negócio é diferente de modelar o negócio em si. A primeira ainda está muito próxima do sistema que irá suportar o negócio.
Alguma chance de fazer um evento em Florianópolis? Estou dando uma boiada para não precisar entrar em um avião nesse país :)
Oi Kerber,
Pois é, entre a proposta da EPBE e as sugestões do RUP (e daquele livro citado por ti, para ITBA's) há uma grande distância. O que me encuca é a opção de descrever um processo ou atividade de negócio na forma de um BUC. Caramba, até os tradicionais fluxogramas são mais eficazes... Mas tudo bem.
E seria uma felicidade imensa ver alguém nos workshops mostrando um pouco de sua experiência com EPBE. Sendo você, tão ativo neste espaço nos últimos tempos, tenho certeza de que seria uma colaboração muito rica.
Eu tinha sim a perspectiva de realizar uma versão do FAN aí em Floripa neste final de ano. Mas a empresa "sumiu" e não deixou nenhuma satisfação. Uma pena.
Mas, se vc tiver alguma dica de alguma empresa que se interesse em levar o evento, será uma grande satisfação.
Mas de avião eu não vou não. Então enfrento outros milhares de quilômetros de asfalto, hehe. Sem problemas. Tô ficando treinado...
Abraços,
Paulo, gostamos de casos de uso de negócios não pelo fluxo em si, que seria bem representado em um diagrama, o que faz a diferença são as outras partes que nos levam a muitas descobertas durante a análise:
- Meta
- Intervenientes e Atores
--- O ator primário
--- Os atores de suporte
--- Os atores silenciosos
--- O sistema em discussão
- Pré-condições
- Garantias mínimas
- Garantias de sucesso
- Gatilhos
- Cenários
--- Cenário principal de sucesso
--- Fluxos alternativos
Geralmente quando uma análise falha, a causa é não dar atenção à um interveniente (em português, stakeholder).
Outra questão interessante é o estudo dos fluxos alternativos, eles ficam bem claros no caso de uso escrito e seu tratamento também. É importante verificar que trabalhamos com diferentes níveis de abstração nos casos de uso, e os passos de um caso de uso de negócio caixa branca correspondem na maior parte dos casos aos casos de uso de sistema caixa preta.
Outro aspecto interessante é o nível de precisão. A idéia é começar com a acuidade, primeiro temos que estar certos de que o que está sendo modelado é correto, depois vamos em direção à precisão. Para isso, podemos utilizar os seguintes artefatos:
- Narração de uso
- Briefings de casos de uso
- Casos de uso
--- Primeiro o nome do ator e a meta
--- Depois o fluxo básico, o cenário principal de sucesso (que todos conhecem)
--- Depois se levantam os fluxos alternativos nos quais se levantam várias regras de negócios.
--- Por fim, se trabalha como tratar cada fluxo alternativo.
Trabalhando com todos os intervenientes em todos os níveis dos casos de uso e partindo da acuidade à precisão estamos evitando muitos problemas de escopo nos projetos. O legal dos casos de uso é que eles não são úteis como documentação apenas, eles ajudam muito no durante.
Sobre Florianópolis, fui a um evento de ITIL bem organizado aqui na cidade pela empresa SC Marketing, eles conseguiram reunir a massa crítica da cidade no assunto para o evento.
Oi Kerber,
Caramba, depois de algumas semanas de discussão (em outro fórum), é a primeira vez que vejo alguém ser tão claro e didático na justificativa para adoção dos BUC's. Parabéns pelo texto.
Para ficar claro: gosto muito dos casos de uso, da *ferramenta*. Mas só utilizo aquele que agora é conhecido como "caso de uso de sistema". E defendo seu uso como *meio*, como a principal ferramenta de apoio para a descoberta e desenvolvimento de requisitos. Colocando de outra foram: acho os UC's um péssimo tipo de documentação. E não sei se é só questão de gosto.
Mas vou aguardar que você conheça a EPBE. Talvez pinte em seu blog um comparativo... o que você acha? Seria legal. Farei um aqui, na série sobre EPBE. Mas o seu ponto de vista pode enriquecer muito o debate. Aí a gente faz uns links cruzados, hehe.
Muito obrigado pelo (rapidíssimo) comentário.
Abraços,