Tópico 4.0 — Arquitetura técnica, nuvem e sistemas legados

Na saúde e nos cuidados, a arquitetura técnica é uma decisão de segurança clínica, de proteção e de dinheiro público tomada com anos de antecedência: as plataformas que você monta e o legado que deixa no lugar determinam em silêncio se o cuidado pode ser seguro, integrado e acessível muito depois de as pessoas que os escolheram terem seguido em frente.

Por que isso importa na saúde e nos cuidados#

A arquitetura é o conjunto de escolhas estruturais de longa duração por baixo dos seus serviços digitais: o que roda onde, como os componentes se conectam, o que você constrói em comparação com o que compra e o que mantém vivo do passado. Essas escolhas raramente são visíveis para pacientes ou clínicos e raramente empolgam os conselhos. Mas moldam tudo o que está por cima. Um parque bem arquitetado permite acrescentar um novo serviço depressa, compartilhar dados com segurança e se recuperar rápido quando algo quebra. Um mal arquitetado torna cada mudança lenta, cada integração frágil e cada incidente pior.

Na saúde e nos cuidados, o que está em jogo é alto porque os sistemas são de consequência. Quando um sistema de administração de pacientes envelhecido cai, ambulâncias desviam e clínicas cancelam. Quando um sistema operacional sem suporte é explorado, prontuários confidenciais são expostos e os serviços param — como o NHS aprendeu em 2017, quando o ataque de ransomware WannaCry se espalhou por máquinas que rodavam software que não podia mais receber correções. Aquela interrupção não foi um ataque inteligente e direcionado; foi a consequência previsível da dívida técnica acumulada em sistemas críticos. As decisões de arquitetura são, portanto, decisões de segurança, quer alguém as enquadre assim ou não.

São também decisões de equidade e de confiança. Os sistemas legados que não conseguem compartilhar dados deixam os pacientes mais complexos — os que tocam muitos serviços — com os prontuários mais fragmentados. Plataformas fechadas que prendem você a um único fornecedor drenam dinheiro que poderia financiar o cuidado. E o público espera, com razão, que o NHS rode em tecnologia moderna, segura e bem mantida; a distância entre essa expectativa e o parque real é, em si, um risco para a confiança.

Por fim, é aqui que muito dinheiro público é comprometido por muito tempo. A parte mais cara de um sistema raramente é a sua compra; é a década de hospedagem, licenciamento, manutenção e eventual substituição que se segue. Líderes que tratam a arquitetura como "algo de que a equipe técnica cuida" estão delegando alguns dos maiores e mais duradouros compromissos financeiros que a organização assume. Este tópico foi escrito para que você consiga cobrar essas decisões sem ser engenheiro.

Conceitos centrais#

A arquitetura corporativa é a disciplina de alinhar os processos de negócio, a informação, as aplicações e a tecnologia de uma organização para que sustentem a estratégia de forma coerente, em vez de crescer por acidente. Adota a visão da organização inteira: de que capacidades você precisa, que sistemas as oferecem e onde estão as lacunas e as duplicidades. A arquitetura de soluções é a disciplina mais estreita, em nível de projeto, de desenhar como um serviço específico será construído e se encaixará no parque mais amplo. Ambas se situam dentro da ideia mais ampla de arquitetura de sistemas — o modelo estrutural de como componentes, interfaces e comportamentos se combinam num todo funcional. Os líderes não precisam praticar essas disciplinas, mas devem insistir que existam, porque a ausência delas é como os parques se tornam ingerenciáveis.

A arquitetura é guiada por princípios de arquitetura: um conjunto curto e acordado de declarações — como "reutilizar antes de comprar, comprar antes de construir" ou "construir sobre padrões abertos" — que tornam possíveis decisões consistentes sem que cada escolha seja escalada. Os princípios são impostos, com leveza, por uma autoridade de design: um pequeno grupo que revisa as decisões técnicas significativas. A versão saudável de uma autoridade de design viabiliza em vez de bloquear; existe para evitar dano e duplicidade evitáveis, e não para retardar as equipes nem para controlar o acesso por si mesma.

A computação em nuvem é a entrega de computação — servidores, armazenamento, bancos de dados, redes — como um serviço sob demanda pela internet, em vez de a partir de equipamentos que você possui no próprio prédio. Uma nuvem pública é operada por um provedor terceiro e compartilhada entre muitos clientes; uma nuvem privada é dedicada a uma organização; uma nuvem híbrida combina as duas, muitas vezes mantendo algumas cargas de trabalho na infraestrutura existente enquanto move outras para fora. Muitos governos, inclusive o do Reino Unido, adotaram uma política de "nuvem primeiro", o que significa que as equipes devem considerar a nuvem pública antes de outras opções e justificar a não utilização. Como a nuvem é cobrada por consumo, e não comprada uma vez, controlar esse gasto tornou-se uma disciplina própria — FinOps, a prática de unir engenharia e finanças para que as equipes tenham visibilidade e responsabilidade pelo que o seu uso de nuvem de fato custa. Na camada de aplicação, o software como serviço (SaaS) entrega uma aplicação pronta pela web, que o fornecedor hospeda e mantém, de modo que você a configura em vez de operá-la. A infraestrutura e a hospedagem — onde e como os seus sistemas rodam fisicamente — ficam por baixo de tudo isso e carregam cada vez mais um custo de carbono que pertence à decisão (ver Tópico 8.5 — Sustentabilidade e emissões líquidas zero).

Um sistema legado é um sistema envelhecido, mas ainda usado, difícil de mudar, que muitas vezes roda software sem suporte, para o qual não se emitem mais correções de segurança. O legado se acumula como dívida técnica — o custo futuro de escolhas expeditas feitas no passado. Um pouco de dívida é normal e até sensato; a dívida não gerida em escala vira um passivo de segurança, porque os sistemas de que a maioria das pessoas depende se tornam os sistemas em que ninguém ousa mexer. Gerir isso é o trabalho da gestão do portfólio de aplicações: manter um inventário claro de cada aplicação, seu custo, condição e valor de negócio, para racionalizar o parque — aposentando, substituindo ou consolidando sistemas — e descomissionar com segurança, em vez de deixar o velho rodando em silêncio.

Os parques modernos são mantidos unidos por interfaces de programação de aplicações (APIs): interfaces definidas pelas quais um sistema oferece uma capacidade a outro. APIs bem projetadas permitem montar plataformas — serviços reutilizáveis sobre os quais muitas equipes constroem — mantendo os componentes fracamente acoplados e substituíveis. Uma disciplina útil aqui é a "plataforma mínima viável": construir apenas a capacidade compartilhada que genuinamente reduz o trabalho dos outros, e nada além. Sustentando o projeto seguro está o princípio de segurança desde a concepção (secure by design), segundo o qual a segurança é embutida desde o início, e não acrescentada depois. E o quadro financeiro de tudo isso é o custo total de propriedade (TCO): o custo completo ao longo da vida de um sistema, e não o seu preço de compra — a lente pela qual a escolha entre construir, comprar ou configurar, e o risco de dependência de fornecedor (vendor lock-in), devem ser julgados.

Boas práticas#

1. Acorde um conjunto curto de princípios de arquitetura e use-os para decidir. Escreva um punhado de princípios claros e memoráveis — reutilizar antes de comprar antes de construir, construir sobre padrões abertos, nuvem onde fizer sentido, segurança desde a concepção, projetar para toda a via de cuidado — e deixe as equipes tomarem a maioria das decisões elas mesmas, aplicando-os. Os princípios só funcionam se forem genuinamente usados para dizer sim e não, e só se forem poucos o bastante para serem lembrados. Isso se liga diretamente ao Tópico 1.1 — O modelo operacional e ao Tópico 1.2 — Estratégia digital e roteiro, que definem a direção a que os princípios servem.

2. Conduza uma autoridade de design que viabilize em vez de bloquear. Estabeleça um pequeno grupo sênior e multidisciplinar para revisar as decisões técnicas significativas — as caras, difíceis de reverter, que afetam muitos serviços ou carregam risco de segurança clínica e de proteção. Dê-lhe uma via rápida e leve, para que as escolhas rotineiras não sejam arrastadas por ele, e submeta-o a um padrão de serviço: deve ajudar as equipes a encontrar uma boa resposta, e não simplesmente recusar. Uma autoridade de design que vira gargalo será contornada, e a arquitetura paralela é pior do que nenhuma.

3. Adote a nuvem deliberadamente, carga de trabalho por carga de trabalho, e não como slogan. Trate o "nuvem primeiro" como um padrão a ser raciocinado, e não como uma instrução de mover tudo. Avalie cada carga de trabalho quanto à adequação, residência dos dados, resiliência, custo em escala e esforço de migração e seja honesto de que o lift-and-shift de uma aplicação legada inalterada muitas vezes apenas desloca o problema a um custo maior. Pese explicitamente a dimensão do carbono, já que onde e como você hospeda afeta as emissões (ver Tópico 8.5 — Sustentabilidade e emissões líquidas zero), e projete para a portabilidade, de modo que uma futura mudança entre provedores continue possível.

4. Mantenha um portfólio de aplicações vivo e gerencie a dívida técnica como um risco nomeado. Mantenha um inventário preciso de cada aplicação, seu dono de negócio, custo, sustentabilidade de suporte e o risco que carrega e revise-o regularmente. Ponha a dívida técnica e o software sem suporte no registro de riscos corporativo com a mesma seriedade do risco clínico ou financeiro, porque é isso que ela é. O que você não vê, não consegue financiar, priorizar nem aposentar com segurança, e os parques que nunca são inventariados são exatamente os que falham sem aviso.

5. Racionalize o parque e descomissione com segurança. Aposente ativamente os sistemas duplicados, obsoletos e em fim de vida, em vez de deixá-los permanecer "por via das dúvidas", porque todo sistema ativo é uma superfície de ataque, um custo de licença e um fardo de manutenção. A desativação é um projeto por si só: migre ou arquive os dados sob regras claras de retenção, confirme que nada mais depende do sistema, comunique-se com os usuários e verifique antes de desligar. Bem feita, a racionalização libera dinheiro e reduz o risco; feita sem cuidado, destrói registros ou quebra uma dependência que ninguém documentou.

6. Prefira padrões abertos, APIs e componentes fracamente acoplados. Projete de modo que as capacidades sejam expostas por APIs documentadas e versionadas, para que um componente possa ser substituído sem reconstruir tudo em torno dele. Esta é a base arquitetural para a interoperabilidade discutida no Tópico 4.3 — Interoperabilidade e padrões de dados e a sua principal defesa contra a dependência de fornecedor. Custa um pouco mais de início do que uma conexão direta, rígida, e se paga muitas vezes na primeira vez em que você precisar trocar de fornecedor ou acrescentar um serviço.

7. Construa a plataforma mínima viável, e nada além. Quando criar uma plataforma compartilhada para outros construírem por cima, resista ao impulso de torná-la abrangente desde o primeiro dia. Ofereça a menor capacidade reutilizável que genuinamente remova trabalho das equipes, prove que é usada e faça-a crescer em resposta à demanda real. As plataformas superconstruídas se tornam o seu próprio legado — caras, rígidas e ressentidas —, ao passo que uma plataforma fina e bem operada conquista adoção e evolui com a necessidade.

8. Torne inegociáveis a arquitetura de segurança e a segurança desde a concepção. Traga o pensamento de segurança para o projeto desde o primeiro esboço, e não como uma barreira de pré-lançamento: minimize a superfície de ataque, aplique o menor privilégio, segmente as redes e presuma que os componentes serão sondados. Na saúde e nos cuidados, isso é indissociável da segurança clínica e da governança da informação (Tópico 1.6 — Segurança clínica e gestão de riscos; Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança), porque uma violação é, ao mesmo tempo, um dano de dados e, quando para os sistemas, um evento de segurança do paciente. O software sem suporte e sem possibilidade de correção é uma decisão de segurança que você está tomando por omissão — então tome-a deliberadamente, com mitigações, ou não a tome.

9. Decida construir, comprar ou configurar com base no custo total de propriedade, e não no preço de etiqueta. Para cada capacidade, compare construir sob medida, comprar um produto e configurar uma plataforma existente pelo seu custo completo ao longo da vida — hospedagem, licenciamento, integração, suporte, atualizações e eventual saída — e não pelo preço inicial. Favoreça comprar ou configurar para necessidades de commodity e reserve a construção para a diferenciação genuína e pese a dependência que cada opção cria. Trabalhe isso com colegas comerciais (Tópico 6.3 — Aquisições e contratações), porque o momento mais barato de garantir interfaces abertas e direitos de saída é antes de assinar.

10. Trate o gasto com nuvem como uma disciplina conjunta de engenharia e finanças (FinOps). Dê às equipes visibilidade clara do que seus serviços custam, etiquetando os recursos de nuvem aos responsáveis, dimensionando as instâncias conforme o uso real e desligando recursos ociosos ou superdimensionados em vez de pagar por eles mês após mês. Faça as equipes que operam um serviço responderem pelo seu custo de operação, para que as pessoas mais bem posicionadas para reduzir o desperdício sejam as que veem a conta. A nuvem paga por uso sem essa disciplina consome em silêncio um orçamento que deveria financiar o cuidado, e a deriva raramente é notada até que uma fatura force a pergunta.

11. Arquitete o custo como um requisito não funcional de primeira ordem, ponderado frente ao carbono e à resiliência. Trate o custo como você trata o desempenho, a segurança e a disponibilidade: uma propriedade para a qual você projeta deliberadamente, que estima antes de construir e revê à medida que o uso cresce. Pese-o explicitamente frente ao carbono (ver Tópico 8.5 — Sustentabilidade e emissões líquidas zero) e à resiliência, porque os três muitas vezes se movem juntos — mas nunca persiga a menor conta à custa da segurança, da recuperabilidade ou dos desfechos dos pacientes. A resposta certa é o menor custo que ainda cumpra as suas obrigações de segurança clínica e de resiliência, e não a opção mais barata isoladamente.

Perguntas para discutir com a sua equipe#

1. Quais dos nossos sistemas críticos hoje não têm suporte ou não podem receber correções, e qual é a nossa exposição real se um for atacado ou falhar? Partam dos sistemas sem os quais os serviços clínicos e operacionais genuinamente não conseguem funcionar e estabeleçam de forma concreta quais rodam software que não recebe mais atualizações de segurança nem suporte do fornecedor. Perguntem o que aconteceria — com pacientes, equipe e dados — se cada um fosse atingido por ransomware ou simplesmente parasse e quanto tempo a recuperação levaria. Distingam os sistemas sobre os quais vocês aceitaram conscientemente o risco, com mitigações em vigor, daqueles cuja fragilidade ninguém avaliou. Considerem se essa exposição é visível no registro de riscos corporativo ou enterrada numa planilha que nenhum conselho viu. Reflitam sobre o WannaCry: o dano não veio da sofisticação, mas de dívida conhecida e não tratada em sistemas críticos. Se vocês não conseguem responder a isso com evidências, essa lacuna é, em si, o seu achado mais urgente, porque não se financia um risco que não foi nomeado.

2. Onde estamos presos a fornecedores, e quanto realmente nos custaria deixar a nossa maior plataforma? Muitas organizações descobrem o preço real de um sistema fechado apenas quando tentam mudá-lo. Percorram o que seria preciso para sair da sua maior plataforma clínica ou corporativa: se vocês conseguem extrair os dados de forma utilizável e padrão, que interfaces proprietárias teriam de ser desfeitas e o que diz o contrato sobre propriedade e saída. Considerem se a "nuvem" silenciosamente virou uma dependência de outro tipo, com dados e ferramentas tão emaranhados num provedor que sair é impraticável. Pesem isso frente à abertura das alternativas e a quaisquer plataformas nacionais que vocês poderiam reutilizar. Não é um argumento para trocar de fornecedor a toda hora; trata-se de entender sua alavancagem antes da próxima negociação e de não deixar o roteiro de um fornecedor virar silenciosamente sua única opção.

3. Estamos investindo o suficiente em manter e racionalizar o que já temos, ou apenas no novo e visível? Os sistemas novos atraem financiamento e atenção; o trabalho pouco glamoroso de corrigir, atualizar, consolidar e aposentar com segurança raramente atrai, e é exatamente assim que a dívida se acumula. Perguntem que proporção do seu orçamento digital realmente vai para manter o parque existente seguro e atual versus construir coisas novas e se alguém é dono desse equilíbrio de forma deliberada. Discutam se a desativação alguma vez recebe recursos adequados ou se os sistemas antigos simplesmente permanecem porque desligá-los não é trabalho de ninguém. Considerem as aplicações duplicadas que fazem a mesma coisa pela organização e o que seria preciso para consolidá-las. Pensem em quem, em nível de conselho, responde pela saúde do parque como um todo, e não por projetos individuais. Uma organização que só financia o novo está tomando emprestado contra a sua própria segurança futura, e o pagamento sempre vence no pior momento possível.

4. Nós de fato sabemos quanto custa a nossa nuvem, quem é dono dessa conta e se o gasto está sob controle? A nuvem paga por uso pode consumir em silêncio um orçamento que deveria financiar o cuidado, e a deriva raramente é notada até que uma fatura force a pergunta. Perguntem se os recursos de nuvem estão etiquetados às equipes e serviços que os possuem, se alguém dimensiona as instâncias conforme o uso real e se os recursos ociosos ou superdimensionados alguma vez são desligados. Discutam se as pessoas que operam um serviço veem e respondem pelo seu custo de operação ou se o gasto com nuvem cai como uma única linha inexplicada num orçamento central que ninguém consegue decompor. Considerem se o custo é tratado como um requisito não funcional de primeira ordem — estimado antes de construir e revisto à medida que o uso cresce — ou apenas descoberto depois do fato. Sejam honestos sobre a tensão entre autonomia da engenharia e controle financeiro e sobre ponderar o custo frente ao carbono e à resiliência em vez de simplesmente perseguir a menor conta. Uma resposta honesta nomeia quem detém a disciplina de FinOps e mostra a evidência de que ela está funcionando, em vez de supor que a nuvem é mais barata por ser moderna.

5. Quando precisamos de uma nova capacidade, como decidimos entre construí-la, comprá-la e configurar algo que já temos — e com que base? O instinto de construir sob medida, ou de comprar o produto com a melhor demonstração, muitas vezes vence antes de alguém comparar o custo completo ao longo da vida. Percorram como as suas últimas escolhas significativas foram de fato feitas: se hospedagem, licenciamento, integração, suporte, atualizações e eventual saída foram ponderados, ou apenas o preço inicial. Perguntem se vocês reservam a construção para a diferenciação genuína e adotam por padrão comprar ou configurar para necessidades de commodity, ou se construções sob medida proliferam em silêncio porque uma equipe as preferiu. Considerem quem está na sala para essas decisões — colegas comerciais e clínicos, além dos engenheiros — e se a dependência que cada opção cria é avaliada antes de assinar, e não descoberta depois. Reflitam sobre se os seus princípios de arquitetura ("reutilizar antes de comprar, comprar antes de construir") de fato obrigam essas escolhas ou são silenciosamente ignorados. Uma resposta honesta consegue apontar decisões reais em que o custo total de propriedade, e não o preço de etiqueta, mudou o resultado.

6. Temos a capacidade interna de arquitetura para sustentar nossas próprias decisões, ou dependemos dos fornecedores que deveríamos estar cobrando? A arquitetura é onde os maiores e mais duradouros compromissos são assumidos, e, no entanto, muitas organizações esvaziaram a própria capacidade necessária para tomá-los bem, apoiando-se nos fornecedores cujos produtos estão em avaliação para lhes dizer o que é bom. Perguntem se vocês têm competência crível de arquitetura corporativa e de soluções do seu lado e se a sua autoridade de design é dimensionada para viabilizar as equipes ou apenas para carimbar. Discutam se as decisões significativas e difíceis de reverter são genuinamente testadas frente a princípios acordados ou se são, na prática, delegadas a qualquer fornecedor que esteja mais perto do problema. Considerem como vocês sequer reconheceriam uma má recomendação arquitetural se não tivessem expertise independente para questioná-la. Pesem o custo de construir e reter essa capacidade frente ao custo muito maior da dependência e do retrabalho que a sua ausência produz. Uma resposta honesta distingue as decisões que vocês podem genuinamente possuir das que hoje tomam na confiança.

Na prática: um exemplo de saúde e cuidados#

O parque técnico de um hospital de agudos cresceu de forma orgânica por duas décadas. No coração dele está um sistema de administração de pacientes rodando num sistema operacional que o fornecedor deixou de suportar há dezoito meses; ao redor, mais de duzentas aplicações, muitas compradas por departamentos, várias com funções sobrepostas, e ninguém detém uma lista completa. Um quase-acidente — uma tentativa de ransomware bloqueada mais por sorte do que por projeto — leva o conselho a fazer uma pergunta que nunca havia feito: o que, exatamente, estamos operando e quão expostos estamos?

O diretor de informação digital resiste ao instinto de lançar um único e heroico programa de "substituir tudo" e faz primeiro o trabalho enfadonho. O hospital constrói um portfólio de aplicações vivo: cada sistema, seu dono de negócio, sua sustentabilidade de suporte, seu custo e seu risco. O retrato é sóbrio — um quinto das aplicações roda em software sem suporte e uma dúzia duplica capacidades já disponíveis em outro lugar —, mas, pela primeira vez, é visível, e as piores exposições vão direto para o registro de riscos corporativo, onde o conselho as vê.

A partir desse inventário, o hospital faz escolhas deliberadas, guiado por um punhado de princípios de arquitetura acordados. O sistema de administração de pacientes sem suporte é priorizado para substituição, adquirido como um produto configurável, com direitos contratuais de API aberta e de extração de dados, para que o hospital não fique preso de novo. Cargas de trabalho adequadas vão para a nuvem pública, avaliadas uma a uma e não por slogan, com carbono e portabilidade pesados ao lado do custo. Uma pequena autoridade de design revisa as decisões significativas e libera as rotineiras rapidamente. Doze aplicações departamentais sobrepostas são consolidadas em três, e os sistemas aposentados são desativados corretamente — dados migrados sob regras claras de retenção, dependências verificadas, usuários avisados e só então desligados.

Nada disso vira manchete. Mas, dezoito meses depois, o hospital sabe o que opera, sua dívida mais perigosa está sendo quitada num plano financiado, em vez de esperada, e uma nova integração de prontuário de cuidados compartilhado é entregue em semanas porque os sistemas substitutos expõem APIs abertas. O quase-acidente virou o momento em que o hospital passou a gerir a sua arquitetura, em vez de ser gerido por ela.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital tem o luxo de pouco legado e deve protegê-lo ferozmente. Construa nativo em nuvem desde o início, exponha APIs abertas e trate a segurança desde a concepção como uma funcionalidade central, e não um custo posterior, porque compradores cautelosos do NHS escrutinarão de perto a sua arquitetura de segurança e os termos de extração de dados. Mantenha a sua própria plataforma mínima viável genuinamente mínima, resistindo à tentação de superprojetar para uma escala que você ainda não tem. Sua via mais rápida para acumular dívida técnica paralisante é entregar código expedito sob pressão de investidores e nunca quitá-lo; por isso, faça escolhas deliberadas e visíveis sobre que dívida assumir. Paradoxalmente, projetar de modo que um cliente possa extrair seus dados e ir embora é o que conquista a confiança que o mantém.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase de startup — carrega os mesmos deveres de um grande hospital, com uma fração dos recursos e raramente alguma capacidade de TI dedicada. Aqui a arquitetura é sobretudo a disciplina de comprar bem: favoreça software como serviço de boa reputação, para que o fornecedor carregue a hospedagem, as correções e a segurança que você não consegue dotar de pessoal, e leia o contrato quanto a direitos de extração de dados e de saída antes de assinar, porque a dependência pica mais forte quando você não tem alavancagem. Mantenha um inventário simples dos poucos sistemas dos quais depende e saiba quais ainda têm suporte, já que mesmo um parque pequeno pode esconder uma máquina sem correções que para o consultório. Insista que os fornecedores cumpram padrões reconhecidos, como o Data Security and Protection Toolkit, em vez de tentar avaliar a segurança do zero. Quando o caixa é apertado, a tentação é manter funcionando um sistema antigo e sem suporte para evitar uma conta, mas essa é uma decisão de segurança que você deve tomar deliberadamente, e não à deriva.

Grande organização#

Um grande hospital ou fornecedor carrega décadas de sistemas acumulados e não pode simplesmente recomeçar. A estratégia realista é a evolução disciplinada: manter um portfólio vivo, pôr camadas abertas baseadas em API na frente do que precisa ficar e quitar a dívida mais perigosa num plano financiado e priorizado, em vez de em pânicos ocasionais. Conduza uma autoridade de design que seja respeitada porque viabiliza a entrega, e não temida porque a bloqueia, e faça da dívida técnica um risco permanente em nível de conselho, com um responsável nomeado. Proteja-se da dependência de fornecedor em cada renovação e trate a desativação como trabalho real e provido de recursos, e não uma reflexão tardia. É a mesma disciplina de reutilização e de interface aberta que governa as plataformas operacionais centrais do Tópico 5.4 — Planejamento de recursos empresariais (ERP).

Governo#

Os órgãos nacionais e regionais definem as condições em que todo o setor opera, e suas escolhas de arquitetura se propagam para fora. As coisas mais valiosas que o governo pode fazer são tornar obrigatórios os padrões abertos, oferecer plataformas nacionais reutilizáveis para que as organizações locais construam uma só vez e definir expectativas de nuvem, segurança e sustentabilidade que elevem o piso em toda parte. De forma crucial, o governo deve financiar o trabalho nacional pouco glamoroso — remediação do legado, manutenção da terminologia, apoio à desativação — que nenhuma organização isolada financiará sozinha, mas do qual todas dependem. Um padrão bom o bastante, firmemente imposto e amplamente reutilizado, vence um teoricamente superior implementado de forma inconsistente. Esse papel de zelo se liga ao Tópico 9.1 — Trabalho com governos locais e nacionais e a como os parceiros colaboram no Tópico 9.0 — Colaboração com organizações parceiras.

Modos de falha comuns#

• Parque invisível. Operar centenas de aplicações sem inventário preciso, de modo que a exposição é desconhecida, a duplicidade passa despercebida e o primeiro sinal de fragilidade é uma indisponibilidade ou uma violação.
• Dívida escondida do conselho. Manter o software sem suporte e a dívida técnica como nota de rodapé técnica, e não como risco corporativo nomeado, de modo que nunca é financiada até falhar.
• Nuvem como slogan. Fazer lift-and-shift do legado inalterado para a nuvem pública por princípio, deslocando o problema a um custo maior, ou emaranhando dados e ferramentas num único provedor a ponto de virar uma nova dependência.
• Autoridade de design como gargalo. Deixar a governança de arquitetura virar uma barreira lenta que as equipes contornam, produzindo arquitetura paralela não documentada, pior do que nenhuma.
• Construir quando se deveria configurar. Escolher construções sob medida para necessidades de commodity, com base no preço de etiqueta e não no custo total de propriedade, e herdar uma década de manutenção não orçada.
• Nunca descomissionar. Deixar sistemas obsoletos rodando "por via das dúvidas", cada um uma superfície de ataque, um custo de licença e um dreno de manutenção de que ninguém é dono.
• Segurança acrescentada depois. Tratar a segurança como barreira de pré-lançamento e não como insumo de projeto, de modo que a superfície de ataque é fixada muito antes de alguém avaliá-la.
• Dependência por padrão. Assinar plataformas sem interfaces abertas nem direitos de extração de dados e descobrir o custo da armadilha só quando se tenta sair.

Modelo de maturidade#

Lista de verificação#

• Um portfólio de aplicações vivo registra o responsável, o custo, a sustentabilidade de suporte e o risco de cada sistema e é revisto regularmente.
• Os sistemas críticos sem suporte e sem possibilidade de correção estão identificados e constam do registro de riscos corporativo, e não de uma planilha técnica.
• Um conjunto curto e acordado de princípios de arquitetura é genuinamente usado para tomar e justificar decisões.
• Uma autoridade de design revisa decisões significativas e difíceis de reverter e libera as rotineiras rapidamente, viabilizando em vez de bloquear.
• A adoção da nuvem é avaliada carga a carga, ponderando residência, resiliência, custo, portabilidade e carbono.
• A dívida técnica tem um responsável nomeado e um plano de remediação financiado, e não apenas apagar incêndios ocasional.
• Os sistemas duplicados e obsoletos são racionalizados, e a desativação tem recursos para migração de dados, retenção e verificação de dependências.
• As novas capacidades expõem APIs abertas e versionadas, para que os componentes possam ser substituídos sem reconstruir tudo em torno deles.
• A segurança é projetada desde o início — superfície de ataque mínima, menor privilégio, segmentação — e não acrescentada antes do lançamento.
• As decisões de construir/comprar/configurar são tomadas com base no custo total de propriedade e na dependência, com direitos de saída e de extração de dados garantidos antes de assinar.

Fontes-chave#

• NHS England — estratégia de nuvem, padrões de tecnologia e o Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — princípios de projeto seguro e orientações de segurança em nuvem.
• Governo do Reino Unido (GDS/CDDO) — o Technology Code of Practice e a política de nuvem primeiro.
• National Audit Office — relatórios sobre sistemas legados do NHS, o ataque WannaCry e programas habilitados por TI.
• The Open Group — TOGAF, o arcabouço de arquitetura corporativa.
• Government Digital Service — o conceito de "plataforma mínima viável" no GOV.UK service manual e na comunidade de design.

Referências#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual