Como reorganizar e compartilhar funcionalidades comuns entre as várias soluções específicas de cada área do negócio.
Projetos de software costumam contar com uma equipe com diferentes papéis, que vai desde gerente comercial à gestor de Medição e Análise.
É 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.
A proposta de solucionar de forma madura e estável problemas como integração, reusabilidade, desacoplamento e escalabilidade, é muito atraente tanto do ponto de vista técnico quanto funcional.
Porém, exige um estudo aprofundado sobre o 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), 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.
Manter em mente o negócio e não os sistemas:
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.
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 este dado só pode ser feito pelo sistema definido e 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.
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.
Concluindo, 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, 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 eles 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 normas para segregação de serviços.
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.
*Fernando Lunelli é gerente de Tecnologia da Teclógica