Modelagem ArchiMate na Prática – BriteLite (Parte 5)

Publicado originalmente por Bas van Gils & Sven van Dijk. Tradução e publicação autorizada pelos autores.
Uma versão para impressão pode ser acessada na biblioteca da Centus Consultoria.

Na quinta postagem desta série, a equipe de Brenda detalha a arquitetura do MDM (Master Data Management), uma peça central na estratégia de mudança da BriteLite.

Detalhando o MDM

A equipe está empolgada com a notícia de que eles podem ir em frente com o detalhamento da arquitetura alvo. Eles estão particularmente entusiasmados com a decisão por uma combinação entre os sistemas “melhores-da-categoria” com uma solução de MDM. Há ainda alguns cuidados, já que Brenda deixou muito claro que houve alguns “perdidos nas nuvens” durante a apresentação. Como antes, a equipe decide a trabalhar em dois subgrupos: uma equipe fará um “road show” para ilustrar o conceito de MDM, visando aumentar a adesão das gerências, enquanto que a outra equipe detalhará os aspectos técnicos.

Explicando o MDM

Percebendo que eles miravam uma audiência mista, a equipe cria um cartaz, em vez de uma apresentação em PowerPoint, e garante que ele mostre apenas o suficiente para gerar um bom debate, sem adicionar muitos detalhes técnicos:

Eles agendam reuniões com todos os executivos e funcionários relevantes, através de sessões durante o almoço com duração de 45 minutos. Os resultados são, de certa forma, surpreendentes. A equipe começa com uma explicação dos desafios: e se você quiser ter uma visão 360° do seu cliente? E se você quer consolidar os dados e criar uma visão única de seus produtos e serviços através de toda a empresa? Uma abordagem em silos não funciona tão bem. Isto encontra algum ceticismo inicial (“apenas jogue os dados em um único repositório!”), mas o exemplo à direita torna claro que isto pode não ser tão simples quanto parece. Sem entrar em pormenores, a equipe explica que existem várias alternativas de solução, e que todas cabem sob o “guarda-chuva do MDM”. A arquitetura alvo mostrará qual das opções é mais relevante para a arquitetura da BriteLite, dada sua abordagem de “melhores-da-categoria”/núcleo de dados.

O resultado desta exposição é que o ceticismo lentamente se esvai. Pode não ser um comprometimento real ainda, mas pelo menos não há nenhuma resistência. A equipe de desenho terá de fazer um bom trabalho para mostrar as alternativas de solução.

Quais são as opções?

A equipe de desenho se reúne na segunda-feira pela manhã, e depois do café, biscoitos, e de discutir os mais recentes resultados desportivos, eles se reúnem em frente do quadro branco e discutem os seguintes pressupostos:

• Vamos selecionar vários sistemas que são os melhores em suas categorias, para CRM, ERP, MES, etc.
• Uma lista completa de funcionalidades será decidida mais tarde. Os detalhes não são tão importantes, mas o mecanismo de integração é
• Nós podemos selecionar um único fornecedor com uma suite, mas também poderíamos ir para sistemas separados de diferentes fornecedores

Inicialmente, há um pouco de debate sobre o problema do fornecedor, até que um membro da equipe sugere que esta não é uma decisão que eles podem tomar a curto prazo, uma vez que tudo depende de uma análise mais aprofundada dos requisitos e das ofertas. Em outras palavras, a equipe vai ter de trabalhar em dois cenários, como ilustrado pelo esboço no quadro branco. Um curso de ação mais definido será decidido com base nas discussões. A equipe espera que esta seja uma ‘venda difícil’, uma vez que soluções MDM requerem um bom investimento inicial, que deve ser feito antes dos benefícios serem aproveitados.

É decidido que Brenda terá de abrir este debate com a Diretoria e a equipe que está trabalhando nas três estratégias. Neste meio tempo, a equipe começará a trabalhar no padrão de co-existência com um foco em sistemas, integração/dados, e as capacidades relevantes.

MDM – o padrão de coexistência

A equipe começa pela exploração do padrão de coexistência em mais detalhes. Nesse padrão, todos os sistemas de origem mantêm os seus próprios dados, baseados nos modelos de dados específicos de cada sistema. Todos os sistemas de origem são conectados ao núcleo MDM, que recebe cada atualização no sistema de origem para qualquer das entidades de dados que são gerenciadas pelo núcleo MDM. O núcleo MDM se certifica de que essas atualizações são também enviadas para outros sistemas no panorama, incluindo outros sistemas de origem, sistemas subsequentes, bem como sistemas de análise. O núcleo MDM usa funções dedicadas a fim de definir e manter “registros dourados” para uma gama de entidades de dados. A equipe criou o seguinte diagrama descrevendo a estratégia de coexistência do MDM, o que fornece à equipe excelente orientação para criar a arquitetura alvo específica para a BriteLite.

O diagrama utiliza conceitos usuais do ArchiMate para modelar coisas como componentes de aplicativo e relacionamentos de fluxo. Usando a especialização dos conceitos ArchiMate, os diferentes papéis dos objetos MDM no diagrama podem ser visualizados. Neste caso, os objetos especializados são identificados com um ícone: o componente de aplicativo com o ícone “coroa” é um sistema MDM. As funções de aplicativo modeladas como parte do núcleo MDM incluem funções de armazenamento de dados (ícone de banco de dados), e funções de processamento (o ícone de engrenagem dupla).

A equipe começa, então, a construir sobre esse padrão, e cria um primeiro rascunho do panorama de aplicativos alvo para as capacidades padrão, visualizado abaixo. Os sistemas de transação de CRM, ERP e MES devem fornecer funcionalidades de acordo com as necessidades da BriteLite. No entanto, como concluído anteriormente, uma análise de requisitos completa das funcionalidades dos aplicativos ainda está para ser feita. Neste ponto, apenas a funções de armazenamento de dados são identificadas como parte dos sistemas de transação, outras funcionalidades serão adicionadas ao modelo futuramente. Por enquanto, o diagrama se concentra nos aspectos da arquitetura de integração baseada no padrão de coexistência.

Embora a visão seja muito “alto nível”, a equipe está feliz por ser capaz de visualizar a razão pela qual a solução de MDM é importante para a BriteLite. Este diagrama deve ajudar nas discussões sobre a qualidade dos dados, sendo capaz de fornecer relatórios de gerenciamento/operacionais rapidamente, e garantir que os vários sistemas têm acesso aos mesmos dados.

A equipe começa, ainda, a pensar sobre a perspectiva de implantação da arquitetura alvo. O diagrama acima identifica os aplicativos e mostra que os dados são trocados entre os componentes. Usando os conceitos da camada de tecnologia da linguagem ArchiMate, a equipe modela uma visão geral inicial do panorama de tecnologia alvo. Isto identifica tecnologias como ESB e ETL, que fornecem funcionalidades para apoiar o intercâmbio de informações entre objetos no panorama da TI.

O diagrama serve como ponto de partida. Numa fase posterior, mais detalhes devem ser adicionados, incluindo as plataformas de banco de dados e as tecnologias de implantação de aplicativos que apoiam o panorama de aplicativos. Por enquanto, os marcadores já foram adicionados

Os modelos de referência

Detalhar o padrão de coexistência foi um trabalho árduo para a equipe: Brenda teve que orientá-los através do projeto, ficando longe de detalhes técnicos, tais como implantação, até o conceito ser claramente entendido e a aprovação definitiva da Diretoria ser obtida.

Mesmo durante o exercício de modelagem, a equipe concorda que a única maneira de mostrar o poder do MDM para a Diretoria seria trabalhar através de um caso de uso completo. Para isso, eles desejam adicionar pelo menos alguns detalhes do sistema de CRM, do sistema de ERP e do sistema de MES, e usar a técnica de roteirização para mostrar como a integração irá trabalhar. A equipe apresenta a ideia para Brenda, que fica agradavelmente surpreendida com a iniciativa. A única orientação que ela lhes dá é a utilização de modelos de referência sempre que possível, para descobrir as principais funções de cada um dos sistemas.

Selecionando modelos de referência

A equipe tem uma boa reunião para dividir o trabalho. Eles descobrem rapidamente que modelos de referência podem ser encontrados em dois níveis:

• Modelos de referência relativos à indústria de manufatura
• Modelos de referência de fornecedores

Depois de um rápido debate, e algumas pesquisas na web, eles descobrem que uma comparação lado a lado de vários modelos de fornecedor resultará em um modelo de referência “bom o suficiente” para ser usado como base para a arquitetura. Ainda mais, decidem captar apenas as principais funções, bem como os principais objetos de dados, não se preocupando muito com a infraestrutura, implantação e outros detalhes.

Depois de documentar esta decisão de projeto, e obter a aprovação de Brenda, a equipe começa a trabalhar. Enquanto isto, Brenda retorna à Diretoria e – surpreendentemente – tem que lidar com algum calor!

Impaciência

Durante a sua sessão de atualização semanal, Brenda toma conhecimento que “a Diretoria está satisfeita com a abordagem geral, mas que os resultados são ‘demasiado lentos’. Mudanças estão sendo feitas, os modelos de linha de base ajudam, mas a ‘visão maior’ está atrasada e é necessária com urgência”. Isto chega com alguma surpresa, dado as conversas e as atualizações regulares ao longo dos últimos meses.

Parece haver pouco espaço para descobrir o que causou isto – embora Brenda suspeite que tem muito a ver com uma próxima reunião dos acionistas, de forma que tudo o que ela pode fazer é prometer mais velocidade. Feliz que a sua equipe tenha apresentado suas ideias mais cedo naquele dia, ela sugere que a parte da TI (mas sem a infraestrutura – isto dependerá do fornecedor) seja apresentada na próxima semana. Uma ilustração de como as capacidades de negócio são suportados pelo panorama de TI será ilustrado na semana seguinte. E então a equipe trabalhará em um roteiro grosseiro para a implementação.

A Diretoria concorda a contragosto. Quando Brenda partilha a notícia com sua equipe, ela garante que todos compreendam o que está em jogo!

Desenvolvendo o modelo de referência

A equipe selecionou os seguintes componentes para desenvolver um modelo de referência:

• O sistema de CRM, que manterá todos os dados afetos a relacionamentos, incluindo clientes, fornecedores, parceiros, etc.
• O sistema de ERP, que manterá tudo o que for relacionado ao planejamento, gerenciamento de inventário, etc.
• O sistema de MES, que apoiará a fabricação real.

Como uma palavra de advertência, Brenda indica que eles não devem se preocupar muito com a sincronização entre países … ainda.

Como primeiro passo, os membros da equipe tentam encontrar tanta orientação sobre o uso de modelos de referência quanto eles possam encontrar. Após algumas pesquisas na internet, eles encontram um artigo no site de blog da Bizzdesign. Eles, então, decidem documentar os modelos de referência na sua ferramenta de EA Bizzdesign Enterprise Studio, consolidando as informações encontradas no material de referência da indústria e dos fornecedores. Deste modo, eles constroem um modelo para cada um dos aplicativos básicos a serem adotados pela BriteLite: CRM, ERP e MES.

Isto está longe de ser fácil, como a equipe descobre rapidamente. Parece que cada fornecedor tem o seu próprio modelo de “referência”, e sua integração é uma tarefa complexa. Isso é lamentável, uma vez que um modelo de referência de fornecedor neutro poderia ser valioso na fase atual do projeto. Por hora, a equipe decide tentar integrar modelos a partir de várias fontes. Cada um dos aplicativos é dividido em funções de aplicação principais, que apoiarão as capacidades de negócio da BriteLite. Outra parte que é adicionada aos modelos pela equipe é a visualização das principais entidades de dados que são parte do modelo de dados, ligadas às arquiteturas de referência dos aplicativos. O exemplo abaixo mostra um resultado inicial, onde os aplicativos são modelados usando Componentes de Aplicativo, com as Funções de Aplicativo atribuídas aninhadas neles, bem como as entidades de dados modeladas como Objetos de Dados:

Enquanto os três principais aplicativos no panorama de referência de aplicativos oferecem suporte para distintas capacidades da BriteLite, as arquiteturas de referência mostram que existem funções que estão disponíveis em múltiplos sistemas. Um aspecto importante na decisão sobre a arquitetura alvo real para a BriteLite é a tomada de decisão sobre que funções serão requeridas de cada um dos aplicativos principais, ao mesmo tempo em que é assegurado que na arquitetura geral todas as funções necessárias para oferecer suporte às capacidades de negócio da BriteLite estarão disponíveis e alinhadas. O outro aspecto é identificar qual informação é gerenciada em qual aplicativo, e como ela deve ser trocada com os demais aplicativos. Para a troca de informações real a equipe utilizará os padrões do MDM, como discutido anteriormente.

A equipe analisa os modelos de referência dos principais aplicativos, e usa cores para identificar e visualizar funções, e entidades de dados, únicas e sobrepostas. O exemplo abaixo mostra um dos resultados desta análise:

O diagrama mostra que algumas das funcionalidades e dados geralmente disponíveis nos sistemas principais se sobrepõem com funcionalidades e dados nos demais sistemas. As cores mostram essas duplicações, como explicado na legenda. Este diagrama dá à equipe a percepção de que é fundamental definir um foco principal para cada um dos sistemas no panorama alvo. Ele ajuda a equipe a definir os requisitos que suportarão o processo de seleção dos sistemas. Os objetos de dados sobrepostos nos sistemas sublinham o valor adicionado da solução MDM. A equipe está confiante de que o trabalho com os modelos de referência trouxe uma base sólida que ajudará no detalhamento da arquitetura alvo.

Na próxima postagem, a equipe de Brenda define o novo Panorama de Aplicativos e analisa as lacunas entre os estados atual e desejado da aruitetura corporativa da BriteLite.