Modelo Canônico – Normalização Semântica

Este é o terceiro post sobre Modelo Canônico. A leitura na ordem cronológica é indicada: Mas o que é Modelo Canônico afinal? Parte 1 e Parte 2.

Na Parte 2, foram apresentadas algumas diferenças entre os estilos de modelagem Relacional, Orientada a Objetios e Orientada a Serviços, além de alguns tópicos técnicos e de modelagem do Modelo Canônico. Agora começa a parte mais complexa da modelagem, quando as incompatibilidades técnicas e de padrão de nomenclatura foram resolvidas.

Quanto à semântica, a complexidade começa por esta incompatibilidade não ser facilmente identificada pelos responsáveis pela modelagem. Por exemplo: No sistema A existe a entidade Promoção, no sistema B a entidade Oferta e no sistema C a entidade Campanha. Cada uma tem um conjunto diferente de atributos, porém podem representar o mesmo conceito do ponto de vista do ‘Negócio’. Depois de identificada pode parecer trivial, mas durante o decorrer dos projetos isso normalmente passa desapercebido, principalmente pela ausência de stakeholders.

Vamos detalhar melhor este cenário:

• Por que o Modelo Canônico surgiu?

› Provavelmente para diminuir o número de transformações na camada SOA;

• Por que SOA surgiu na empresa?

› Provavelmente para diminuir o esforço na integração entre sistemas;

• Como SOA foi introduzido na empresa?

› Provavelmente através de um projeto piloto onde vários serviços foram construidos, bem como as primeiras Entidades Canônicas;

• Como SOA evoluiu?

› Provavelmente a partir de demandas e projetos que surgiram após a conclusão do projeto piloto;

Com este cenário em mente, vamos considerar que o projeto piloto tenha criado a Entidade Canônica Promocao, que se originou a partir de um sistema de CRM:

Aparentemente a modelagem está correta, nenhum vício de legado, padrão de nomenclatura Ok, etc.

Mais tarde, em um outro projeto da área de Marketing, surge a necessidade de mapear dados de Campanhas:

Como a modelagem anterior, esta aparenta estar correta.

Enquanto isso uma demanda no sistema de catálogo de produtos e ofertas, a entidade chamada Oferta foi modelada:

Depois de algum tempo, em um projeto de otimização e unificação de promoções, sente-se a necessidade de colocar algumas informações na entidade Campanha, como descrição e data de inicio e fim de vigência, quando um analista lembra de uma demanda que utilizava a entidade Oferta. Depois de algumas reuniões com stakeholders percebe-se que as três entidades representam o mesmo conceito do ponto de vista do negócio.

Neste caso hipotético, esta dívida técnica surgiu organicamente e, em um projeto tradicional poderia ser paga com um refactoring, porém como comentado no primeiro post, refactoring em SOA não é tão simples.

Uma forma de evitar esse problema é sempre ter stakeholders presentes, mas como isso não é a realidade na maioria dos casos, pode-se usar um modelo informacional da área de empresa como referência. O SID é um modelo informacional para empresas Telecom. No entanto o modelo informacional escolhido deve ser usado como uma referencia para definir os conceitos de negócio e nomenclaturas, não deve ser usado puramente.