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

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 quarta postagem desta série, a equipe de Brenda acelera novamente em direção à arquitetura alvo da iniciativa de mudança de negócios da BriteLite, e o futuro estado da arquitetura começa a tomar forma.

Acelerando novamente

Antes e durante o fim-de-semana, Brenda trabalhou arduamente para preparar uma análise para a Diretoria. Hoje cedo, Brenda apresentou as suas conclusões para a Diretoria, que ficaram mais do que satisfeitos com os resultados. Durante a reunião eles decidiram seguir as recomendações da equipe de Brenda, e encarregaram James das ações apropriadas.

Infelizmente, o sucesso tem um preço. A Diretoria tentou jogar mais trabalho para Brenda durante a reunião. Sabendo que uma falta de foco no desenvolvimento das arquiteturas de linha de base e de destino iria colocá-la em apuros, ela resistiu e declarou claramente que esta era uma péssima ideia, que iria comprometer a importante iniciativa de construir esses modelos. Ela terminou a sua breve intervenção com uma pergunta retórica: estamos nisso para o longo prazo, ou a equipe deverá voltar a apagar pequenos incêndios?

Após um acalorado debate, a Diretoria concordou que colocar mais trabalho nas mãos de Brenda, neste momento, poderia não ser afinal a melhor solução, de forma que outros arranjos serão feitos. Reconhecendo o poder de comando, Brenda indicou que a sua equipe iria, naturalmente, ajudar tanto quando possível.

Evidentemente, Brenda compartilhou estas discussões com sua equipe durante o almoço conjunto. Todos sentiram que o único caminho seria para cima, de modo que pressionar com o trabalho será a melhor saída.

A equipe “linha de base”

A equipe da linha de base informa que todos os modelos individuais foram criados e orgulhosamente mostra uma pilha de papéis. Eles estão no processo de:

• Criação da documentação adicional para descrever os diversos elementos dos modelos
• Construção de um relatório HTML que possa ser publicado na Intranet
• Construção de um grande cartaz que possa ser colocado na parede, mostrando todos os sistemas e as relações entre eles

A equipe utiliza a funcionalidade que está disponível no Bizzdesign Enterprise Studio. Ele permite não só criar modelos e diagramas, mas também adicionar dados relevantes como atributos dos componentes que fazem parte da Arquitetura Corporativa da BriteLite. Esses dados podem ser utilizados para apresentação, por exemplo, em uma tabela, como mostrado abaixo:

Vários tipos de dados podem ser usados, incluindo texto e datas, como na tabela acima, mas também dados quantitativos tais como montantes de dinheiro. O Bizzdesign Enterprise Studio também suporta a execução de análises detalhadas sobre o modelo, e a inclusão dados de atributos nas consultas. Os resultados das análises podem ser apresentados em vários formatos, incluindo diagramas e tabelas, mas também gráficos e quadros. A equipe da linha de base utiliza informações disponíveis sobre os custos de execução dos aplicativos atuais, e adiciona isto ao repositório de modelos. Usando isto eles podem gerar facilmente os seguintes gráficos:

Três aplicativos principais têm custos anuais de execução maior que 100k, como mostrado no gráfico de pizza à esquerda. Os custos de execução das aplicações restantes são mostrados no gráfico de barras à direita.

A equipe “alvo”

A equipe que está trabalhando na arquitetura alvo solicitou um espaço de trabalho na Intranet para configurar o repositório de arquitetura. A figura à direita mostra as várias seções para os diferentes tipos de conteúdo da arquitetura.

Tendo em conta todo o trabalho que tem sido feito até agora, várias seções já foram preenchidas com conteúdo relevante: o modelo operacional já foi documentado, uma versão (antiga) do canvas de modelo de negócios desenvolvido em uma sessão estratégica foi desenterrado, e assim por diante. A equipe de linha de base foi convidada para colocar os seus modelos e relatórios na seção apropriada, para que um repositório consistente possa ser construído um passo de cada vez.

Em termos de conteúdo, a equipe alvo tem feito alguns progressos no que diz respeito à arquitetura de produtos e serviços, o que foi adicionado ao novo repositório. Para cada uma das categorias de produtos, um “contenedor” foi criado. Cada um desses contenedores enumera os principais produtos. Para obter os detalhes, basta “mergulhar” através do produto, o que irá conduzir a uma apresentação ou documento que lista os serviços subjacentes e fornece mais explicações.

Os mapas de capacidades também estão em um estado que permite que eles sejam publicados. Os três níveis superiores das capacidades de negócio foram documentados e aprovados, mas um dos membros da equipe ainda está ocupado criando a documentação pormenorizada que é necessária para poder utilizar o mapa. A equipe decide reter a apresentação estratificada, e mostrar apenas o mapa de capacidades de nível superior.

A equipe está feliz por ter o “conteúdo” inicial das duas camadas superiores do framework, como apresentado por Brenda, e parece pronto para continuar com as camadas mais técnicas subsequentes. A equipe gerencia todo o seu conteúdo de arquitetura através da sua ferramenta de arquitetura corporativa Bizzdesign Enterprise Studio, onde eles podem mergulhar nos vários diagramas a partir de sua página inicial, como mostrado na captura de tela abaixo.

Estratégias

Neste meio tempo, a Diretoria manteve a pressão também sobre os seus assessores. Eles têm sido solicitados para enriquecer a direção estratégica, mas ainda estão lutando com os detalhes. Brenda tem um breve encontro com eles e retorna com as seguintes notas:

• Para fabricação:
  • Os equipamentos de produção vêm com seu próprio software
  • Qualquer software de planejamento e fabricação que precise ser colocado sobre eles terá de ser adquirido
• Capacidades padrão (como CRM e ERP) são suportadas por sistemas de prateleira padrão (COTS).
  • Melhor do mercado
  • Construí-los somente se as divergências com a arquitetura alvo puderem causar grandes problemas no futuro
• Outros sistemas devem ser construídos em casa
  • Preferência por ferramentas de código aberto
  • Procurar parceiros de implementação para capacidade adicional, quando necessário
• Fazer as coisas importantes primeiro
  • Os sistemas de produção estão (quase) no lugar, então não começar aqui
  • Trabalhar para suportar primeiro as capacidades padrão

De volta à sua “sala de guerra”, a equipe discute o resultado desta sessão. Esta é a primeira vez que há orientação explícita e atenção da Diretoria para este assunto, de forma que a equipe fica inicialmente muito feliz. Uma rápida análise revela, porém, que adotar os melhores sistemas do mercado significa comprar sistemas que podem não seguir bastante a estrutura da arquitetura. Afinal, a equipe quis separar os “dados” da “lógica”, o que pode não ser possível nesta configuração. Algo para se pensar ao longo das próximas sessões.

Debate

A equipe da arquitetura alvo de Brenda se sente como se estivesse em uma sinuca. É excelente que a Diretoria tenha dado alguma orientação para as estratégias de TI, suprimentos e produtos, mas ela não parece se harmonizar com aquilo que tinham em mente para a arquitetura alvo. Neste meio tempo a pressão está alta, uma vez que Brenda foi convidada a apresentar suas ideias sobre a estratégia em função da arquitetura alvo.

Por enquanto, Brenda coloca uma proibição na modelagem das coisas para a arquitetura alvo até que uma abordagem comum tenha sido acordada.

A equipe “linha de base”

A equipe da arquitetura de linha de base tem pleno acesso ao repositório e está trabalhando nas ligações entre as camadas, que eles esperam apresentar na próxima semana. A sua abordagem é trabalhar com tabelas de referência cruzada, e depois gerar algumas visões para mostrar como tudo se encaixa. As tabelas de referência cruzada que eles preparam são:

• Produtos & Serviços x Capacidades
• Capacidades x Sistemas
  • Isso deve também validar os serviços de aplicativos que foram definidos
• Sistemas x Infraestrutura
  • Isso deve também validar os serviços de infraestrutura que foram definidos

Além disso, a equipe de linha de base finalizou o panorama de aplicativos. Usando o Bizzdesign Enterprise Studio, eles geraram e publicaram um relatório HTML para as partes interessadas procurarem e analisarem o conteúdo. O relatório permite que os leitores naveguem pelo modelo e dinamicamente mostrem ou ocultem informações dos atributos para obter o nível de detalhe necessário. O exemplo abaixo mostra o panorama de aplicativos da BriteLite, mostrando os tipos de aplicativo através de cores, e a data de início de operação como um rótulo.

A equipe “alvo”

A equipe que está trabalhando na arquitetura alvo passou a maior parte do dia em um debate na frente do quadro branco. Várias abordagens têm sido tentadas, e a equipe lentamente desenvolve a ideia de que a estratégia e o framework de arquitetura podem ser reconciliados.

Depois de outra pausa para o café, um dos membros da equipe conecta seu iPad ao projetor e explica a ideia que lhe veio durante o intervalo.

A chave para resolver a questão, na sua opinião, está em considerar um sistema como uma coleção de dados e funcionalidade. Nesse caso, parte do sistema estaria na camada dos sistemas de inovação, e outra parte na camada dos sistemas de registro. Além disso, a camada pode ser complementada com o armazenamento para gerenciamento de dados (mestres) separados para as principais entidades, tais como clientes e produtos. Os sistemas de reporte (um armazém de dados) também podem estar nesta camada.

A equipe quer saber porque uma solução de MDM (Master Data Management) é necessária se serão usadas soluções melhores-das-categorias. É Brenda quem pode responder isto: porque vários desses sistemas requerem acesso aos mesmos dados! Usar um núcleo MDM será também um bom passo no sentido tirar uma capacidade de gestão de dados do solo. Ela rapidamente puxa um slide para mostrar a funcionalidade principal dos sistemas MDM, para explicar sua linha de raciocínio:

Indo em frente

A equipe concorda que esta abordagem permitiria resolver muitos problemas, mas reconhece também que ela seria dispendiosa. Ainda trabalhando no quadro branco, eles desenvolvem um roteiro para apresentar para a Diretoria que mostra:

• Como a arquitetura alvo funciona
  • com uma breve visão geral da TI BiModal e das camadas PACE
• Como as novas estratégias e arquitetura alvo se encaixam
• Quais serão as consequências
• Estimativa do custo (de alto nível pois é demasiado cedo para uma análise financeira detalhada)
• Estimativa dos benefícios e dos riscos desta abordagem

Brenda manterá a proibição de modelagem até que a Diretoria aprove esta direção. Enquanto espera, a equipe decide elaborar uma lista de aplicativos-chave, funções principais e objetos de dados que provavelmente serão usados.

Finalizando a arquitetura de linha de base

No início da semana, a equipe de linha de base anuncia que está quase terminando seu trabalho. Há ainda alguns pontos a revisar, mas no geral a estrutura está lá. A equipe trouxe o seguinte diagrama para ilustrar a sua maneira de trabalhar:

 Brenda está muito orgulhosa de que sua equipe consiga transmitir sua abordagem tão bem, especialmente quando a equipe de linha de base explica que eles também têm usado a ferramenta de modelagem para gerar várias visões em camadas para verificar os conhecimentos com as partes interessadas na organização. Eles pretendem publicar um pequeno conjunto destas visões em camadas como cartazes até o final da semana, juntamente com todas as tabelas de referência cruzada. O relatório HTML na Intranet local também está sendo atualizado com os mais recentes conhecimentos.

No final da reunião de equipe, Brenda pergunta à equipe de linha de base se eles necessitam de mais ajuda para ter a certeza de que os prazos são cumpridos, e encoraja a equipe a também escrever um boletim informativo que será distribuído a todas as partes interessadas na organização. A equipe está confiante de que eles vão cumprir o prazo, então todos podem voltar para suas tarefas.

Os resultados

No final da semana, tanto a equipe de linha de base como a equipe alvo estão orgulhosas de anunciar que tinham concluído suas tarefas. A equipe de linha de base apresenta suas conclusões primeiro, e distribui grandes folhas de papel que mostram as tabelas de referência cruzada que fizeram:

Matriz de Capacidades x Aplicativos, gerada usando o Bizzdesign Enterprise Studio

Matriz de Nós x Aplicativos, gerada usando o Bizzdesign Enterprise Studio

Eles também imprimiram várias visões em camadas, e explicam que querem fazer uma demonstração para as partes interessadas para mostrar como é fácil fazer análises sobre o modelo de linha de base. Esta ideia é bem recebida, e a equipe agendará isto para a próxima semana.

A equipe alvo trabalhou em uma apresentação que ilustra a natureza focada no negócio da arquitetura alvo, e ilustra os principais conceitos das abordagens PACE e TI BiModal, uma vez que estas são a base para a arquitetura alvo. Ela também mostra a relação com os componentes MDM nos sistemas de registro, e explica como isto se relaciona com as estratégias de negócio que estão prestes a serem aprovadas.

Esta (primeira) parte da apresentação corre muito bem. Especialmente o foco nos negócios, e os “ritmos” diferentes de desenvolvimento, são bem recebidos. No entanto, há também alguma impaciência e resistência: a Diretoria parece estar em um clima de “nós-somos-diferentes”, e não está interessada em discussões “acadêmicas” sobre ritmos de desenvolvimento. Com isso em mente, Brenda decide mencionar apenas brevemente a necessidade de pensar à frente, considerar a “iluminação inteligente” no contexto da Internet das Coisas (IoT-Internet of Things), e passa para o framework de arquitetura para ilustrar a linha de pensamento para a arquitetura de destino.

Ela puxa uma versão simplificada em PowerPoint dos resultados dos debates,e tenta explicar como, nesta configuração, o núcleo da arquitetura serão os dados. A camada de Sistemas de Registro (SOR-System of Records) será construída com ferramentas padrão, incluindo um hub de gerenciamento de dados mestres – e é cuidadosa para não entrar em detalhes quanto ao que isso implica: esta é uma discussão para mais tarde. Ela será suportada com processos (de gestão de dados) que garantem que os dados permanecerão consistentes e de alta qualidade.

Continuando a discussão, ela explica então como sistemas “melhores-da-categoria” podem ser comprados para suportar as principais capacidades da organização. Isto exige uma forte integração de dados, um tema que será discutido posteriormente. Ela também reforça a noção geral de suportar a produção através de um Sistema de Execução de Manufatura (MES-Manufacturing Execution System), enquanto mantém as novas políticas em mente. Isto irá simplificar o planejamento e os processos de produção, enquanto o núcleo separado (de sistemas de registro) de dados garante o controle sobre os dados.

Enquanto algumas pessoas parecem “perdidas nas nuvens”, vários dos principais participantes parecem compreender os benefícios de tal abordagem, mas sentem alguma “pegadinha”. Depois de explicar que flexibilidade e controle não são “grátis”, Brenda defende a necessidade de uma camada de integração, e salienta os aspectos de custo/benefício mais do que a tecnologia propriamente dita. Em sua apresentação, ela tenta tanto quanto possível tornar claro que as vantagens da utilização de uma camada de integração se encaixam realmente bem com as ideias sobre a arquitetura alvo que sua equipe desenvolveu até agora. Mas, ao mesmo tempo, existem argumentos contra a adição de uma camada de integração na arquitetura corporativa, como mostrado na tabela abaixo:

Vantagens e desvantagens do uso de uma camada de integração na Arquitetura Corporativa

Embora, novamente, haja alguma resistência, há também apoio para a sua abordagem: a Diretoria aprecia estar sendo envolvida tão cedo, mas não compreende suficientemente o impacto para decidir por uma ou outra opção. Compreendendo a necessidade de aprovação/orientação, fica resolvido que a equipe pode continuar por enquanto, mas terá de voltar com uma análise mais formal posteriormente.

Brenda compartilha a boa notícia com sua equipe, e lhes dá a luz verde para o agendamento de algumas sessões de modelagem da arquitetura alvo, começando com o panorama de TI.

Na próxima postagem, a equipe de Brenda detalha a arquitetura do MDM (Master Data Management), uma peça central na estratégia de mudança da BriteLite