SOA - Arquitetura Orientada a Serviços

Me espanto com a complicação que vejo no mercado quando o assunto é SOA. Também me espanta o desinteresse que vejo muitos desenvolvedores tratarem o assunto. Me espanta mais ainda a confusão que essa complicação e desinteresse juntos estão causando.

Costumo dizer que a maior contribuição que SOA trás para TI é a unificação do vocabulário em torno de uma palavra: serviço. Essa palavra permite que todos os interlocutores, desde o usuário, passando pelos analistas, desenvolvedores, gerentes de projeto até a área de operações/produção falem a mesma língua. Ao saber que num determinado servidor roda um serviço crítico para o negócio, a área de operações pode calcular o resultado de uma melhora no desempenho dessa máquina. A área de desenvolvimento pode mapear quais serviços suportam os processos de negócio e focar seus esforços no desenvolvimento dos serviços mais importantes.

Técnicamente, SOA não muda a maneira de desenvolver software. Mas do ponto de vista estratégico, permite que pela primeira vez se use um termo simples e que tem significado para quem depende do software. E isso unifica esforços e garante que todos os membros de toda a cadeia produtiva do software falem a mesma língua. SOA permite preencher o "gap" que existe entre o software (componentes) e o negócio (processos). É isso!

Aqui vocês podem ver uma palestra que ministrei na abertura de um curso de pós graduação em Engenharia de Software com UML.

Sobre modelagem de software utilizando SOA com UML, recomendo um estudo da técnica SOMA, e também do profile para serviços de software, desenvolvidos pela IBM.

Depois para descontrair, recomendo uma visita ao site www.soafacts.com. É hilário.

Grande abraço!

Exorcisando o RUP II - Executáveis e Iterações

As vezes, quando conhecemos algo, esquecemos de repetir as coisas básicas sobre ele porque são óbvias para nós. Mas nessa semana realizei algo que me deixou embasbacado: tem gente que ainda acha que as Iterações à lá RUP não terminam em software funcionando.

Vou ser direto (acho esse o grande defeito do RUP, tem muita coisa lá): segundo o RUP, o objetivo de TODA iteração é obter um release TESTÁVEL do software em desenvolvimento .

Agora vamos aos detalhes:
1. Esse release pode ser interno: a equipe vai realizar testes com ou sem a presença do usuário, ou
2. Externo: o software será efetivamente implantado "em produção" para o usuário começar a usar.
3. Existe uma única exceção para essa regra: as iterações da fase de Concepção podem não resultar em executável testável.

A razão para os itens 1 e 2 é que o RUP é um processo centrado em arquitetura e a arquitetura deve ser VALIDADA o mais cedo possível. Perguntas como: "o software vai suportar as X mil transações por segundo?" ou "nossa idéia vai acomodar a inclusão de novos produtos financeiros ao longo do projeto sem necessidade de 'grandes reformas'?", devem ser respondidas logo no início do projeto (fase de Elaboração). E quando digo que a arquitetura deve ser validada, isso significa software FUNCIONANDO e sendo trucidado por testes de carga e desempenho. Arquitetura não é desenho. Não é modelo. Não é framework. É software! Mas é a parte do software que garante o atendimento dos requisitos não funcionais e portanto não tem valor para o usuário. Por isso não é entregue, mas pode ser mostrado, para que o Stakeholder valide se o tempo de resposta está adequado, por exemplo.

Ao ler o Item 3, os "agileiros" de plantão devem ter pensado "A-ha! Sabia que o RUP não obrigava a produção de um software testável a cada iteração!". Lembrem-se, eu disse (e repito) que a regra é software funcionando ao final de cada Iteração. Porém, o RUP suporta o desenvolvimento do software desde antes da decisão de construi-lo. Imagine uma empresa que está examinando seus processos e decidindo quais devem/podem ser automatizados (por software): neste momento, coisas como ROI (Retorno Sobre Investimento) e Time-to-Market (a janela de tempo até que a primeira versão do software esteja funcionando e comece a dar retorno) devem ser avaliadas para decidir se vale a pena construido. Acontece que a maioria dos projetos começam depois dessa decisão (esse estudo já foi feito) e os requisitos já vão começar a ser definidos. Pois bem, neste caso não tem exceção: a iteração só termina com software funcionando sendo testado ao final de cada iteração.

Muita gente me pergunta: mas e se não terminar assim? A resposta é simples: então a iteração não terminou. "Ah! Mas segundo o cronograma, terminou." Neste caso você só está se enganando, porque a Iteração só termina com software funcionando sendo testado.

E é batendo o resultado dos testes contra os requisitos que o gerente do projeto vai aferir progresso e qualidade. Não olhando a pilha de documentos crescer. Nem olhando a percentagem da tarefa no Gantt Chart. Esse é um bom tópico para outro post.

É isso. Espero que não demore tanto pra falar mais (caso estejam gostando, comentem pois isso é um baita estimulo!)

Forte abraço!