5 passos para uma arquitetura empresarial mínima viável

Na Vault Health, o CTO Steve Shi inicia o trabalho de arquitetura corporativa (EA) com uma pesquisa local de toda a infraestrutura de TI, aplicativo, sistema e dados, mas restringe-o a duas semanas com entrevistas de uma hora sobre cada função.

Os clientes, sejam funcionários ou aqueles que pagam por um produto ou serviço, devem “amar” o resultado dessa abordagem mínima viável para a EA, diz Shi. “Se você não conseguir a adesão do cliente, perderá o impulso e, se perder o impulso, será mais difícil continuar iterando após o lançamento mínimo viável”, diz ele.

Como muitos líderes de TI, Shi está tentando encontrar um equilíbrio entre estudos de arquitetura complexos que não são usados e relatórios de EA básicos que carecem de escopo e profundidade suficientes para fornecer valor duradouro. Encontrar esse equilíbrio requer estar próximo das necessidades de negócios, reduzir o trabalho ocupado, definir o escopo do projeto adequadamente e definir e aplicar os padrões e princípios de arquitetura corretos. Aqui estão cinco etapas que os CIOs veteranos do processo recomendam.

Fique perto do negócio

Manter uma comunicação próxima com as partes interessadas do negócio é a única maneira de saber onde uma arquitetura empresarial mínima viável (MVA) pode ajudar melhor o negócio e direcionar o financiamento para avaliações contínuas de EA à medida que as necessidades do negócio mudam.

Na Carrier Global Corp., o CIO Joe Schulz mede o sucesso da EA por métricas de negócios, como a forma como a produtividade dos funcionários é afetada pela qualidade do aplicativo ou interrupções de serviço.

“Não vemos a arquitetura corporativa como um único grupo de pessoas que são os guardiões, que são mais teóricos por natureza sobre como algo deve funcionar”, diz Schulz. Ele usa relatórios e insights gerados pela ferramenta EA LeanIX para descrever a interconectividade do ecossistema, bem como os recursos dos sistemas em todo o portfólio para identificar redundâncias ou lacunas. Isso permite que o fornecedor global de soluções inteligentes de construção e cadeia de frio “democratize grande parte da tomada de decisões… (para) trazer todo o melhor pensamento e capacidade de investimento em toda a nossa organização”.

George Tsounis, Diretor de Tecnologia da empresa de serviços e tecnologia falida Stretto, recomenda o uso da EA para “estabelecer confiança e transparência”, informando os líderes de negócios sobre os gastos atuais de TI e as áreas em que as plataformas não estão alinhadas com a estratégia de negócios. Isso torna as futuras conversas relacionadas à EA “muito mais fáceis do que se o arquiteto corporativo estivesse trabalhando em um silo e não tivesse esse relacionamento”, diz ele.

Corte a burocracia

Questionários extensos e entrevistas baseadas em modelos são uma parte familiar e muitas vezes indesejada dos esforços de EA. Praticantes de MVA sugerem eliminar quaisquer perguntas que não forneçam informações essenciais e permitam o feedback dos usuários.

Gregor Hohpe, Diretor de Estratégia Corporativa no hiperescalador de nuvem Amazon Web Services, recomenda passar de processos de EA “pesados e em grande parte unidirecionais” para conversas mais simples, rápidas e interativas com usuários corporativos.

Na empresa de serviços financeiros State Street, Aman Thind, Arquiteto-Chefe Global, tenta agilizar o processo de EA fazendo apenas perguntas precisas e relevantes, em vez de tudo em um modelo de EA. Concentrar-se nas questões mais essenciais pode reduzir o tempo necessário para a revisão e submissão da arquitetura em, pelo menos, a metade e torna o processo muito mais eficaz, diz ele. Por exemplo, a estrutura que um aplicativo SaaS usa para fornecer a interface do usuário é menos importante do que os procedimentos de gerenciamento de identidade e acesso que determinam como os usuários interagem com ele.

Juntamente com o uso de verificações de conformidade automatizadas e plataformas de autoatendimento, Hohpe recomenda eliminar “listas intermináveis de padrões que são amplamente ignorados”; reuniões de revisão em que todos os documentos são submetidos à engenharia reversa do resultado preferido da respectiva equipe; reuniões de “alinhamento” em tópicos que não agregam valor; e a “geração de tapeçarias gigantes de ferramentas de EA de peso que nunca são usadas para tomada de decisão”.

Na Vault, uma empresa de assistência médica digital, Shi considera a ferramenta de observabilidade de aplicativos New Relic valiosa para acelerar o trabalho de EA, fornecendo visibilidade instantânea de toda a arquitetura.

Ele também usa novos termos e processos para evitar lentidão comum e criar consciência de sua nova abordagem. Um exemplo é um “relatório do site” que pede aos usuários que visualizem o produto final do EA. Isso ajuda a definir requisitos críticos, como o número de transações e os tipos de processos que um aplicativo deve suportar, “vindos do lado do cliente e trabalhando de trás para frente”. Em vez de usar um processo “one and done” de pedir aos usuários que concordem com uma decisão tecnológica crítica antecipadamente, Shi os desafia a confirmar ou revisar “hipóteses de desenvolvimento”, como o número de chamadas de banco de dados que um sistema deve suportar a cada dia. Essa abordagem acelera o acordo sobre as escolhas de componentes, como bancos de dados, diz ele.

Durante o lançamento do aplicativo, Shi evita um plano de projeto genérico em favor do que ele chama de “um plano de sequenciamento de macro específico” de etapas construídas em torno de marcos como testes alfa e beta e seus marcos de validação associados. Isso define, para cada estágio da implantação, o sucesso em termos de negócios, como receita ou taxa de adoção do usuário, e as lições aprendidas do processo de suporte que reduzem os custos de suporte contínuo. Também lembra a todos, diz ele, que “o projeto não termina até que saibamos que a arquitetura entregou valor mensurável ao cliente”.

Escopo certo

Assuma muita coisa em um projeto de MVA e ele ficará desatualizado antes de ser feito, entregando resultados tarde demais para satisfazer e receber financiamento futuro de líderes empresariais. Restrinja-o demais e não fornecerá a visão abrangente da tecnologia e dos negócios necessários para aproveitar ao máximo os investimentos em TI. Alcançar o equilíbrio adequado geralmente requer o foco em um aplicativo ou ponto problemático no negócio ou em uma área onde os requisitos estão mudando rapidamente devido a novos negócios ou necessidades regulatórias.

Nolan Hart, Analista Principal associado do Gartner Inc., chama o escopo de EA adequado de “o menor número de entregas, como pontos de vista, modelos de referência e padrões de design, que ajudam a garantir a entrega oportuna e compatível de produtos e soluções”. Em vez de gastar muito tempo entendendo a arquitetura atual, ele recomenda “primeiro, entenda os resultados desejados”. Não há valor, diz ele, em se “perder documentando sua arquitetura disfuncional atual para todo o sempre”.

Shi recomenda que um MVA considere “tudo, desde a interface do usuário até as APIs que vinculam os sistemas à arquitetura de dados, em vez de um único componente ou serviço em silos”. A arquitetura proposta também deve ser testável em escala de produção, diz ele, e lidar com os mesmos requisitos de pico do sistema que ela substitui.

O escopo adequado também se aplica à organização da EA. Em vez de um grupo de EA dedicado, a Carrier criou centros de excelência para as principais necessidades, como recursos de CRM, serviço de campo, ERP, analytics e fábrica digital. Esses centros fornecem uma base simplificada de componentes principais que permitem inovar rapidamente sem exigir um exercício de EA para avaliar plataformas separadas para cada unidade de negócios, diz Schulz.

Se um grupo dentro de uma empresa não estiver interessado em um projeto mínimo viável de EA, “há muitas outras pessoas que vão dedicar seu tempo a isso”, diz Hart. Combine essa demanda com as habilidades de um grupo de EA para determinar “três a cinco tipos de serviços que você pode oferecer para entregar esses resultados de negócios com uma abordagem mínima viável”.

Defina e aplique padrões

A aplicação dos princípios de design, juntamente com o foco nas necessidades de negócios, pode ajudar a encurtar “argumentos filosóficos sobre qual solução é a melhor”, diz Tsounis. Os princípios que ele incentiva incluem “sempre tente criar a solução mais simples possível, não exagere na engenharia, permita a reutilização máxima em toda a organização, aproveite os padrões de design de arquitetura estabelecidos, bem como serviços baseados em nuvem, antes de criar algo novo”.

Arquiteturas e padrões de referência em áreas como segurança cibernética, governança de dados, gerenciamento de produção e práticas recomendadas de implantação fornecem um “manual pronto” para construir aplicativos combináveis de forma eficiente que são robustos, compatíveis e resilientes por design, diz Thind. Essas arquiteturas, construídas de microsserviços que são “muito bem definidos… em termos de suas APIs, sua escalabilidade e como eles interoperam”, permitem que uma empresa substitua qualquer microsserviço sem afetar nenhum outro, criando assim um design à prova de futuro.

Hohpe diz que alguns padrões sufocam a inovação, enquanto outros a impulsionam. Por exemplo, interfaces uniformes são essenciais para criar arquiteturas fáceis de adaptar. No entanto, padrões excessivamente rígidos podem levar a escolhas de tecnologia ruins. Ele se lembra de uma equipe de aplicativos que escolheu XML como interface de componente em vez de protocolos de comunicação mais rápidos. Quando perguntado por que, a equipe respondeu que a equipe de arquitetura exigia isso, aparentemente sem considerar o efeito prejudicial da análise XML no desempenho do aplicativo.

Comece em algum lugar

No mínimo, diz Thind, nomeie um “…um arquiteto-chefe, um executivo que avalie os padrões gerais, a governança geral, as plataformas gerais e a disciplina geral do design de aplicativos desde o topo. Apenas ter essa posição sinaliza a importância da arquitetura para toda a empresa e instiga os comportamentos certos que precisamos para criar organizações de TI eficientes e inovadoras”.

Dar início a uma MVA pode começar simplesmente “fazendo um balanço”, diz Thind, identificando gastos excessivos como “por que temos seis aplicativos diferentes para o mesmo processo, cinco contratos diferentes (para) a mesma ferramenta de BI, vários contratos de dados de mercado com o mesmo escopo, clusters Hadoop 24×7 para relatórios mensais e assim por diante”. Mas mesmo um esforço mínimo viável pode trazer grandes benefícios. “Apenas garantir que a ferramenta certa seja usada para o trabalho certo e que haja padronização e práticas recomendadas em torno de seu uso, pode causar um impacto considerável no resultado final e levar a menos dívida técnica, requisitos de suporte reduzidos e permitir uma inovação mais rápida”, ele diz.