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

Figure 039A 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.

Figure 040

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.

 Figure 041

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

Figure 042Com 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:

Figure 043

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:

Figure 044

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:

Figure 045

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.

Figure 046

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.