Projetos de software costumam contar com uma equipe com diferentes papéis, como os exemplos listados a seguir:

• Gerente Comercial;
• Gerente de Projetos;
• Analista de Negócios;
• Analista de Sistemas;
• Arquiteto de Software;
• Desenvolvedor de Sistemas;
• Analista de Testes;
• Gestor de Configuração;
• Analista de Qualidade;
• Gestor de Medição e Análise;
• Entre vários outros que poderiam ser citados aqui.

É fato que qualquer um destes papéis, mesmo não tendo responsabilidade direta sobre o assunto, já teve algum contato com o conceito de SOA (Service Oriented Architecture). Esta arquitetura tem sido aprovada, vislumbrada e referenciada sempre que uma solução é projetada, seja ela nova ou esteja em evolução.

Qual a proposta?

A proposta de solucionar de forma madura e estável problemas como integração, reusabilidade, desacoplamento e escalabilidade entre vários outros, é muito atraente tanto do ponto de vista técnico quanto funcional, porém exige um estudo aprofundado sobre sua arquitetura, e principalmente do ambiente em que a mesma será implementada, uma vez que ao final, deve-se entregar uma composição de serviços que nada mais serão do que funcionalidades já existentes, porém reorganizadas de maneira a respeitar os padrões da arquitetura (SOA) implementada, compartilhando funcionalidades comuns entre as várias soluções específicas de cada área do negócio.

Durante a implementação desta arquitetura, que é orientada a serviços, deve-se justamente despender um tempo considerável na identificação destes serviços, a fim de alcançar o benefício efetivo proposto por SOA.

Dentre as várias técnicas e teorias de identificação de serviços, gostaria de expor um pequeno conjunto de boas práticas, ou ainda considerações a se fazer durante a execução desta atividade. Estas sugestões foram compiladas a partir dos trabalhos realizados em diferentes clientes e necessidades variadas.

Princípio da simplicidade

Da mesma forma que em definições de soluções quaisquer, sempre que algo torna-se complexo, a probabilidade de estarmos seguindo um caminho incorreto é alta. Na identificação de serviços em SOA esta filosofia também é válida, ou seja, não existem regras de identificação infalíveis ou ainda que atendam a todos os casos, logo é muito interessante partir de uma visão simplificada, e trabalhar com o fato de que as regras de identificação serão modificadas conforme a evolução e amadurecimento dos trabalhos.

Uma forma prática de começar, é respondendo a questões como:

• Quais soluções de negócio já estão integradas hoje?
• O projeto está disposto a modificar parte das soluções envolvidas, a fim de adequar-se à SOA, ou as implementações deverão ser sempre externas à solução, trabalhando em conjunto para integrar-se à plataforma definida?
• Existirão integrações externas ao negócio (internet por exemplo)?
• Existe documentação de Requisitos Funcionais de cada produto envolvido? Isto é muito importante para a etapa de definição de responsabilidades.
• Já existe algum mapeamento entre as unidades de negócio?
• Como organizaremos os serviços identificados? Existem padrões para documentação e registro de serviços, sendo que o registro dos mesmos depende da ferramenta escolhida como barramento. É importante começar organizado para evitar revisões excessivas posteriormente.

Manter em mente o negócio

Identificação de serviços depende diretamente da análise da representação do negócio em forma de sistema. Sendo assim é muito mais importante ter bons conhecimentos sobre o modelo de dados de cada solução envolvida na integração, do que conhecimentos de implementação técnica da solução em questão. Por este motivo, esta etapa deve ser realizada sempre em conjunto com alguém que detenha o conhecimento dos requisitos funcionais e do modelo de dados da solução, uma vez que é neste contexto que estarão as informações mais úteis para definir quantos, quais, onde estão ou onde ficarão os serviços identificados. Torna-se então um tanto quanto óbvio mas não pode-se deixar de comentar, que uma modelagem de negócio (BPM) aplica-se perfeitamente como material de referência para a identificação de serviços.

Para entender melhor esta associação entre serviços e requisitos funcionais, pode-se trabalhar como se os sistemas fossem pessoas, e os serviços fossem tarefas realizadas por estas pessoas, onde cada pessoa deve ter responsabilidade sobre um determinado conjunto de informações, e por consequência realizar tarefas solicitadas por outras pessoas, mantendo as informações que são de sua responsabilidade.

Imitar os conceitos de DDD (Domain Driven Design)

Aproveitando o gancho de associação entre negócio, pessoas e responsabilidades sobre as informações, sugiro fortemente o reaproveitamento dos conceitos definidos pelos projetos orientados a domínio.

Estes conceitos definem que um sistema deve ser construído definindo o domínio das informações que são de sua responsabilidade, e isolando completamente o acesso a estas informações. Desta forma, todo e qualquer acesso a esta informação só pode ser feito pelo sistema definido, logo nenhuma informação é obtida, alterada ou excluída sem que seja através de funções disponíveis no sistema que domina o conhecimento de como manter tal informação. A principal característica de projetos que seguem estes conceitos é que, mesmo módulos dentro de um mesmo sistema devem implementar esta divisão de responsabilidade por domínio de informação. A imagem a seguir demonstra de maneira simples esta separação de responsabilidade por domínio de informação.

Observando a imagem acima pode-se facilmente identificar a existência de um candidato a serviço, que neste caso é o serviço que mantém informações de cliente. A utilização de conceitos como DDD não é muito comum ou implementada de maneira completa, logo são poucos os sistemas que oferecem a identificação de serviços tão simples e direta, porém podemos levar o aprendizado dos conceitos de DDD para observar os sistemas existentes em nossos ambientes, a fim de separar qual o domínio de dados que cada um compreende e mantém, e a partir daí atribuir responsabilidades e começar a identificar nossos serviços.

Atribuição de responsabilidades

Na minha visão, a tarefa mais importante no processo de identificação de serviços é a atribuição de responsabilidades para cada um dos sistemas envolvidos. Isto é devido ao fato de que, a partir do momento em que identifica-se que um sistema é responsável por determinada informação, torna-se clara a necessidade de serviços que devem ser oferecidos para outros sistemas que façam uso desta informação. Ainda dentro da etapa de atribuição de responsabilidades, pode-se fazer a separação entre informações que são utilizadas somente para complemento do modelo interno do sistema, e informações que devem ser compartilhadas entre os demais modelos pertencentes a outros domínios.

De maneira resumida, um fluxo simplificado para identificação de serviços poderia ser:

Conclusão

Serviços podem ser identificados de maneira simplificada, uma vez que as informações necessárias para sua identificação já existem e devem apenas ser analisadas. Indiferente da estratégia adotada (seguindo a teoria, definindo uma customizada ou ainda aprendendo em tempo de vôo), este trabalho deve ser levado a sério pois ele é responsável por fazer o uso correto da estrutura de integração via serviços, ou seja, não faz nenhum sentido ter um barramento de serviços ótimo em termos técnicos, porém utilizado de maneira incorreta, com serviços mal definidos ou mal utilizados.

A identificação de serviços sempre deve ser feita por uma equipe e não por uma pessoa específica, uma vez que exige conhecimentos variados (técnicos, analíticos e de negócio). Os serviços identificados sofrem evolução contínua, conforme o amadurecimento das soluções que compõe os mesmos, e o crescimento do negócio que os mesmos representam. Mesmo baseando-se em uma lista de passos, é necessário o estudo de cada situação a fim de descobrir necessidades específicas que venham a exigir uma estratégia diferenciada.

É importante lembrar ainda que esta é apenas uma sugestão para iniciar os trabalhos de identificação de serviços e implementação de uma arquitetura orientada a serviços. Se entrarmos em detalhes, descobriremos que existem regras ou normas para segregação de serviços, ou ainda para definição de contratos disponíveis em cada serviço. Vale salientar que os resultados obtidos, tal como qualidade e reaproveitamento da unidade de serviço entre outras aplicações, tornando as unidades de negócio (serviços) interoperáveis e mais flexível, adaptando de forma mais ágil as mudanças de negócio.

Inicie com um projeto que ofereça menos risco, realize todo estudo da unidade de negócio e a implemente. Ao final, tire as lições aprendidas e aumente a complexidade na implementação do conceito.

SOA – Service Oriented Architecture

Contribuição:

Andre Meirelles de Rezende

Arquiteto de Software da Teclógica