Por Paddy Fagan, STSM IBM Watson Health
Trabalho em uma equipe que entrega atualizações para um aplicativo SaaS existente, no espaço de saúde e serviços humanos. Ao fazer isso, precisamos oferecer suporte aos nossos clientes / casos de uso existentes, expandir os casos de uso suportados e desenvolver a arquitetura para oferecer suporte a ambos e ao cenário em evolução do PaaS, em nosso caso IBM Cloud, que hospeda o aplicativo.
Em nossa abordagem, implementamos muitas das práticas de Arquitetura Ágil Aberta (O-AA™). Aqui, vou me concentrar na reestruturação arquitetônica contínua, particularmente no planejamento, compreensão e orientação da arquitetura. À medida que evoluímos nossa solução, precisamos equilibrar o esforço para melhorar a função / recurso para os clientes, acompanhando a evolução do PaaS e mantendo / melhorando as características não funcionais de nossa solução.
Em termos de planejamento, é fundamental ter uma ‘visão’ para a evolução da arquitetura, isso não é algo definitivo, mas sim uma melhor estimativa de para onde a arquitetura deve se dirigir com base no seu conhecimento atual. Isso pode e vai mudar à medida que fatores externos mudam e influenciam sua arquitetura. No entanto, não obstante a volatilidade da ‘visão’, continua a ser uma ferramenta central na orientação da evolução da arquitetura, pois atua como um ponto de referência para avaliar as alterações arquitetônicas propostas, para determinar se estão movendo a arquitetura como um todo em direção a suas metas.
Em minhas equipes, essa ‘visão’ tende a ser uma espécie de acúmulo, listando o conjunto de mudanças arquitetônicas que sentimos que precisamos fazer. Um elemento-chave do valor para nós é que nos permite ver rapidamente onde uma mudança proposta se cruza com esta lista – e isso pode ajudar na nossa tomada de decisão. Às vezes, isso nos faz mudar a ‘visão’ e, na verdade, às vezes permitimos mudanças que nos afastam ainda mais da ‘visão’.
Em muitos aspectos, a “visão” também é uma restrição fundamental para a compreensão e orientação da arquitetura, mas existem outras. Para minhas equipes, os custos de hospedagem e operações são sempre uma consideração muito importante – em resumo, se nossa solução não for lucrativa, não estaremos no mercado por muito tempo! A outra restrição importante para nós é a conformidade, nossas ofertas estão em áreas altamente regulamentadas e, com frequência, a mudança arquitetônica é restringida por isso. Perguntas como: “O serviço que queremos consumir está disponível em uma versão compatível?”, “Nossa solução como um todo pode continuar atendendo aos padrões de conformidade com essa mudança?” – muitas vezes dominam nosso pensamento. Os outros aspectos-chave para entender e orientar a arquitetura que desejo cobrir são as coisas que damos aos desenvolvedores / equipes para ajudá-los a permanecer dentro das restrições gerais da arquitetura à medida que projetam e implementam mudanças. Alguns deles são “Funções de Fitness”, verificação executável das características da arquitetura, alguns são “Guardrails” declarações escritas das características. Uma pressão constante nisso é tentar encontrar maneiras de codificar o máximo possível das características como “Funções de condicionamento físico” – a fim de reduzir o número de coisas que os desenvolvedores e as equipes devem considerar ativamente à medida que avançam.
Paddy Fagan é especialista em arquitetura e design de aplicativos de negócios corporativos. Trabalhando em SaaS e soluções locais em saúde e governo. Ele também é um ciclista ocasional, professor e pai. Paddy é conhecido como um líder técnico essencial. Paddy tem uma vasta experiência de trabalho com as principais iniciativas e clientes, oferecendo as melhores soluções para atender às necessidades de negócios estratégicas, incluindo implantações de reforma do sistema de saúde (ObamaCare) e principais clientes empresariais.