A abordagem de modelagem de processos tem sido muito discutida e quase sempre recomendada para iniciativas SOA. A massiva propaganda e momentum BPM parece nos indicar que é sempre interessante modelar processos para resolver um problema. A realidade, entretanto, é diferente da teoria, baseado em um cenário real que discuti hoje no começo da noite em uma empresa que está em uma franca implementação SOA.

Ouvindo John Zachman

A figura abaixo mostra o Zachman Framework. A coluna “How” é o domínio do BPM. A coluna “What” é o domínio das capacidades. A coluna “When” é domínio dos eventos complexos (CEP).

Processos expressam como fazer alguma coisa. Antes de pensar no como, entretanto, devemos pensar no que devemos fazer. Estes quês denotam as capacidades a serem desenvolvidas dentro de uma organização e, surpreendentemente, podem levar a uma abordagem completamente diferente que não implica no como, mas no quando.

Detecção de Fraudes e Processos de Manufatura

Considere uma capacidade de uma seguradora de detectar fraudes. A abordagem tradicional BPM iria buscar modelar os processos que podem detectar uma fraude. Entretanto, modelar a classe de processos que detectam fraudes pode levar uma conjunto extremamente complexo de variações que são muito difíceis de manter na prática. É um caso completamente antagônico ao processo de manufatura fabril, que pode ser classicamente modelado através de um processo discreto com variações conhecidas a priori.

A abordagem de captura de fraudes pode ser endereçada por uma outra dimensão na figura do Zachman Framework, que é a dimensão do quando, ou da modelagem de eventos complexos. A modelagem de eventos complexos nos dá instrumentos matemáticos muito interessantes, que resumo na figura abaixo que retrata as capacidades de um produto open-source popular neste meio, o Drools Fusion.

A figura abaixo mostra padrões intervalares e correlações temporais espaciais que podem ser capturadas através de máquinas de inferência de eventos complexos.

Por exemplo, com eventos complexos, podemos habilitar uma máquina de inferência para monitorar em um cenário de uma seguradora que dispare um alerta na ocorrência de pelo menos três das condições abaixo quando um novo “fato”de Sinisto ocorrer.
- Atraso na denúncia de mais de 72 horas;
- Número excessivo de testemunhas (maior que 3)
- Ausência de testemunhas.
- Sinistro que melhora situação difícil (situação cadastral ruim no SERASA).
- Desproporção entre causas e efeito do sinistro.
- Sinistro acontecido em ambiente familiar ou de amigos.
- Dificuldades ou demora em fornecer os documentos pedidos.
- Excesso de sinistros ou sinistros não compatíveis no período (saúde).

Naturalmente, não advogo que CEP deve ser usado para qualquer cenário. O CEP é indicado para alguns cenários bem específicos e deve ser realizado com bastante cautela.

A regra é que alguns problemas requerem uma abordagem baseada em processos e outros problemas requerem uma abordagem centrada em eventos. Outros problemas requerem as duas abordagens. Entretanto, todos os problemas podem ser modelados dentro do contexto da Arquitetura Corporativa, no contexto do Zachman Framework.

Tales from the Crypt é uma série de TV com contos macabros e de horror, que fez algum sucesso no Brasil nos anos 90. Indo da ficção para o mundo real de TI, vejo contos da cripta de TI que são muito mais assustadores do que aqueles que assistia na minha velha e ultrapassada TV do milênio passado. Compartilho aqui uma (triste) história da cripta de TI.

História de Hoje - O Analista Frankenstein
O analista Frankenstein é um ser puramente tecnológico, que acredita que ferramentas e tecnologias precedem o entendimento de capacidades de negócio, processos, regras e dos conceitos de negócio. Formado a partir de códigos Java, .NET, bancos de dados e outros fragmentos tecnológicos, este ser horrendo, que habita as TIs de todo o Brasil, usa a sua tecnologia para resolver qualquer problema.

Quando ainda criança (na faculdade), o analista Frankenstein foi educado em C++, Java, .NET e engenharia de software por seres de outras dimensões que nunca entregaram uma linha de código em um ambiente de produção no planeta Terra.

No seu primeiro estágio, o analista Frankenstein foi educado em técnicas de escrita de código-spagetti por monstros experientes em repetir os mesmos erros por mais de 20 anos e que se orgulham de não ler um único livro de TI desde que saíram das suas faculdades.

No seu primeiro emprego, o analista Frankenstein aprofundou o seu conhecimento do lado negro da força com a escrita de código lasanha, criando aplicações com 8 camadas lógicas para implementar uma simples aplicação Web corporativa.

Conseguiu a sua primeira promoção com a disseminação do horrendo padrão Modelo de Domínio Anêmico, criando “código OO” com “classes” de dados e “classes” de negócio.

Depois de cinco anos, o analista Frankenstein já se intitulava monstro sênior, e assim era reconhecido por seus pares horrendos. Ele aumentou o seu arsenal tecnológico indicando servidores de aplicação e ESBs para toda e qualquer demanda, mesmo que o problema fosse apenas acessar um banco de dados. Ele somou ao seu curriculum certificações de todos os grandes fornecedores de mercado e usa a sua imensa lista de certificações no seu horrendo email, que tem uma assinatura maior que a mensagem do corpo.

Este monstro horrendo, após dez anos, já havia passado por várias empresas e causado prejuízos gigantescos e contribuído pela má reputação que a TI goza junto às áreas de negócio.

Astuto, este monstro abandona a empresa quando a tecnologia inadequada começa a mostrar os seus resultados ruins e assim vai assombrando outras organizações. Infelizmente ele não é visto desde o ano passado e o seu paradeiro é desconhecido. Felizmente, ele pode ser desmascarado com seis perguntas simples, que compartilho abaixo:

• Você elicitou, desenvolveu e priorizou os condutores de negócio mais importantes para o aumento das capacidades de negócio da sua organização?
• Você desenvolveu uma arquitetura agnóstica de tecnologia para capturar as abstrações chave e mecanismos derivados dos condutores de negócio?
• Você buscou e avaliou as tecnologias que respondem de forma sincera aos requisitos da arquitetura candidata, incluindo as tecnologias já experimentadas e maduras da sua organização?
• Você experimentou e provou a tecnologia com uma ou mais provas de conceito que exercitaram os cenários de negócio mais signicativos para os seus usuários chave?
• Você estaria disposto a aprender e usar outras linguagens de programação, caso estas linguagens se mostrarem mais adequadas à nossa empresa?
• Você fala mal das tecnologias e linguagens de programação que você não usa como se fossem os times de futebol que jogam contra o seu time do coração?

Pensamento do dia: He cried in a whisper at some image, at some vision—he cried out twice, a cry that was no more than a breath—”The horror! The horror!” – Joseph Conrad, Heart of Darkness

Era uma vez, na época em que os animais ainda falavam, três porquinhos que viviam felizes e despreocupados como analistas de sistemas nas suas empresas. Seus nomes eram Fanático, Lunático e Pragmático. Certo dia, os porquinhos foram promovidos a arquitetos de software pelo rei da floresta, o rei Leão.

O rei Leão disse:
- Queridos colaboradores, vocês já estão bem crescidos. Já é hora de terem mais responsabilidades e para isso é bom morarem sozinhos e construírem suas próprias casas.

Os três porquinhos arquitetos, então, partiram pelas florestas corporativas em busca de um bom lugar para construírem as suas casas. Porém, no caminho começaram a discordar sobre como construir as suas casas.
Cada porquinho queria usar um metodologia diferente.

O primeiro porquinho, o porquinho Fanático, um dos preguiçosos, foi logo dizendo:
- Não quero ter muito trabalho! Ouvi falar de um método ágil chamado Screw It! que diz que casas de palhas são mais rápidas. Não precisamos de plantas, nem fundações e por isso são muito rápidas. Basta comprar um monte de palha e empilhá-la.

O porquinho pragmático advertiu:
- Uma casa de palha não é nada segura.

O outro porquinho, o irmão do meio que era chamado de porquinho Lunático também deu seu palpite:
- Prefiro terceirizar a minha casa, que será de madeira. Recebi uma planta arquitetural em um Documento de Arquitetura de Software de 200 páginas da empresa ACME, a preços módicos e condições de financiamento incomparáveis.

Comprar uma casa baseada apenas na planta arquitetural não é nada seguro - comentou o mais velho. Como você vai garantir que os materiais estarão corretos e que a fundação suportará o seu peso? Onde estão as provas de conceito e a arquitetura executável? Esta planta foi assinada por um engenheiro?

Os porquinhos ironizam o porquinho Pragmático, o mais velho, que foi construir a sua casa de tijolos com métodos arquitetônicos provados. Ele montou uma planta arquitetural, organizou os materiais corretos, fez provas de conceito e acompanhou os resultados do trabalho em conformidade com a planta.

Os outros porquinhos também começaram a criar as suas casas. Na primeira semana, o porquinho fanático terminou a sua casa. Já estava descansando quando o irmão do meio, que havia construído a casa de madeira chegou chamando-o para ir ver a sua casa terceirizada, cuja fachada era igualzinha ao prometido na planta arquitetural.

Os porquinhos preguiçosos, o Lunático e o Fanático, foram visitar seu irmão mais velho, o porquinho Pragmático.

O porquinho Fanático disse:
- Nossa! Você ainda não acabou! Não está nem na metade da Fase de Elaboração! Nós agora vamos almoçar com o Rei Leão, que ficou feliz ao receber mais duas casas da sua floresta. Ele está pensando em nos promover a gerentes!! hahaha… Se você fosse agilista como eu, teria terminado a sua casa.

O porquinho mais velho porém não ligou para os comentários e continuou a trabalhar. Ele preparava o cimento e montava as paredes de tijolos. Após quatro semanas de trabalho intenso, a casa de tijolos estava pronta, e era robusta!

Os dias foram passando, até que um lobo, chamado Mudança, percebeu que havia porquinhos morando naquela parte da floresta. O Lobo Mudança foi então bater na porta do porquinho mais novo, o da casa de palha.
Ele soprou, soprou e soprou e as mudanças vieram. A casa do porquinho Fanático sucumbiu e ele correu para a casa do porquinho Lunático.

O Lobo Mudança foi bater agora na casa do porquinho do meio, o Lunático. Ele soprou, soprou e soprou e mais mudanças vieram. A casa terceirizada não tinha uma boa estrutura e a madeira estava infestada de cupins. A casa sucumbiu e então os dois porquinhos correram para a casa do irmão mais velho, o porquinho Pragmático.

O Lobo Mudança foi agora bater finalmente na casa do porquinho Pragmático. Ele soprou, soprou e soprou. Entretanto, a casa era robusta e o lobo Mudança não conseguiu desmontar a casa com a boa arquitetura.

O Rei Leão soube do ocorrido e foi correndo para a casa do porquinho Pragmático. Ele despediu e comeu os porquinhos preguiçosos em um almoço corporativo de lombo com pururuca. O Lobo Mau foi também convidado e se deleitou com a iguaria corporativa fornecida pelo rei Leão.

No fim, o Rei Leão, o Lobo Mudança e o Porquinho Pragmático viveram felizes para sempre!

Qualquer semelhança com fatos e evento reais não é mera coincidência.

O movimento antropofágico, cunhado por Oswald de Andrade nos anos 20, propunha a “Devoração cultural das técnicas importadas para reelaborá-las com autonomia, convertendo-as em produto de exportação”.

Processos de software, como o AUP, RUP ou o XP são elementos muito complexos, compostos por diversas técnicas, métodos, papéis e pontos de extensão. Não é de se estranhar que a tarefa de implantar processos de software em organizações seja muito complexa e falhe em grandes partes das tentativas. É consenso que um processo deve ser personalizado à sua realidade para que ele funcione. Ao tentarmos personalizar um processo completo, temos muito trabalho e muitos pontos de divergência cultural com a realidade da organização alvo.

Antropofagia de Software

Como engenheiros de software, também devemos praticar a antropofagia dos processos de software e esquartejá-los em “práticas de processo”. Uma prática de processo é uma melhor prática, provada em diversos cenários e projetos. Uma prática de processo tem algumas características importantes, tais como: ser atômica, facilmente implantável e composível com outras práticas.

Exemplos de práticas de processo incluem:

• Projetos iterativos
• Modelagem de casos de uso
• Modelagem arquitetural
• Casos de teste
• Revisão pelos pares
• Planning Poker/Wide Band Delphi)
• Daily Builds (Produtos diários)

As vantagens de adotarmos e implantarmos práticas de processo, ao invés de um processo completo, são várias. Podemos destacar:

• Redução do risco de transformações culturais em times.
• Retorno mais rápido do investimento.
• Adequação a realidade cultural de cada empresa
• Possibilidades de composição com outras práticas para a montagem do um processo personalizado

As escolas mais modernas de processos tem adotado o conceito de práticas de processo em sua essência. Exemplos são o RUP 7.5 e o Essential UP, de Ivar Jacobson. O SCRUM, que tanto sucesso faz atualmente, tem a sua maior força na sua pequena essência, composta de um pequeno conjunto de práticas gerenciais ágeis.

Pensamento do dia: “Menos é mais”, Ludwig Mies van der Rohe

Arquiteturas ágeis partem da premissa que nem todo condutor arquitetural possa ser antecipado e desenvolvido antes que a primeira versão do produto vá para a produção. Normalmente, arquiteturas ágeis procuram implementar os elementos técnicos críticos ao longo das entregas parciais de um produto ou projeto, em conjunto com as funcionalidades de maior valor de negócio para os seus usuários

Esta abordagem é, tecnicamente falando, bem mais arriscada que manter uma fase de elaboração que procure acomodar os riscos técnicos através da realização de todos os condutores arquiteturais importantes. Métodos como o UP usam a abordagem tradicional, enquanto métodos como o XP usam a abordagem ágil.

De volta às arquiteturas ágeis, como lidar com o dilema de intercalar condutores arquiteturais, elementos funcionais e software em produção. A chave para lidar com a antecipação de um investimento arquitetural para uma futura funcionalidade, segundo Nanette Brown, é fazer a você e ao seu time as seguintes perguntas:

• O quão provável que a futura funcionalidade seja realmente necessária no produto? É importante lembrar, conforme pesquisas diversas (ex: Standish Group), que quase metade das funcionalidades solicitadas de um produto são raramente ou nunca usadas.
• Existe um investimento arquitetural que eu possa fazer agora que irá reduzir o custo futuro de implementar esta funcionalidade?
• Qual o custo do investimento arquitetural? (ex: custo da oportunidade, custo de implementação)
• Qual a consequência econômica de no futuro precisar implementar a funcionalidade sem o investimento arquitetural realizado a priori?

A metáfora do cheque especial

O famoso agilista Ward Cunninghan possui uma excelente metáfora, do cheque especial, que compartilho aqui. Ele diz que ao entregarmos um produto com uma arquitetura sub-ótima (ex: não performática ou com uma usabilidade deficitária, caso estes sejam condutores importantes), estamos usando um cheque especial técnico.

Os juros deste cheque especial implicam que futuras melhorias no sistema irão custar mais tempo e esforço para serem atendidas. Por exemplo, é claramente mais simples montar um sistema com um estilo de acessibilidade WCAG AA previamente definido do que refatorar 50 páginas em produção para se adequar a este condutor.

Se as técnicas de refatoração arquitetural não forem usadas para pagar a dívida técnica a tempo, o sistema irá se degradar tecnicamente ao longo do tempo e levar o seu “sistema econômico” à falência.

Como todo empréstimo bancário, devemos avaliar se é prudente “tomar dinheiro emprestado” no banco arquitetural. Se tomarmos dinheiro emprestado, devemos investir tempo e esforço em técnicas de refatoração arquitetural para pagar o débito rapidamente.

Arquiteturas ágeis podem ser excelentes instrumentos de acomodar as pressões de mercado, mas devem ser cuidadosamente elaboradas e pensadas para que o “fluxo de caixa do seu produto” continue saudável e você não tenha graves problemas em produção.

5 Minutos com Ward Cunninghan
Para os mais interessados no assunto, recomendo este pequeno vídeo de 5 minutos do autor.

Neste mês os bancos de dados relacionais completam 40 anos. Após todo este tempo, eles possuem grande popularidade e podem ser posicionados na parte direita da curva abaixo que modela como inovações são difundidas, e que foi popularizada por Everest Rogers em 1962.

Antes que os bancos relacionais se tornassem populares, entretanto, eles passaram por diversos percalços até que fossem reconhecidos e adotados pelo mercado. Uma breve história do tempo reflete isso:

• O artigo “A Relational Model of Data for Large Shared Data Banks,” de Edgar Codd é publicado na ACM em 1970.
• O projeto IBM’s System R e projeto Ingres da Universidade da Califórina traduzem os conceitos dos bancos relacionais em produtos concretos ao longo dos anos 70. O projeto do System R, em particular, padronizou a linguagem conhecida como SQL.
• O artigo seminal “Access Path Selection in a Relational Database Management System,” de Patricia Selinger, pesquisadora do projeto R, permite grandes avanços em termos de escalabilidade através de algoritmos eficientes de uso de memória, disco e CPU.
• No fim dos anos 70 e anos 80, bancos derivados destes projetos, como o IBM DB2 e o banco de dados da Oracle estabelecem as bases técnicas e comerciais para a profusão dos bancos de dados.
• Em 2010, virtualmente toda empresa de médio e grande porte possui bancos de dados relacionais em sua TI.

Novas tecnologias como BPMS, SOA, CEP, BRMS, entre outras, talvez não demorem 40 anos para sempre amplamente utilizadas, mas certamente ainda estão do lado esquerdo da curva de Rogers. Até lá, devemos aprender com os pioneiros de bancos de dados relacionais e ajudar na popularização com casos reais e contribuições para o aumento da sua maturidade em projetos.

Para os mais curiosos sobre os 40 anos dos bancos de dados relacionais, recomendo o excelente artigo publicado mês passado na ACM com a sua história.

Pensamento do dia: “Be patient, for the world is broad and wide.”, William Shakespeare

Esta é uma tradução pessoal do SOA Manifesto Guiding Principles criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis.

Bons projetos SOA!

O Manifesto SOA

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.

Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.

Esta é uma tradução pessoal do SOA Manifesto criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis. Acredito no manifesto. Também aderi ao manifesto, ao qual me tornei signatário.

Bons projetos SOA!

Postei há algum tempo aqui uma notícai sobre o jogo Innov8 (Innovate) da IBM que mostrava de forma lúdica os conceitos de BPM em um jogo 3-D com excelente qualidade gráfica.

Agora o jogo está disponível online para qualquer usuário (basta preencher um registro e criar uma conta). Para os estudantes universitários da parceria acadâmica IBM, ele pode ser baixado para a sua máquina.

O jogo foi melhorado e agora apresenta cenários de negócios diferentes para os jogadores.

Bons jogos e bom aprendizado!

Veja o trailer aqui.
Jogue o jogo online aqui.
Baixe o jogo completo aqui.

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

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

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

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

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