Planejamento e Roteirização: Funcionalidade Avançada para Análise Baseada no Tempo
Postado em 31 de mar. de 2020 por Antonio Plais
Originalmente postado por Marc Lankhorst e Sven van Dijk*, no blog da BiZZdesign – Tradução e adaptação autorizados
Nas nossa duas postagens anteriores, nós discutimos o planejamento e a roteirização no contexto da arquitetura corporativa, e como você pode usar os conceitos da linguagem ArchiMate para modelar seus roteiros. Nós mostramos como você pode modelar a evolução da sua empresa em um nível grosseiro, usando conceitos como o Platô do ArchiMate. Nessa postagem, discutiremos uma modelagem mais refinada da mudança no Enterprise Studio. Especificamente, mostraremos como você pode modelar os ciclos de vida dos elementos individuais da sua arquitetura e como nossa plataforma suporta a análise baseada em ciclos de vida e as dependências entre os elementos, por exemplo, para encontrar conflitos em seus planos de transição.
Modelando ciclos de vida
No Enterprise Studio, você pode adicionar propriedades temporais aos elementos do seu modelo. Como o nome diz, o valor destas propriedades pode mudar ao longo do tempo. Pense, por exemplo, em propriedades que representam a versão de um componente de aplicativo, ou o nível de maturidade de uma capacidade. Propriedades temporais podem ser usadas para todos os tipos de propósito no Visual Studio, mas aqui nós vamos usá-las para modelar ciclos de vida. O Enterprise Studio vem com vários ciclos de vida pré-configurados para diferentes tipos de elementos, como aplicativos e projetos, entre outros; além disso, você pode definir seus próprios ciclos de vida. Abaixo você pode uma visão de ciclo de vida de um conjunto de aplicativos, com os ciclos de vida de cada um associados à uma linha do tempo.
Visão de ciclo de vida
Nesta visão, você pode notar também as barras vermelhas abaixo de dois aplicativos. Isso demonstra conflitos de ciclo de vida, ou seja, eles podem estar trocando dados ou usando funcionalidades um do outro. Clicar na barra vermelha realçará qual é o aplicativo ‘conflitante’.
Na visão ArchiMate abaixo você pode ver exatamente como os aplicativos neste exemplo estão relacionados uns com os outros. Nós realçamos os relacionamentos que causam o conflito de ciclo de vida mostrados acima: ‘Ramadera’ serve ‘Crystal Ball’, o qual por sua vez serve ‘Backbase CXP’. Assim, se Ramadeira é desligado porque está em manutenção, Crystal Ball não pode fazer o seu trabalho. Como os vários relacionamentos na sua arquitetura afetam as dependências dos estágios do ciclo de vida é totalmente configurável. Isso pode incluir dependências através das camadas, por exemplo mostrando quais processos de negócio usam serviços e componentes de aplicativo; aplicativos que usam certas tecnologias, como sistemas operacionais, interfaces ou plataformas de bancos de dados; ou projetos que realizam as várias partes da arquitetura.
Panorama parcial de aplicativos realçando as dependências que causam os conflitos de ciclo de vida
Análises de ciclo de vida avançadas
Você pode também executar esta análise para casos mais complexos, tais como relacionando os estágios de um projeto com o ciclo de vida do aplicativo que ele constrói, ou determinar o que acontece se uma equipe ágil decide adiar uma funcionalidade para o próximo sprint. Isso pode ajudar você para avaliar quais funcionalidades relevantes para o negócio serão atrasadas e quais clientes poderiam ser afetados. Com base nessa informação, você pode decidir a respeito das suas prioridades de desenvolvimento.
A figura abaixo mostra um exemplo mais elaborado. No alto, vemos como um conjunto de pacotes de trabalho dependem das saídas dos outros. Neste cenário, estes pacotes de trabalho refletem diferentes projetos, mas eles poderiam ser usados para modelar, também, sprints em um contexto ágil. Os sinais de aviso na figura, e a tabela à esquerda, mostram que se o Projeto P428 terminar atrasado acontecerá um conflito, uma vez que o Projeto 473 precisa da saída do primeiro projeto. Mais ainda, existem problemas potenciais com uma sobreposição de escopo, como mostrado na tabela da direita: os Projetos P431 e P473 trabalham ao mesmo tempo no aplicativo New Relic Insights. Se eles também se sobrepõem no tempo, eles podem acabar trombando um com o outro.
Planejamento e dependências entre projetos
A informação sobre o escopo dos projetos, por sua vez, é buscada em outra parte do modelo. A visão abaixo mostra o roteiro de alto nível do programa de racionalização de aplicativos. As caixas rosa representam os mesmos projetos mostrados acima, migrando os dados de um aplicativo antigo para um novo aplicativo. Se um projeto toca um aplicativo, então aquele aplicativo está no escopo daquele projeto.
Roteiro de alto nível
Este roteiro usa o conceito de platô do ArchiMate para modelar os principais estágios na transição do panorama de aplicativos, de uma forma semelhante ao que nós mostramos na postagem anterior. Assim, você pode conectar seu planejamento grosseiro de alto nível com as informações detalhadas dos ciclos de vida dos aplicativos, projetos e outros elementos individuais.
Se você quer saber mais sobre estas e outras funcionalidades avançadas do Enterprise Studio, entre em contato ou solicite uma uma demonstração.
* Mark Lankhorst é Gerente de Consultoria & Evangelista-Chefe de Tecnologia, e Sven van Dijk é consultor-líder da Bizzdesign, empresa líder em ferramentas para modelagem da arquitetura corporativa, representada no Brasil pela Centus Consultoria.
eBook
ArchiMate: da Teoria à Prática
Inovação, regulações em constante mudança, novas possibilidades tecnológicas, uma nova direção estratégica; estas são algumas das razões pelas quais muitas organizações estão em constante movimento. Este livro apresenta as melhores práticas dos autores, fruto da experiência do uso da linguagem ArchiMate em dezenas de projetos reais, em clientes dos mais diversos ramos de negócio. Uma […]