fbpx
Como descrever um roadmap de arquitetura de forma clara
Publicado em: terça-feira, 13 de jun de 2023
Categorias: Arquitetura

Em um mundo cada vez mais voltado para a tecnologia, a arquitetura de soluções desempenha um papel crucial na orientação de como as organizações desenvolvem e implementam suas estratégias digitais. No entanto, a maneira como apresentamos e comunicamos essas arquiteturas pode muitas vezes ser um desafio. Tradicionalmente, a visão de desenhos arquiteturais têm se concentrado em fornecer “snapshots” estáticos de uma arquitetura em um determinado ponto no tempo. Eles são fundamentais para uma visão clara da arquitetura, mas esses modelos podem não capturar completamente a complexidade e a natureza evolutiva de uma arquitetura de soluções.

Este post é destinado a desenvolvedores, aspirantes a arquitetos de software, arquitetos de soluções profissionais e qualquer pessoa interessada em explorar novas maneiras de visualizar e entender a arquitetura de soluções. Aqui, discutiremos uma nova abordagem para apresentar roadmaps de arquitetura de soluções, uma que vai além dos diagramas de arquitetura e conta uma história sobre todo o ciclo de vida evolutivo da arquitetura.

Em vez de se concentrar em um único ponto no tempo, este novo modelo apresenta a arquitetura como uma linha do tempo, com ação e reação. Ele permite que você veja como a arquitetura evoluiu ao longo do tempo, destacando as relações de causa e efeito, problema e solução. Ao fazer isso, esperamos que este modelo ofereça uma visão complementar e rica da arquitetura de soluções, ajudando a melhorar a comunicação entre as partes interessadas e a facilitar a tomada de decisões estratégicas.

Então, se você está pronto para explorar uma nova maneira de pensar roadmaps de arquitetura, continue lendo. Estou animado para compartilhar essa jornada com você.

Contexto

A arquitetura de soluções é uma disciplina complexa e multifacetada. Ela envolve a concepção, o design, a implementação e a manutenção de sistemas de TI que atendem às necessidades de negócios de uma organização. No entanto, a maneira como esses sistemas evoluem ao longo do tempo é muitas vezes esquecida ou mal compreendida. Isso é em grande parte devido à maneira como o mercado enfatiza a adoção de diagramas que descrevem comunicações e interações, mas ignoram causa e efeito, ação e reação, e como endereçamos pontos importantes da jornada.

Os diagramas de arquitetura convencionais descrevem como as coisas são, como se conectam, que caminho percorrem. Mas não nos contam como chegamos à aquela decisão, quais foram as influências, que problemas queremos resolver, como chegamos à determinada solução. Esses recortes no tempo, negligenciam o roadmap e as premissas fundamentais que permitem um melhor entendimento sobre a estratégia por trás de uma arquitetura de soluções.

Além disso, esses modelos estáticos muitas vezes não capturam a complexidade e a natureza dinâmica da arquitetura de soluções. Eles mostram como os diferentes componentes do sistema interagem entre si, mas raramente abordam como eles podem evoluir ao longo do tempo. Isso pode levar a uma compreensão fragmentada e superficial da arquitetura, e principalmente do roadmap. Essa questão é agravada quando estamos diante de uma jornada de transformação com várias etapas, em que definimos estágios em uma jornada maior. A falta desse tipo de contexto, pode, por sua vez, levar a decisões de negócios mal informadas e a uma implementação ineficaz da estratégia de TI.

Para resolver esses problemas, proponho uma abordagem exclusiva para apresentar roadmaps de arquitetura de soluções. Este modelo apresenta a arquitetura como uma linha do tempo. Ele conta uma história sobre todo o ciclo de vida evolutivo da arquitetura, mostrando não apenas onde estamos agora, mas também de onde viemos e para onde estamos indo.

Acreditamos que este modelo oferece uma visão mais rica e mais completa da arquitetura de soluções. Ele permite que as partes interessadas vejam a “big picture” da estratégia de arquitetura, incluindo as relações de causa e efeito, e impactos importantes. Ao mesmo tempo, mostramos como lidamos com as adversidades na estratégia de arquitetura.

Ao fazer isso, espero que este modelo possa melhorar a comunicação entre as partes interessadas, facilitar a tomada de decisões estratégicas e, em última análise, levar a uma implementação mais eficaz da estratégia de TI.

Ao embarcar nesta nova abordagem para apresentar roadmaps de arquitetura de soluções, é importante entender como ela se diferencia dos modelos tradicionais e como ela pode ser aplicada na prática. Vamos explorar isso em detalhes.

O Novo Modelo: Uma Visão Evolutiva

Em vez de fornecer um “snapshot” estático de um ponto no tempo, o novo modelo apresenta a arquitetura como uma sequência temporal de ações e reações a cada um dos dilemas de uma arquitetura. Ele conta uma história sobre todo o ciclo de vida evolutivo da arquitetura, desde a concepção inicial até a implementação, conectando com o futuro projetado para a arquitetura.

Benefícios do Novo Modelo

O novo modelo oferece vários benefícios que complementam modelos tradicionais. Primeiro, ele fornece uma visão mais completa do processo evolucionário da arquitetura. Em vez de se concentrar em um único ponto no tempo, ele mostra como a arquitetura evoluiu ao longo do tempo. Isso pode ajudar as partes interessadas a entender melhor a lógica por trás das decisões de arquitetura e a planejar efetivamente para o futuro.

Segundo, o novo modelo traz uma visão atual, de médio e longo prazos, permitindo dar luz à como a estratégia é composta, de tal forma que inconsistências entre visões de C-Level e Arquitetura possam ficar evidenciadas. Com a visão de longo prazo, fica fácil entender onde queremos chegar, e para onde estamos caminhando, da mesma foram que fica fácil entender como planejamos alcançar esse objetivo de longo prazo e quais etapas e marcos intermediários são necessários.

Terceiro, esse modelo apresenta uma estratégia completa, de um estado original, AS-IS, para o TO-BE, levando em conta a necessidade de passar por estágios intermediários.

Ferramentas necessárias

Embora ferramentas como Visio e Bizagi possam ser úteis para implementar o novo diagrama, é importante notar que qualquer ferramenta — até mesmo um quadro branco — pode ser usada. O mais importante é a abordagem de contar uma história sobre o ciclo de vida evolutivo da arquitetura, não a ferramenta específica usada para fazê-lo.

As cores são úteis para demonstrar pontos positivos e enquanto os vermelhos apresentam pontos negativos.

Exemplos de Aplicação Real

Ao longo dos últimos 10 anos, validamos e repetimos o novo modelo em várias situações. Cada um desses exemplos fornece uma visão valiosa sobre como o modelo pode ser aplicado na prática.

Além disso, no post “Por onde andei, andei frustrado”, forneci um exemplo de um roadmap bem-sucedido usando o novo modelo. Embora o título possa parecer um nome de música, o post detalha um roadmap de 2013 em que empreguei esse diagrama com sucesso. Este é apenas um exemplo de como o novo modelo pode ser usado para melhorar a comunicação e a tomada de decisões estratégicas na arquitetura de soluções.

Desde 2013 tenho aplicado esse modelo em diversos clientes em diversos projetos para apesentar roadmaps para times de arquitetura, times de negócio, diretores e CEO’s.

Esse modelo tem a habilidade de dar transparência para times técnicos e não técnicos. Muitos dos assuntos abordados no diagrama, são temas que Gestores de Médio e Alto escalões ouviram vagamente falar, e agora conseguem enxergar de forma visual.

Ao mesmo tempo, ao apresentar a estratégia completa, é possível abrir margem para novas discussões, sobre COMO tangibilizar essa estratégia em ações. E o diagrama cumpre o papel de provocar discussões e o entendimento da micro-estratégia operacional que dará vida, no dia-a-dia do projeto.

Essa visão ampla fornece ainda um mecanismo para revisitarmos e realinharmos o curso da operação.

Aplicando o Novo Modelo

A aplicação do novo modelo de roadmap de arquitetura de soluções começa com a compreensão do ciclo de vida da arquitetura. Isso inclui a concepção inicial, o design, a implementação, a manutenção e a evolução. Cada um desses aspectos é representado na linha do tempo, proporcionando uma visão clara e compreensível do progresso da arquitetura.

Por exemplo, a fase de concepção pode incluir a identificação das necessidades do negócio e a definição dos objetivos da arquitetura. Nós adicionamos à camada superior, blocos que descrevem problemas, reclamações, aspectos negativos que demandam alguma ação na arquitetura. Ainda que de forma superficial, apresentamos problemas que a arquitetura se propoem a resolver.

A fase de design pode envolver a escolha de tecnologias e a definição de como elas serão integradas. A fase de implementação pode envolver a construção e o teste do sistema, enquanto a fase de manutenção pode envolver a monitoração e a atualização do sistema conforme necessário. Finalmente, a fase de evolução pode envolver a adaptação do sistema para atender a novas necessidades ou desafios do negócio.

Ao longo de todo esse processo, o novo modelo de roadmap ajuda a destacar as relações de causa e efeito, os marcos importantes, incluindo, em algumas raras ocasiões, casos de uso excepcionais. Isso permite que as partes interessadas vejam como as decisões tomadas em uma fase afetam as outras fases, ajudando a melhorar a tomada de decisões e a comunicação.

Validação do Novo Modelo

Ao longo dos últimos 10 anos, tive a oportunidade de validar e repetir o novo modelo em várias situações. Em cada caso, o modelo provou ser uma ferramenta valiosa para melhorar a comunicação e a tomada de decisões estratégicas. Principalmente quando estamos falando com quem paga a conta.

Em algumas ocasiões, foi possível evidenciar percepções e feedbacks do usuário reportando problemas relacionados à qualidade, que demandaram adição de testes não somente unitários, mas integrados. Não seria nada exótico diagnosticar a necessidade de testes de implantação, dependendo da complexidade e/ou o nível de distribuição global, dependendo de como o produto é implantado.

O dia-a-dia de um arquiteto é repleto de turbulência e não é incomum esquecer do que já foi realizado. Essa visão se apresenta como um mapa, que lista os principais assuntos de interesse e a estratégia para atacar cada um deles.

Por inúmeras vezes, o distanciamento de times executivos do dia-a-dia de operações faz com que nos esquecemos do que foi feito desde o último report. São tantas demandas de baixo nível, tanta implementação para tangibilizar esse diagrama em passos reais e realizáveis, que não é incomum esquecer o que foi feito há 2 ou 3 meses.

Não é incomum ser questionado sobre eventos do passado dos quais já não me recordo, e com esse diagrama consigo revivenciar cada um dos momentos, mostrando claramente todo o caminho percorrido, como um mapa que me diz como chegamos até aqui.

Acima tenho um exemplo de como comunicar a arquitetura e as decisões estratégicas em um cliente que estou atuando hoje. Nele comunico todo o ciclo da arquitetura desse projeto. Ele está em fase inicial, mas é um projeto global, com demandas globais de deployment em múltiplos data-centers, e essa é uma visão sobre o esboço inicial de arquitetura. São os primeiros momentos desse projeto.

A versão acima está ofuscada, por questões contratuais, de tal forma que não permite a leitura do conteúdo. É uma demonstração de como esse modelo é adotado consistentemente nos últimos 10 anos nos meus projetos.

Já adotei esse modelo para negócios, no contexto de empreendedorismo, com a criação de um roadmap estratégico, da mesma forma que para outras atividades menores como a criação de um produto.

Conclusão

Em resumo, a abordagem de contar uma história sobre o ciclo de vida evolutivo da arquitetura de soluções oferece uma perspectiva única e valiosa. Ela permite uma compreensão mais profunda das interações, dependências e evoluções que ocorrem ao longo do tempo, proporcionando uma visão mais completa e contextualizada da estratégia de arquitetura.

Ao adotar essa abordagem, você pode melhorar a comunicação entre as partes interessadas, facilitar a tomada de decisões estratégicas e aumentar a eficácia da implementação da estratégia de TI. Além disso, essa abordagem pode ajudar a identificar e resolver problemas que podem não ser evidentes em um “snapshot” estático da arquitetura.

Convido você a explorar essa abordagem em seus próprios projetos. Acredito que, ao adotar essa nova forma de visualizar a arquitetura de soluções, você poderá trazer uma nova perspectiva para sua equipe e para a organização como um todo. Em especial time executivo e estratégico.

Ao final, gostaria de encorajá-lo a compartilhar suas experiências e feedback. Sua perspectiva é valiosa para mim e para a comunidade mais ampla de arquitetos de soluções e tomadores de decisão técnicos. Juntos, podemos continuar a aprimorar a maneira como visualizamos e entendemos a arquitetura de soluções.

2023-JUN-14

Algumas discussões sobre esse diagrama merecem estar presentes aqui.

Esse diagrama não substitui outros

Esse diagrama não tem pretensão de substituir nenhum outro. A ideia é conseguir trazer informações que outros diagramas não trazem em um novo diagrama.

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.