Planejamento e Roteirização: Modelando com ArchiMate

postado em 30 de mar. de 2020 10:14 por Antonio Plais   [ 31 de mar. de 2020 13:42 atualizado‎(s)‎ ]
Originalmente postado por Marc Lankhorst e Sven van Dijk*, no blog da BiZZdesign- Tradução e adaptação autorizados

Na nossa postagem anterior sobre planejamento e roteirização, discutimos a ideia geral do planejamento e roteirização no contexto da arquitetura corporativa e o planejamento baseado em capacidades. Nós abordamos vários níveis de roteiros, desde sprints de curto prazo com duração de poucas semanas, até roteiros de longo prazo cobrindo vários anos. Nesta postagem, queremos ir um pouco mais fundo nas várias formas de modelar a evolução da sua arquitetura.

Modelando roteiros com platôs

Uma das características mais marcantes da linguagem ArchiMate é o conceito de Platô. No padrão, isso é definido como: "um estado relativamente estável da arquitetura que existe durante um período limitado de tempo". A intenção deste conceito é modelar mudanças razoavelmente grandes na sua arquitetura, por isso 'relativamente estáveis'; mudanças em pequena escala são muito frequentes para se permitirem serem capturadas através de platôs. Por exemplo, você não deveria modelar cada atualização individual nos seus aplicativos desta forma. Uma vez que, de qualquer forma, estas pequenas mudanças raramente tenham significância arquitetural (embora possam, naturalmente, ser importantes por outras razões), um modelo de arquitetura não é o melhor lugar para capturar tais mudanças. Assim sendo, esta forma de modelar é particularmente útil nos níveis estratégico e tático com os quais tipicamente a arquitetura corporativa está preocupada.

Um platô é válido por algum período de tempo, então ele tipicamente tem uma data de início e de término. Um platô pode entrar em vigor depois que algum projeto ou trem de entrega ágil (ART-Agile Release Train) entrega uma mudança, e continua em vigor até que a próxima mudança acontece. Em termos de relacionamentos ArchiMate, platôs podem agregar quaisquer elementos ou relacionamentos na arquitetura que sejam válidos dentro do período compreendido pelo platô, O escopo da arquitetura de um platô pode ser limitado a uma parte específica da arquitetura, por exemplo, um domínio de negócio ou um sistema específico. Vários sub-platôs podem ser agregados em um platô mais amplo, para modelar, por exemplo, o roteiro completo que consiste de da evolução dos diferentes domínios de negócio. Naturalmente, você deveria manter os períodos de tempo dos sub-platôs consistentes com seu platô 'pai', se não seu modelo não fará muito sentido.

Modelando cenários

Você também pode usar platôs para expressar caminhos alternativos em direção ao futuro. A figura abaixo dmostra um exemplo disso, em um cenário pós-fusão de duas organizações: na Transição A, um sistema CRM comum é implementado primeiro, enquanto na Transição B os sistemas de retaguarda são substituídos primeiro. A Transição C, então, é o estado em que tanto o CRM como os sistemas de retaguarda já estão consolidados, e ele antecede a implementação de um armazém de dados comum.

Exemplo de roteiro com platôs

A notação gráfica para os platôs é útil principalmente para mapear tal evolução, ao invés de organizar a arquitetura em si, uma vez que muitos elementos na sua arquitetura farão parte de vários platôs. Por exemplo, tudo aquilo na Linha de Base que sobrevive através das transições pode ser agregado em todos os platôs.

Por essa razão, nós geralmente usamos platôs em um modelo de arquitetura, mas não necessariamente em uma visão da maneira mostrada acima. Ao invés disso, nós entramos com os relacionamentos de agregação entre os platôs e o seu conteúdo em uma tabela de referência cruzada e usar isto em visões e análises. A figura abaixo mostra um exemplo disso, realçando os elementos de acordo com os platôs em que eles estão, também com base no mesmo cenário acima:

Realçando os platôs na arquitetura

Modelando incrementos e releases como especializações

Além da evolução grosseira do roteiro mostrada acima, você também pode querer modelar que algum elemento da arquitetura está sendo evoluído. Um exemplo comum disso é usar 'incrementos de capacidade' para expressar que a maturidade de uma capacidade cresce ao longo do tempo. Uma boa forma de fazer isso é modelar cada incremento como uma especialização de um elemento genérico de mais alto nível, neste caso esta capacidade específica, e agregar estas especializações nos platôs apropriados. Desta forma, você pode ver tanto a estrutura geral da arquitetura - ou seja, quais elementos são necessários para realizar esta capacidade - como mostrar as melhorias consecutivas. O mesmo padrão funciona para a modelagem de releases de software, de forma que você pode modelar o elemento genérico 'App de Pagamento' com especializações como 'App de Pagamento v3.3',  'App de Pagamento v3.4' e  'App de Pagamento v4.0'. Cada um destes elementos pode, por sua vez, ser relacionado com um platô que começa na data de liberação ou implementação daquela versão, e que termina quando ele é substituído pela próxima. A figura abaixo mostra isso:

Roteiro com releases e versões

Na próxima postagem desta série, daremos uma olhada na modelagem do tempo em um nível mais detalhado e granular. Discutiremos também como você pode modelar os ciclos de vida dos elementos individuais e usar dependências entre os estágios dos ciclos de vida dos vários elementos na sua arquitetura para identificar, por exemplo, conflitos nos seus planos de transição. Se você quiser ver qualquer uma destas funcionalidades ao vivo e a cores, na nossa ferramenta BiZZdesign Enterprise Studio, assista nossos vídeos de introdução ou agende 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.