Aquele blog de SOA

08 de August de 2011

Aplicação de Metodologia Ágil em Consultorias SOA

Na maioria das vezes, as consultorias SOA adotam processo convencionais para a entrega de resultados aos seus clientes. Neste processo, todos os artefatos que serão gerados ao longo do projeto, sejam definições tais como: guias, padrões, ferramentas, práticas e templates, ou conteúdo de um projeto piloto como: contratos de serviços, especificações de integração e arquitetura do projeto, são todos definidos no início do projeto de consultoria.

Além do fato de, nos processos convencionais, todos os artefatos serem entregues somente no final do projeto, normalmente, os guias gerados são extensos demais, ocasionando outro grande problema que é a dificuldade na absorção do conteúdo gerado.

Somando-se os dois problemas, temos um processo longo que demora no mínimo seis meses para começar a entregar resultados e, quando esses são entregues, são de difícil compreensão e acabam não agregando tanto quanto poderiam agregar.

Para tentar minimizar este problema, a adoção de práticas de metodologias ágeis, tais como o Scrum, tem sido uma alternativa na agregação de resultados para o cliente. Um grande diferencial deste tipo de metodologia é a definição de espaços menores de tempo (Sprints), que variam entre duas a quatro semanas, onde são definidas quais atividades/entregáveis devem ser realizados e, ao término deste período, os resultados são apresentados, revisados e um novo Sprint é planejado e tudo começa outra vez.

O Scrum define alguns papéis: Product Owner, Scrum Master e Time Scrum. Geralmente um projeto de consultoria SOA conta com apenas um consultor e a equipe envolvida do cliente. O consultor exerce papel de Scrum Master e Time Scrum, pois é o principal gerador de conteúdos além se preocupar com as atividades do backlog que estão com problemas (blocks). O ponto focal do cliente atua como Time Scrum pois, além de revisar os artefatos gerados, algumas atividades, principalmente durante o piloto, são endereçadas a ele, e também tem o papel de Product Owner, afinal, é ele quem prioriza o backlog. Os ritos – Sprint Planning, Spring Review e Daily Meeting – e ferramentas – ProductBacklog, SprintBacklog – são utilizados para contemplar a metodologia.

Esta abordagem, considerada uma abordagem leve, tem se mostrado muito eficiente, pois o cliente não precisa ficar esperando o término do projeto para ver os resultados. Os guias criados, como são revisados no final de cada Sprint, tendem a ser menores e mais focados no objetivo real do guia. Além disso, um dos pontos mais importantes, todos os guias e definições são validados em um projeto real, um piloto que garante que todas as definições serão aplicadas e validadas de acordo com a necessidade real da corporação.

O Scrum, na maioria das vezes, é recomendado para projetos complexos onde as mudanças devem ser gerenciadas e priorizadas constantemente. Pode até ser que esta não seja uma característica dos projetos de consultoria SOA, no entanto, em meu último projeto de consultoria, adotamos um processo de gestão ágil que trouxe grandes ganhos, pois nosso Backlog de execução se moldou de acordo com as demandas imediatas e, às vezes, inesperadas de governança SOA do cliente. Graças à utilização de Sprints curtos (duas semanas) e da flexibilização do Backlog, conseguimos atender todas as demandas do cliente.

Leia mais »

Enviado por: gibson
2 Comentários

Categorias:

Metodologias

Divulgue esse post:

Rec6

Del.icio.us Adicionar blog aos favoritos do BlogBlogs

BlogBlogs

Technorati Envie este link para linkTo!

LinkTo

15 de July de 2011

O Modelo Canônico em uma abordagem SOA

O modelo canônico é um facilitador para troca de dados entre serviços.

Assim como o ESB (Enterprise Service Bus) atua como um mediador, permitindo que web services conversem uns com os outros sem a necessidade de criar um relacionamento ponto-a-ponto específico para cada um deles, um modelo canônico permite que sejam definidos esquemas para as entidades de uma organização (ex. Cliente, Produto, Fatura, etc..), desta forma, todos serviços fazem uso desse mesmo modelo de dados canônico, reduzindo o número de transações, o custo de infraestrutura e o custo de implementação e garantindo uma maior padronização como consequência do aumento do reúso.

Definir as entidades separadamente para cada serviço implica em um contrato de serviço (WSDL) totalmente customizado para cada serviço. Isto pode significar muita redundância, também conhecido como desnormalização de esquema.

Qualquer serviço que necessite fazer troca de dados pode traduzir sua versão de dados local para versão canônica.

Considere que uma empresa adquiriu outra empresa. Ambas as empresas possuem a entidade Funcionário. No entanto, o esquema de ambas as entidades são diferentes. Utilizando o modelo de dados canônico, basta que os dois serviços mapeiem seus dados para o modelo canônico, eles não precisam mapear de um para o outro ou serem individualmente reescritos.

A transformação de dados local para o modelo canônico ocorre mais frequentemente de três formas:

O Consumidor 1 chama o Serviço A. Ambos utilizam o modelo canônico, nenhuma transformação é necessária, sendo esta implementação a ideal;
O Consumidor 2 chama o Serviço B. A transformação para o modelo canônico ocorre dentro do barramento;
O Consumidor 3 chama o Serviço C. Um adaptador transforma a mensagem do modelo local do serviço para o modelo canônico.

O modelo canônico existe para definir conceitos e agem como mediadores ideais.

O modelo canônico deve ser mantido de forma flexível e geral, dado que eles irão potencialmente absorver uma variedade de definições de entidades.

A evolução do modelo canônico implica na evolução do contrato do serviço (WSDL), já que o esquema faz parte do contrato do serviço (WSDL), sendo assim, será necessário re-gerar código do serviço.

A evolução do modelo canônico deve ocorrer através da governança SOA. Os esquemas podem ser versionados. Indicando explicitamente a versão do esquema no namespace, têm-se a liberdade para mudar apenas os serviços necessários no momento, sem a necessidade de alterar todos os serviços de uma só vez. Os demais serviços podem ser alterados ao longo do tempo, mas o ideal é que essa atualização não demore a ser feita. Ter muitas versões de esquema canônico em uso, pode levar a não se ter mais o esquema canônico. As atividades de governança para este processo devem estar bem definidas.

Abraço,
Daniel Varanda

Representação do Modelo Canônico em uma abordagem SOA

Leia mais »

Enviado por: Daniel Varanda
23 Comentários

Posts relacionados:

O lado técnico da aquisição de um ESB