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

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 sexta postagem desta série, a equipe de Brenda define o novo Panorama de Aplicativos e analisa as lacunas entre os estados atual e desejado da arquitetura corporativa da BriteLite.

Definindo o panorama de aplicativos

A equipe está em pleno andamento agora, bastante conscientes do fato que “a pressão está alta”. Os modelos de referência estão, no momento, em um estado “bom o suficiente”, e alguns dos resmungos da Diretoria parecem ter desaparecido. Através de canais informais, a equipe ficou sabendo que parte da frustração parece vir do fato de que uma auditoria (“avaliação rápida”) realizada por uma consultoria externa aconselhou a Diretoria a “acelerar as coisas um ponto”. E onde fica um planejamento cuidadoso!

Trabalhando de perto com o seu patrocinador, Brenda está tentando conseguir o máximo de tempo possível para que a equipe possa fazer o trabalho real. Ela introduziu com sucesso a ideia de incluir uma análise de segurança nos modelos de solução que ela prometeu. Isto pode significar trabalho extra, mas valerá a pena se for o empurrão final para a aceitação do resultado de semanas de modelagem realizadas pela equipe.

Modelando o panorama de aplicativos

A fim de dar rápido início à modelagem do panorama de aplicativos real, Brenda desenvolveu um cartaz simples para orientar sua equipe. Seu mantra é “modele tão pouco quanto possível, mas não menos”.

Começando com os modelos de referência que foram desenvolvidos, seu objetivo é garantir que a equipe, em primeiro lugar, compreenda em alto nível quais capacidades são suportadas por quais funções/dados no panorama de sistemas, e depois fazer um mapeamento para os componentes reais. O mapeamento das capacidades será feito como um exercício no quadro branco, e não é uma entrega formal neste momento, devido a questões relacionadas com os prazos disponíveis. A equipe faz uma observação para retornar a este assunto mais tarde. Modelar o panorama inclui também claras percepções sobre a forma como os dados se moverão de um componente para o próximo. Esta será, provavelmente, a parte mais difícil de definir, dado que a equipe quer usar uma solução baseada em MDM. No entanto, todos estão confiantes de que haverá um grande valor adicionado no longo prazo, e a equipe rapidamente começa o trabalho.

Como uma palavra final de orientação, Brenda garante que todos compreendem que (a) isto tem de ser feito rapidamente, e que é a reutilização dos modelos de referência que tornará isto possível, e (b) que a próxima semana será dedicada ao desenvolvimento de um modelo detalhado que mostre como uma capacidade única é suportada pelo panorama de aplicativos desenvolvido recentemente.

A arquitetura alvo para o panorama de aplicativos

Neste ponto do processo, a equipe começa realmente a se beneficiar de todos os trabalhos preliminares. As diferentes peças do quebra-cabeças podem agora ser conectadas e transformadas em uma arquitetura alvo sólida e à prova de futuro para a organização BriteLite. Os estudos e padrões MDM, e modelos de referência de aplicativos, foram documentados de forma consistente na linguagem ArchiMate e, além disso, em um único repositório que é parte integrante da ferramenta de arquitetura corporativa da BriteLite, o Bizzdesign Enterprise Studio. Isto significa que a criação de modelos para a arquitetura alvo é “apenas” uma questão de reutilização e geração de novos diagramas com base nas informações existentes.

A visão abaixo é um exemplo que ilustra este ponto. Ela mostra como os principais aplicativos no panorama estão alinhados com base no padrão de coexistência do MDM. Os aplicativos compartilham funções e dados em torno de gerenciamento de clientes, do gerenciamento de pedidos, bem como do gerenciamento de inventários. Os dados em cada um dos sistemas de origem são consolidados e gerenciados pelo núcleo do MDM. Uma das principais funções do núcleo do MDM é manter o “registro dourado” para cada um dos objetos de dados compartilhados. A equipe utiliza uma abordagem “orientada para serviços”. Serviços de aplicativos representam a funcionalidade automatizada “útil” para os usuários (usuários humanos ou outros elementos no panorama de aplicativos) de um sistema. Traduzindo esta ideia para a arquitetura alvo de aplicativos da BriteLite, o núcleo MDM realiza um “serviço de masterização de dados”, que pode ser utilizado pelos sistemas de transação. Para tornar esta imagem ainda mais clara, e colocar um foco sobre quais dados serão masterizados pelo núcleo do MDM, três “instanciações” de um serviço de masterização de dados são modeladas, uma para cada tipo de dados.

A equipe também trabalha sobre a arquitetura alvo de tecnologia. Os membros da equipe usam os objetos da camada de tecnologia no ArchiMate para criar diagramas que fornecem percepções a partir da perspectiva da implantação da arquitetura alvo. O exemplo abaixo mostra como a tecnologia ESB está incorporada na infraestrutura para suportar a troca efetiva de dados entre os componentes, incluindo os aplicativos principais, como bem como o núcleo do MDM.

Na medida em que o desenvolvimento da arquitetura alvo progride, é tempo de começar a pensar a respeito do próximo desafio: como chegar lá a partir de onde estamos hoje? Em outras palavras, a próxima tarefa para a equipe é começar a pensar a respeito de um roteiro de implementação.

Análise de Lacunas

Com a pressão em alta, a equipe tem a sensação de que eles são “trabalhando contra o relógio”. Certamente, o modelo alvo está crescendo rápido, também porque os modelos de referência oferecem um bom ponto de partida. Mesmo assim, a equipe tem claro que a expectativa de todos é que houvesse mais resultados concretos. Isto, provavelmente, é devido ao fato de que um grande número de pessoas na organização deseja começar a realizar a arquitetura, em vez de continuamente enriquecer os modelos com mais detalhes. Aqui, Brenda percebe que ela deve estabelecer um equilíbrio entre a obtenção de uma imagem completa da arquitetura alvo em ArchiMate e dar à sua equipe o que eles querem e precisam.

Por onde começar a realização

Brenda decide falar com sua equipe primeiro, e trazê-los para bordo do seu plano: envolver a Diretoria na escolha de por onde começar a realização. Ela organiza uma reunião na “sala de guerra”, e compartilha os seus pensamentos com a equipe. Normalmente a sua abordagem seria se ater ao plano e concluir a análise de lacunas em primeiro lugar, uma vez que ela detestaria perder quaisquer dependências importantes antes de escolher uma abordagem para a realização.

Com base no que ela viu nos modelos até agora, parece que tanto o CRM como o ERP são bons lugares para começar, e até mesmo o sistema MES pode funcionar – embora seu sentimento seja ser contra esta opção.

A equipe está muito feliz por chegar mais perto de realização, e depois de alguma discussão sobre a alegação de que qualquer sistema pode ser uma opção boa o suficiente para começar, um consenso é alcançado: deixar a Diretoria decidir. Com um sorriso, Brenda sugere que a equipe continue trabalhando na arquitetura alvo, limpando as áreas do ERP e CRM em particular, enquanto ela discute a questão com a Diretoria usando o diagrama simples que ela criou usando um software de apresentação padrão.

A Diretoria está começando a se acostumar com o estilo visual de apresentação de Brenda: ela não envia relatórios enormes, mas traz um único diagrama que mantém o debate geral sob controle. Esta vez não é uma exceção. Uma vez que ela realmente não tem uma preferência em relação à por onde começar, é relativamente fácil para Brenda orientar a discussão. Seu foco principal é se certificar de que todos compreendam que a primeira iteração será a mais difícil, devido ao fato de que a complexa camada de integração terá de ser configurada. Após ela prometer que voltará com uma análise mais sólida, a Diretoria dá sua orientação para iniciar com o CRM, e retornar com um planejamento o mais rápido possível!

Análise de lacunas

Como de costume, Brenda começa preparando a equipe para o próximo passo do projeto. Desta vez, isto envolve explicar como executar a análise de lacunas através da Extensão de Implementação e Migração do ArchiMate, o que será uma novidade para a maioria da equipe. Ela prepara o seguinte diagrama:

Reunindo a equipe, ela começa com uma explicação dos novos conceitos: platô e lacuna (para mais detalhes consulte a especificação da linguagem ArchiMate). Ela ilustra esses novos conceitos usando três funções de aplicativo: uma vez que a função A está na linha de base, mas não no alvo, ela deve ser associada entre a linha de base e o alvo. Para a função C o caso é o inverso. Uma vez que a função B é parte tanto da linha de base como do alvo, ela não deve ser associada com a lacuna, simples assim. Ela também demonstra que, com a ferramenta adequada, deve ser possível criar visões de cores que mostram a diferença entre platôs.

Análise de lacunas para a BriteLite

A abordagem não é difícil de compreender intelectualmente, mas ainda assim a equipe suspeita que isso é mais difícil do que parece na prática, especialmente porque algumas funções do sistema CRM podem parecer as mesmas entre a linha de base e o alvo, mas são de fato diferentes. Questões complexas de nomes (homônimos, sinônimos) serão também um desafio. A única forma de ver o quão difícil é na prática é realmente começar!

A equipe decide adotar uma abordagem onde eles começam a modelagem pelo nível mais alto, e depois gradualmente mergulham nos detalhes. No diagrama abaixo, apenas os componentes principais do (de parte do) novo panorama de aplicativos são visualizados: o núcleo dos sistemas de transação (ERP, CRM e MES), ligados uns aos outros pela solução de MDM imaginada. Usando o conceito do platô do ArchiMate, como tão bem explicado por Brenda, o platô “Alvo” é introduzido no modelo de Arquitetura Corporativa da BriteLite. Embora também hoje existam um CRM e um ERP, todos os componentes do diagrama abaixo são atribuídos ao platô alvo. Na arquitetura alvo as funções do CRM e do ERP serão cuidadosamente escolhidas, mantendo um olhar atento sobre alguns dos importantes objetivos da presente iniciativa: não duplicar qualquer funcionalidade, bem como compartilhar dados comuns entre os aplicativos.

Depois que a equipe decidiu sobre a abordagem, eles precisaram de apenas alguns poucos passos na ferramenta para documentar e visualizar tudo isto como desejado. Vincular os objetos na arquitetura com o estado alvo é suficiente para que a ferramenta gere a figura abaixo:

Todos os objetos, bem como os relacionamentos, estão na cor verde, e a legenda explica precisamente o que isto significa: os objetos pertencem ao estado alvo, ou em outras palavras: estamos olhando para uma visão geral de alto nível do panorama alvo de aplicativos. Inicialmente, a equipe achou “engraçado” que todo o esquema seja verde, muito em linha com uma abordagem de “campo verde”. A equipe reconhece que será preciso uma análise mais detalhada para obter as verdadeiros percepções que são necessárias para fins de planejamento.

Como mencionado, o papel exato dos sistemas de transação na arquitetura alvo de aplicativos é definido pelas funções que eles fornecem, e os dados que eles criam, usam e/ou gerenciam. Para descobrir como isso muda no estado alvo, quando comparado com onde estamos hoje, a equipe precisa mergulhar nos detalhes. A equipe analisa neste nível que funções devem ou não ser transportadas para o estado alvo, e por qual sistema serão fornecidas. Além disso, novas funcionalidades estarão disponíveis para apoiar as capacidades necessárias do novo modelo operacional da BriteLite.

A equipe documenta, cuidadosamente, os resultados da sua análise de lacunas no seu ambiente de ferramenta. Eles não têm de começar a partir do zero, mas apenas adicionar esta noção de platô e roteiro ao seu repositório de modelos existente. Isto significa que eles precisam apenas de fazer a ligação entre os objetos dos modelos de linha de base e alvo com os platôs que têm os nomes similares “Linha de Base” e “Alvo”. Na sua ferramenta, eles podem fazer esta associação usando uma visão de tabela, como no exemplo mostrado abaixo:

Depois de concluir o exercício como descrito acima, o repositório contém informações suficientes para que a ferramenta realize o trabalho árduo automaticamente: criar uma visão intuitiva da transformação do panorama de aplicativos indo da linha de base até o estado alvo. O diagrama resultante é ilustrado abaixo. Novamente, uma explicação sobre as cores é dada em uma legenda (também gerada automaticamente). Em suma: verde é novo, azul sobrevive, mas o laranja não. Uma das coisas que o diagrama mostra, para o caso da BriteLite, é que as funções e dados relativos ao gerenciamento de produção não serão mais fornecidos pelo sistema ERP, mas serão transferidos para o sistema de MES.

Isto faz mais sentido: há alguns elementos que podem ser reutilizados, vários que podem ser ignorados e desligados, e um bocado que são novos. São necessárias várias iterações de validação para completar a figura, mas logo a equipe se sente confiante que ela capta a essência suficientemente bem: tendo agora uma sólida imagem da linha de base, do estado alvo, e de suas diferenças (lacunas), é indispensável buscar as percepções para a próxima fase: o planejamento do trabalho real!

Na próxima postagem, a equipe de Brenda finalmente passa para a fase de definição do roteiro para a arquitetura alvo e o planejamento de sua implantação, e criação de um portfólio de projetos de mudança, finalizando este estudo de caso.