Preparar-se para a revisão do blueprint da solução

  • 10 minutos

Normalmente, a revisão do blueprint da solução dura entre duas e oito horas. Esse tempo pode variar de acordo com o nível de detalhe disponível para revisão e a amplitude da solução como um todo. O arquiteto de soluções trabalhará com a liderança da equipe de implementação para planejar o workshop com base nas especificações da solução que está sendo revisada.

Antes do workshop de revisão do blueprint da solução, os participantes devem se familiarizar o máximo possível com a estrutura do workshop e com os tipos de tópicos e pré-requisitos que serão abordados. O arquiteto de soluções fornecerá uma agenda com tópicos e pré-requisitos à frente do workshop.

Observação

A revisão do blueprint da solução é uma discussão e não deve ser visto como um questionário que pode ser respondido e revisado offline. Embora os pré-requisitos sejam definidos e fornecidos antecipadamente, não é possível delimitar as direções que a conversa pode tomar.

O arquiteto de soluções se preparará com antecedência para o workshop, revisando os artefatos de projeto existentes. Os artefatos úteis do projeto incluem:

  • Catálogos de processos – listas ou hierarquias de processos, subprocessos e histórias de usuários que fazem parte do escopo da implementação.
  • Diagramas de fluxos de processos – diagramas que podem adicionar contexto ao catálogo de processos e descrever a operação da empresa. No estágio de revisão do blueprint da solução, é mais útil analisar processos gerais e completos.
  • Diagramas de aplicativos – diagramas de blocos mostrando os vários componentes que compõem a solução. Esses diagramas também podem fornecer contexto para o mapeamento de recursos e componentes dos aplicativos ou explicar como esses componentes interagem entre si.
  • Requisitos de lacuna – áreas conhecidas de funcionalidade que não são consideradas como recebendo suporte do sistema padrão.
  • Diagramas de fluxo de dados – em uma solução que inclui vários aplicativos do Dynamics 365, aplicativos herdados ou serviços e componentes externos, é útil identificar de onde os dados vêm e como eles se movimentam e são consumidos na solução.
  • Estratégia de migração de dados – documentos ou registros que mostram as entidades a serem migradas, as fontes de onde elas virão, os volumes, o momento e os métodos de migração. No estágio de blueprint da solução, é essencial conhecer o escopo (tabelas e fontes).
  • Registro de interface – listas de interfaces com requisitos não funcionais e padrões de design que documentam o escopo e a abordagem de implementação a seguir.
  • Design de agregação de dados analíticos – diagramas ou registros de fontes de dados que serão migrados para análises agregadas.
  • Estratégia de ambientes – diagramas de blocos ou fluxogramas que descrevem os tipos de ambientes que serão provisionados, como e quando eles serão usados e como o código e a configuração fluirão por eles.
  • Perfis de uso do sistema – agendamentos de processos operacionais e volumes transacionais de pico por tipo de carga de trabalho.
  • Estrutura de entidades legais – diagramas ou registros que mostram as entidades legais que serão modeladas na solução e os relacionamentos entre elas.
  • Locais de implantação – diagramas ou registros que mostram os locais físicos nos quais a solução será implantada juntamente com requisitos de idioma e localização.
  • Estatuto do projeto – documento que fornece o histórico do projeto, especialmente os objetivos e os principais resultados esperados, stakeholders, orçamentos, linhas de tempo e marcos.
  • Plano/agenda do projeto – documentos ou gráficos de Gantt que representam a agenda e a dependência gerais das principais fases do projeto e as atividades associadas.
  • Matriz de atribuição de responsabilidade – tabela de tarefas e o relacionamento entre as funções do projeto e as tarefas. Esses relacionamentos são normalmente atribuídos por meio de uma classificação RACI (responsável, autorizado, consultado e informado).
  • Plano/estratégia de teste – documento que descreve os tipos de teste que serão feitos ao longo da implementação e como eles serão definidos, implementados e medidos.

Esta não é a lista completa da entrega do projeto, mas é um bom ponto de partida para a revisão do blueprint da solução. Os formatos, a composição e os nomes de cada entrega podem variar de um projeto para outro. O formato não é o componente mais importante. O essencial é ter informações disponíveis e acordadas na equipe.

Quando você realiza uma revisão do blueprint da solução no início do projeto, muitos desses documentos não estarão totalmente prontos, o que é aceitável na maioria dos casos. É mais importante identificar o escopo e elaborar um plano conceitual para determinar como a solução oferecerá suporte a esse escopo. Se o plano não for bem-sucedido, esses itens deverão ser representados de alguma forma na proposta de serviço fornecida pelo parceiro de consultoria auxiliando na implementação. Se a abordagem conceitual e de escopo de solução estiverem definidas, a revisão do blueprint poderá se concentrar na parte conceitual e os workshops aprofundados de acompanhamento poderão focar nos detalhes quando eles estiverem disponíveis.

É aceitável que seu projeto use maneiras diferentes de gerenciar ou acompanhar informações daquelas listadas anteriormente. Normalmente, o formato não será importante se as informações estiverem prontamente disponíveis para os membros do projeto. Se as informações listadas acima não estiverem documentadas no projeto, ou se estiverem documentadas de uma forma que não seja facilmente acessível, você deverá priorizar a produção dos artefatos relevantes.

Recomendamos que você use diagramas e representações visuais para fornecer resumos de alto nível, quando possível, na implementação. Esses diagramas e gráficos fornecem um meio imediato de comunicação sobre planos e projetos com toda a equipe e com a gerência executiva.

Observação

A revisão do blueprint da solução não pretende ser uma revisão exaustiva de requisitos detalhados ou documentos de design. A equipe de implementação trabalhará com níveis de detalhes mais específicos para gerar e apresentar a arquitetura geral. Pressupõe-se que a equipe de implementação exibirá as principais preocupações e os arquitetos farão consultas sobre potenciais áreas problemáticas. O arquiteto de soluções sugerirá workshops aprofundados para investigar áreas que exigirem avaliação adicional.