Blog do Eduardo Costa Meu blog pessoal

18Ago/112

Serviços, SOA e BPM

Agora que meu amigo Flávio vai para uma empresa que trabalha com BPM, dei uma introdução sobre o assunto que acho que outras pessoas podem se beneficiar. Vamos contar uma historinha.

Tudo começou com o desenvolvimento "clássico" de aplicações. O desenvolvedor ouve o que o cliente/usuário quer e transforma isso em programas. Esse modelo funcionou muito bem até que a quantidade de código tornou-se tão grande que inviabiliza continuar com um único sistema monolítico. Surgiram os "módulos" (cadastro de funcionários, clientes, contas a receber, etc).

Com um sistema modular, fica mais fácil a expansão e manutenção de cada módulo individualmente. O time de desenvolvimento continua recebendo as requisições do cliente/usuário, mas, dessa vez, cada parte interessada só precisa afetar seu próprio módulo. Tudo maravilhoso, até que as necessidades dos módulos começam a se interseccionar. "Contas a receber" depende do cadastro de clientes, "pagamento" depende dos funcionaŕios, etc. Surge o conceito de "serviço".

Ao invés do cadastro de cliente só existir no módulo de "clientes", ele pode existir como um "serviço de clientes", e os demais módulos usam esse serviço: o módulo de "clientes" alimenta esse serviço com novos clientes, enquanto "contas a receber" usa o mesmo serviço para alimentar sua própria base de contas com dados dos clientes devedores. "Serviço", segundo a Wikipedia, é um conjunto agregado de funcionalidades somado com uma política de acesso. Repare que um serviço não precisa ser um Web Service SOAP ou REST! O importante é agregar uma funcionalidade autocontida e controlar o acesso à informação (ou seja, nada de "SELECT"s direto na base). Até um "JAR" devidamente configurado ou um Servlet serviria.

Se você consegue encapsular as funcionalidades em serviços, por que não encapsular TODAS? Tudo poderia ser serviços ("Confirmação de Cliente", "Inclusão de Conta", "Aprovação de Acesso de Funcionário", etc), bastando uma interface bem fina, só para orquestrar e receber dados do usuário. Isso podemos chamar de uma arquitetura orientada a serviços. Ou seja, SOA. Com SOA, assumindo que todo o negócio do sistema está modularizado em serviços, toda nova funcionalidade fica simples de implementar: basicamente basta fazer uma nova orquestração para os diversos serviços já existentes. Novos serviços surgem com bem menos freqüencia - basicamente, surgem com as funcionalidades mais "inovadoras" (integração com o setor financeiro, uma nova empresa comprada, etc).

Daí, com vários serviços já prontos, o trabalho principal da equipe de desenvolvimento é receber as necessidades do cliente/usuário, modelar o negócio e orquestrar em SOA. Nesse nível, normalmente, a empresa já tem uma equipe de negócio especializada. O trabalho dessa equipe, então, fica meio estranho pensando de forma "clássica": a equipe de negócios recebe a requisição do cliente/usuário e repassa aos desenvolvedores. Qual a utilidade deles? Temos pauta para muita discussão, mas esse não é o foco. Em minha opinião pessoal, quando o trabalho deles é bem feito, tem muita utilidade.

O que aconteceria se a equipe de negócio, ao invés de rabiscar no "Word", rabiscasse a orquestração em um "meta-sistema"? Se fosse possível, nesse sistema, dizer que existe um formulário que deve enviar ao serviço de cadastro de clientes, obter a resposta, enviar ao serviço de "abrir ordem de serviço", aguardar confirmação do gestor por e-mail, etc, etc? Muito mais fácil que implementar a tela que chama dois serviços, envia e-mail, etc. Com isso, seria possível modelar o processo que rege um negócio. Oras, isso é o tal BPM (Business Process Management)! Com BPM, os desenvolvedores fazem os vários serviços, enquanto a equipe de negócio orquestra tudo.

Se é tão maravilhoso, por que parece não funcionar? Simples. Quem leu o que escrevi sobre "mercado versus inovação", pode ter imaginado: ainda não houve inovadores suficientes para que o mercado possa seguir. Logo, alguns erros básicos geralmente são cometidos:

  • Programadores não entendem BPM - é triste, mas muitos programadores "clássicos" acham errado que a equipe de negócio faça a modelagem com ferramentas visuais. Acham que é mais fácil fazer uma tela em Java com toda a lógica e pronto. Eu, particularmente, acho que seria muito mais fácil fazer vários serviços SOAP ou REST e testar ao máximo com testes unitários - sem precisar de enormes armengues para testar a interface (isso quando é possivel testar). Como o serviço só contém lógica e uma política de acesso (nesse caso, a interface SOAP/REST), basta testar a lógica que o "bind" com o Jersey ou similar é o menor dos problemas;
  • Ninguém entende SOA - todo mundo acha que basta fazer tudo com webservices que você tem SOA. Falácia gravemente obtusa. SOA pressupõe serviços, e não webservices. WS só é padrão de facto em SOA pelos seus benefícios de passar firewall, usar "protocolos normais" (HTTP, XML), etc. Nada impediria que um JAR fosse um serviço, ou qualquer outra tecnologia mais obscura (CORBA, CICS, etc). O truque do SOA não é o "S", mas sim o "A". A arquitetura dos serviços é o fundamental. Se você nem sabe o que colocar no serviço, já era - desista de usar SOA por enquanto;
  • Querer começar criando novos serviços. Ou seja: fazer as novas funcionalidades em "SOA" e esquecer o legado. Mais uma falácia. Detesto esse erro clássico de tentar fazer algo reaproveitável começando do zero. Como reaproveitar se nem aproveitou ainda? Que tal olhar aquele sistema legado monstruoso e ver o que ele faz ao negócio? "Puxa, preciso fazer a funcionalidade de prospecção de clientes igual ao legado". Opa! Traduza para "preciso reaproveitar a prospecção de clientes do legado". Olha o tal "reaproveitar" aí. Transforma em um serviço! Legado usa uma outra tecnologia? Integração também é uma palavra bonita! Provavelmente você já tem um jeito de acessar o legado usando sua tecnologia nova (já vi até Java conversar com CICS!), então, faz o Java virar o tal WebService, somente traduzindo os dados e solicitando ao módulo legado. Pronto! Um serviço totalmente reusável surgiu! Mais inteligente que tentar recriar do zero, copiando o que tem no legado - e bem mais rápido de fazer, também.

Resumindo, reparem na história que contei. SOA e BPM encaixaram como uma luva por causa do legado de aplicações. Eles deram a base para transformar o sistema monolítico em módulos, depois em serviços, depois orquestrar com SOA, por fim modelar com BPM. Se tentar começar com BPM ou SOA sem ter profundos conhecimentos do negócio, nem de prática real em SOA/BPM, é evidente que algo errado vai acontecer.

21Mar/100

Utilizando o Google Notas com XP

Dentre as várias vantagens que vejo no Extreme Programming, creio que o núcleo delas seja a simplicidade. Ao contrário de muitas metodologias, você não precisa de caríssimas ferramentas para fazer seu trabalho: somente um bloco de papel, um editor, um compilador e um framework de testes são necessários.

Sem diagramas de interpretação dúbia nem documentos desatualizados que ninguém lê. Os desenvolvedores só precisam desenvolver o código, documentá-lo com comentários (incluindo JavaDoc ou similar), e, se desejável, gravar as "User Stories" (escrever é obrigatório - manter gravado, nem tanto).

Uma "User Story" é similar a um "Caso de Uso" do RUP. Não obstante, são mais simples (ou seja, menos burocráticos), e, o mais importante, são escritos pelo cliente, usando termos orientados ao negócio do cliente.

Como, infelizmente, nem sempre é possível contar com o cliente para estar sempre ao nosso lado para escrever todas as "User Stories", podemos usar saídas alternativas. Uma delas, que descobri ao acaso graças ao iGoogle, é o Google Notas.

Trata-se de um editor de notas incrivelmente simples e eficaz. Ele edita pequenas notas, contraindo-as para a primeira linha para economizar espaço visual, agrupando-as em blocos e seções.

Como eu precisava de um meio não-físico para escrever algumas stories, decidi escrevê-las no Google Notas. Serviu como uma luva: criei um bloco para o projeto, escrevi cada story em uma nota e, depois, agrupei-as conforme cada iteração ia surgindo. Ativando o compartilhamento, todos os interessados teriam acesso.

Ou seja, o cliente pode entrar no Google Notas em qualquer lugar com acesso à Internet, escrever as stories, priorizar e disponibilizar à equipe de desenvolvimento. Liberando o cliente para participar de uma reunião somente para tirar eventuais dúvidas na hora de redigir as tarefas e escolher a próxima iteração.

12Jan/100

Como não fazer: Documentação "Gênesis"

"No princípio, Deus criou os céus e a terra" (Gênesis 1:1)

Já passou alguma vez por uma documentação que, ao invés de descrever o que o sistema faz, conta a história deste? Algo similar a "No princípio, Fulano criou o sistema para fazer isso" - praticamente uma versão em texto corrido daquela tabela de "histórico de alterações" (cuja origem desconheço).

Implementar um sistema baseando-se nesse tipo de documentação é como fazer manualmente um "merge", revisão por revisão, de um arquivo no sistema de controle de versão.

Se o sistema originalmente considerava multa de 20% e, por definição do chefe do setor, passou a considerar multa de 10%, por que precisa documentar isso no modelo de análise? Só para ter o gosto de ouvir o programador perguntar: "devo sempre considerar 10% ou tem algum caso que ainda vale 20%"?

Muito mais claro, resumido e conciso seria documentar que o sistema "deve considerar multa de 10%". Se a intenção é documentar a história, existem locais melhores para isso, como a tabela de histórico da capa, o histórico no sistema de versionamento ou uma ata de reunião.

22Set/080

Programação Orientada a Gambiarra

Depois das famigeradas coletâneas de patterns do Gang of Four, enterprise patterns, refactoring to patterns e cia, finalmente lançaram a coletânea mais importante para nós, desenvolvedores:

GAMBI DESIGN PATTERNS: todas as gambiarras mais conhecidas, devidamente catalogadas. Finalmente, estamos amparados!!!!