Engenharia de software e plataformas no setor público

Por que razão isto importa para o valor público

Quase todos os serviços públicos que um cidadão toca hoje — registar um nascimento, pedir uma prestação, pagar uma fatura de impostos, marcar uma data em tribunal — funcionam com software nalgum lugar por trás do balcão ou do ecrã. Esse software raramente é uma compra pontual; torna-se parte da infraestrutura permanente do Estado, muitas vezes sobrevivendo à administração que o encomendou, ao fornecedor que o construiu e à linguagem de programação em que os seus engenheiros foram formados. Um organismo público não vive o software da forma como vive um edifício ou uma estrada, em que o estado do ativo é visível; o software degrada-se invisivelmente, e a fatura dessa degradação chega anos depois sob a forma de uma emergência.

A tensão que move este tópico é estrutural. O software é inerentemente iterativo — os requisitos tornam-se mais claros à medida que os utilizadores interagem com um sistema funcional, e a melhor prática de engenharia é construir algo pequeno, aprender e adaptar. Os ciclos de contratação e de responsabilização públicas (ver Tópico 3.7 — Contratação pública e contratualização), por contraste, foram construídos para obras de capital e contratos de defesa: uma especificação fixa, uma única grande adjudicação, pagamentos por marcos e um caso de negócio aprovado anos antes de a entrega começar. Quando uma legislatura ou um auditor espera um contrato de preço fixo e âmbito fixo e uma equipa de engenharia precisa de mudar de rumo depois do primeiro lançamento, a discrepância manifesta-se em deriva de âmbito, derrapagem orçamental ou num sistema corretamente especificado em 2019 e obsoleto quando chega.

As plataformas que a prática de engenharia deste tópico existe para construir — sistemas partilhados de identidade, circuitos de pagamento, ferramentas de gestão de processos reutilizadas entre departamentos — são o tema do Tópico 5.1 (ver Tópico 5.1 — Governo digital e transformação digital); este tópico trata da disciplina de construir e adquirir o software que torna qualquer dessas plataformas, ou qualquer serviço isolado, fiável, substituível e detido pelo organismo público que dele depende e não por qualquer fornecedor que por acaso o tenha escrito primeiro.

Conceitos fundamentais

A decisão de construir ou comprar é a escolha entre encomendar software à medida escrito para a necessidade de uma organização e adotar software comercial configurável já construído para um mercado de compradores semelhantes. Comprar é normalmente mais barato e de menor risco para uma necessidade que não é genuinamente distintiva — processamento salarial, correio eletrónico, gestão de processos corrente — enquanto construir só se justifica quando o requisito é suficientemente diferente para que nenhum produto configurável se ajuste, ou quando a capacidade é em si mesma um ativo estratégico que a organização precisa de deter e fazer evoluir.

A dívida técnica é uma metáfora, cunhada pelo engenheiro de software Ward Cunningham em 1992, para o custo acumulado de escolher uma forma expedita de entregar software agora em vez de uma forma mais minuciosa que teria demorado mais. A dívida técnica, tal como a dívida financeira, não é inerentemente errada de contrair — o próprio ponto de Cunningham era que entregar depressa código funcional e refatorá-lo depois pode ser a decisão certa — mas a dívida que nunca é paga acumula juros sob a forma de entrega mais lenta, mais defeitos e risco crescente, e um organismo público que não vê a sua dívida não consegue decidir se a deve amortizar ou deixar que se acumule.

Um sistema legado é uma tecnologia, aplicação ou plataforma antiga que continua em uso ativo apesar de desatualizada, muitas vezes porque substituí-la é caro ou porque ninguém que reste na organização compreende por inteiro o que ela faz. Os sistemas legados são especialmente persistentes no governo: os sistemas centrais de impostos, prestações e segurança social escritos há décadas em linguagens como o COBOL — a Common Business-Oriented Language, concebida em 1960 para computação administrativa — continuam a processar transações para milhões de cidadãos, porque os sistemas funcionam e o conhecimento institucional necessário para os retirar em segurança já se reformou, muitas vezes, antes deles.

A modernização de software é o termo geral para converter, reescrever ou migrar um sistema legado para uma arquitetura, linguagem ou plataforma atual. A modernização de software abrange um espectro desde uma reescrita completa até opções mais conservadoras, como realojar o mesmo código em infraestrutura moderna, e a escolha entre elas é tanto uma decisão de gestão de riscos como técnica.

O padrão da figueira-estranguladora (strangler fig) é uma abordagem de modernização incremental, com o nome de uma trepadeira que cresce em torno de uma árvore hospedeira e gradualmente a substitui, em que a nova funcionalidade é construída ao lado de um sistema legado e o tráfego é redirecionado para ela aos poucos, em vez de substituir todo o sistema numa única passagem. O padrão da figueira-estranguladora importa porque permite que cada incremento seja testado, revertido ou suspenso sem deitar abaixo todo o serviço — o oposto de uma substituição big-bang, em que o sistema antigo é desligado e o novo ligado num único momento sem retorno se algo estiver errado.

A dependência de fornecedor (vendor lock-in) ocorre quando um cliente fica tão dependente da tecnologia proprietária, dos formatos de dados ou das condições contratuais de um fornecedor que a mudança para outro fornecedor acarreta um custo ou risco proibitivo. A dependência de fornecedor é um perigo particular no software do setor público porque o comprador é um cliente repetido com capacidade prática limitada de se afastar de um sistema que sustenta um serviço crítico, o que enfraquece a sua posição negocial em cada renovação subsequente.

O software livre e de código aberto é software distribuído sob uma licença que concede aos utilizadores a liberdade de usar, estudar, modificar e redistribuir o código-fonte. O software livre e de código aberto sustenta uma política de código aberto por defeito, ao abrigo da qual um organismo público tem por norma publicar o código-fonte que encomenda, a menos que uma razão específica — sensibilidade de segurança, direitos de terceiros — justifique retê-lo; a fundamentação resume-se habitualmente em «dinheiro público, código público»: o software pago uma vez com fundos públicos não deve precisar de ser pago de novo, noutra jurisdição, por outro organismo público que resolve o mesmo problema.

Um bem público digital é software, dados ou conteúdo aberto, divulgado sob uma licença aberta, concebido para ajudar a satisfazer um objetivo público de desenvolvimento ou de governação e não para gerar retorno comercial. Os bens públicos digitais reenquadram a divulgação em código aberto de um governo como parte de uma infraestrutura partilhada mais ampla a que outros governos e organizações da sociedade civil podem recorrer diretamente, e não apenas um gesto de transparência interna.

O desenvolvimento ágil de software é um termo-chapéu para abordagens iterativas à construção de software que favorecem o software funcional, a entrega frequente e a resposta à mudança em vez do cumprimento de um plano fixo acordado de antemão. O desenvolvimento ágil de software contrasta com o modelo em cascata (waterfall), uma abordagem sequencial em que os requisitos, a conceção, a construção e os testes se completam cada um por inteiro antes de o seguinte começar; o atrativo do modelo em cascata para os organismos públicos sempre foi que os seus marcos se ajustam bem a um contrato de preço fixo e a um ciclo orçamental anual, razão pela qual tanto direito da contratação continua a presumi-lo, mesmo quando a entrega é genuinamente ágil.

Um produto mínimo viável é a menor versão de um serviço que pode ser lançada a utilizadores reais para testar se funciona e aprender o que construir a seguir. O conceito de produto mínimo viável, adaptado aos guias de serviços digitais do setor público, dá a uma equipa iterativa uma forma defensável de mostrar a um financiador ou auditor algo real e funcional muito antes de o âmbito completo estar concluído — desde que o processo de responsabilização aceite um lançamento genuinamente mínimo e não o trate como o produto acabado sob outro nome.

Boas práticas

1. Recorra por defeito à compra para as necessidades indiferenciadas, e reserve a construção para o que é genuinamente distintivo. O processamento salarial, o correio eletrónico e as necessidades gerais de gestão de processos raramente são suficientemente diferentes das de qualquer outra organização para justificar software à medida; construa apenas quando o requisito, a escala ou a necessidade de deter e fazer evoluir a capacidade ao longo de décadas for genuinamente diferente do que o mercado oferece.
2. Torne visível a dívida técnica antes de decidir quanta carregar. Mantenha um registo dos atalhos conhecidos, das correções adiadas e das dependências sem suporte de cada sistema em serviço, revisto num ciclo fixo, de modo que carregar dívida mais um ano seja um compromisso deliberado e não ninguém a olhar.
3. Nunca planeie uma única passagem irreversível como o único caminho para sair de um sistema legado crítico. Prefira abordagens incrementais como o padrão da figueira-estranguladora, que permitem testar, reverter e implantar gradualmente cada peça; a substituição big-bang de um sistema de que milhões dependem concentra anos de risco num único fim de semana sem retorno se algo falhar.
4. Trate o código-fonte que a sua organização paga para ser escrito como um ativo que possui, e não um serviço que aluga. Negoceie o depósito do código-fonte em escrow ou a propriedade plena no momento da contratação, e não depois de um litígio ter começado, uma vez que um fornecedor que detém a única cópia do código do seu serviço crítico é dependência de fornecedor por construção.
5. Publique o código-fonte como aberto por defeito, e exija uma justificação específica para o reter. Uma política de código aberto por defeito, aplicada de forma consistente, transforma o software à medida de cada departamento num ativo partilhado de todo o governo e não num custo pontual, e permite a peritos externos encontrar falhas de segurança que uma equipa interna só perderia.
6. Redija contratos de software que tornem juridicamente possível a entrega iterativa, e não apenas tecnicamente possível. Um contrato que paga apenas face a uma especificação fixa acordada na assinatura força uma equipa a escolher entre a prática ágil honesta e o cumprimento contratual; use, em vez disso, barreiras de financiamento faseadas ligadas ao software funcional demonstrado, em vez de um só marco no fim.
7. Financie a modernização como programa contínuo, e não como projeto de capital pontual. Um sistema legado modernizado uma vez e depois deixado durante outros vinte anos acumula o mesmo risco com que começou; orce uma renovação contínua e incremental da forma como uma autoridade rodoviária orça o repavimento, e não uma grande substituição uma vez por geração.
8. Escolha normas abertas e formatos de dados portáteis mesmo ao comprar software comercial. Exigir que o sistema de um fornecedor armazene e exporte dados em formatos abertos e documentados mantém baixos os custos de mudança mesmo quando o software em si é proprietário, e é muitas vezes uma salvaguarda de curto prazo mais exequível contra a dependência do que insistir em que todos os sistemas sejam de código aberto.
9. Construa um produto mínimo viável e mostre-o a utilizadores reais antes de se comprometer com o âmbito completo. Lançar uma versão genuinamente mínima e depois iterar com o que se aprende apanha pressupostos errados enquanto ainda é barato corrigi-los, em vez de depois de um sistema à escala completa ter sido construído contra eles.
10. Mantenha capacidade interna de engenharia suficiente para ser um comprador inteligente, mesmo quando a entrega é contratada. Um organismo público que esvaziou a sua competência técnica não consegue avaliar a proposta de um fornecedor, detetar os sinais precoces de um projeto em dificuldade nem negociar a saída de uma dependência, sejam quais forem as suas regras de contratação no papel.
11. Retire o perfil de risco de um sistema legado antes da sua interface. Priorize a substituição de linguagens sem suporte, infraestrutura sem correções e integrações não documentadas — as falhas que causam interrupções e violações — antes da modernização visual, que acarreta muito menos risco operacional.
12. Meça a saúde da entrega com indicadores de engenharia, e não apenas com a variação de orçamento e de calendário. A frequência das implantações, as taxas de defeitos e a antiguidade do item de dívida técnica mais antigo por tratar dizem a um conselho de governação mais sobre se um programa terá êxito do que saber se está atualmente dentro do orçamento, muitas vezes o último indicador a mexer-se.

Perguntas para discutir com a sua equipa

Sabemos realmente quanta dívida técnica carregamos, sistema a sistema? A maioria dos organismos públicos consegue indicar o seu orçamento de capital do ano mas não consegue dizer, com alguma confiança, que parte do seu parque de software assenta em componentes sem suporte, lógica não documentada ou código que ninguém do pessoal restante compreende por inteiro. Use esta pergunta para pedir a cada responsável de sistema na sala que estime, com honestidade, quão confiante está de que a sua equipa conseguiria alterar em segurança o seu sistema mais crítico sem quebrar algo que ninguém antecipou. Discuta o que seria preciso para transformar essas estimativas num registo efetivo, revisto num ciclo fixo, em vez de conhecimento tácito que sai quando um engenheiro-chave se vai embora. Considere também quem decide atualmente quanta dívida é aceitável carregar e se essa decisão é deliberada ou por omissão.

Se o nosso sistema legado mais crítico tivesse de ser substituído a partir de hoje, estaríamos a planear uma passagem big-bang ou uma migração incremental — e porquê? O instinto de substituir um sistema antigo de uma só vez é muitas vezes impulsionado pelos ciclos orçamentais e pela conveniência da gestão de programas e não pela necessidade técnica, e concentra um enorme risco num único momento. Use esta pergunta para percorrer, concretamente, como seria efetivamente uma migração incremental ao estilo da figueira-estranguladora do seu sistema legado mais crítico, peça a peça. Discuta o que o impede de escolher esse caminho hoje — um financiamento estruturado em torno de uma única data de entrada em funcionamento, um processo de governação que quer um marco limpo, ou um constrangimento técnico genuíno que torna impossível a migração incremental neste sistema.

Quem possui efetivamente o código-fonte do software que a nossa organização pagou para ser construído, e conseguiríamos prová-lo? Muitos organismos públicos descobrem, apenas quando uma relação com um fornecedor azeda, que o contrato nunca assegurou a propriedade clara nem o depósito em escrow do código de que os seus serviços críticos dependem. Use esta pergunta para pegar nos contratos dos seus três sistemas à medida mais importantes e verificar, especificamente, o que cada um diz sobre a propriedade do código, o escrow e o direito de levar o código para outro fornecedor. Discuta o que aconteceria amanhã se o seu principal fornecedor de qualquer desses três sistemas fosse à falência ou se recusasse a continuar a relação.

Onde estamos a recorrer por defeito a software fechado e proprietário por hábito, quando uma abordagem de código aberto por defeito nos serviria igualmente bem ou melhor? As políticas de código aberto por defeito existem precisamente porque a maioria dos organismos públicos resolve problemas sobrepostos de forma independente, cada um pagando o custo integral de software que outro organismo público já construiu e poderia ter partilhado. Use esta pergunta para identificar um sistema que está a ser construído ou especificado e perguntar se já existe um equivalente como software de código aberto noutro ponto do governo, ou se aquele que está a construir poderia utilmente ser divulgado para que outros o reutilizem. Discuta que barreira específica — preocupação de segurança, hábito de contratação, falta de uma política clara — está de facto a impedir essa reutilização, em vez de presumir que não é relevante aqui.

O nosso processo de contratação e de responsabilização permite realmente uma entrega ágil honesta, ou limita-se a rebatizar marcos em cascata como sprints? É comum uma equipa executar cerimónias nominalmente ágeis enquanto continua a ser financiada, governada e reportada face a uma especificação fixa acordada na assinatura do contrato, o que recria todos os modos de falha da cascata sob um rótulo ágil. Use esta pergunta para traçar um programa digital em curso desde o seu caso de negócio até ao seu atual relato de governação e perguntar se a estrutura de financiamento toleraria que o programa mudasse de direção com base no que um genuíno lançamento precoce lhe ensinasse. Discuta o que teria de mudar na forma como o programa é financiado e reportado para que a entrega iterativa seja real e não cosmética (ver Tópico 3.7 — Contratação pública e contratualização).

Temos capacidade interna de engenharia suficiente para ser um comprador inteligente dos sistemas de que mais dependemos? Uma organização que contratou externamente todo o seu juízo técnico, e não apenas a sua capacidade de entrega, não consegue dizer se a proposta de um fornecedor é sólida, se um projeto está discretamente a caminhar para o problema nem qual o preço justo do trabalho. Use esta pergunta para perguntar quantas pessoas da sua organização poderiam rever com credibilidade uma proposta de arquitetura técnica do seu sistema mais importante e como esse número mudou nos últimos cinco anos. Discuta o que seria preciso para reconstruir essa capacidade onde se erodiu e o que a sua organização perde, em posição negocial tanto como em risco de entrega, por cada ano que passa sem ela.

Na prática: um exemplo de valor público

Um governo regional fictício — meramente ilustrativo, não uma descrição de qualquer jurisdição real — processava os pedidos de subsídio de desemprego num sistema escrito pela primeira vez há mais de trinta anos, mantido por um número decrescente de engenheiros que compreendiam a sua linguagem de programação original. O volume de pedidos crescera bastante para além do que os autores do sistema tinham antecipado, as execuções noturnas de processamento falhavam cada vez mais em terminar antes de as transações da manhã começarem e a direção de tecnologia da agência avisava que uma interrupção não planeada que afetasse o pagamento de prestações era agora uma questão de quando e não de se.

O primeiro instinto da agência foi uma resposta convencional a um problema que parecia urgente: encomendar um único grande contrato para substituir todo o sistema por uma plataforma moderna, especificada na íntegra de antemão, entregue contra um calendário fixo de dois anos com uma única passagem de fim de semana no final. Uma revisão pré-implementação encomendada pela comissão de auditoria da agência levantou uma pergunta difícil antes de o contrato ser assinado: o que aconteceria ao pagamento de prestações a várias centenas de milhares de requerentes se o novo sistema tivesse um defeito por descobrir na sua primeira semana de operação plena e em direto, com o sistema antigo já desativado e sem retorno possível.

A agência mudou de rumo. Manteve o sistema legado em funcionamento como sistema de registo e começou a construir funcionalidade nova de receção de pedidos e de avaliação de elegibilidade ao lado dele, usando uma abordagem de figueira-estranguladora: cada novo módulo era lançado primeiro para uma pequena percentagem de novos pedidos, verificado face ao resultado paralelo do sistema antigo e alargado apenas quando os seus resultados coincidiam. Em dezoito meses, a maioria dos novos pedidos corria por componentes modernos enquanto o sistema original tratava uma carteira residual cada vez menor, com a possibilidade de reencaminhar qualquer caso isolado para o caminho antigo se algo parecesse errado. A agência exigiu também, em cada novo contrato emitido para este trabalho, que o código-fonte fosse propriedade da agência e publicado como código aberto assim que a revisão de segurança estivesse concluída, para que outros governos regionais que enfrentavam o mesmo problema do computador central envelhecido pudessem adaptar os componentes em vez de repetir a mesma construção do zero.

A substituição completa das últimas funções residuais do sistema legado demorou perto de quatro anos — mais, no papel, do que o plano original de dois anos big-bang prometia. Mas nenhum requerente experimentou alguma vez uma interrupção não planeada durante a transição, cada incremento era suficientemente pequeno para ser revertido em horas quando se encontrava um defeito e dois governos regionais vizinhos começaram a adaptar o código de avaliação de elegibilidade publicado pela agência para os seus próprios sistemas no primeiro ano após o seu lançamento.

Quatro perspetivas setoriais

Poder local

O governo local gere tipicamente um grande número de sistemas mais pequenos e desligados em vez de um punhado de plataformas à escala nacional, o que significa que a dívida técnica se acumula em muitas aplicações adquiridas e mantidas separadamente e não num só sistema emblemático visível. As autarquias têm normalmente a menor capacidade interna de engenharia de qualquer nível de governo, o que torna especialmente forte o argumento a favor da compra de software comercial configurável em vez de construções à medida, e torna as plataformas regionais ou nacionais partilhadas — o tema do Tópico 5.1 (ver Tópico 5.1 — Governo digital e transformação digital) — uma via particularmente valiosa para evitar que cada autoridade reconstrua separadamente a mesma capacidade.

Governo nacional

O governo nacional é onde tendem a situar-se os sistemas legados mais antigos e mais consequentes — impostos centrais, segurança social e administração de prestações — porque estes estiveram muitas vezes entre os primeiros esforços de informatização em grande escala do governo e carregam agora o que está em jogo mais elevado para qualquer falha de modernização. O governo nacional tem tipicamente a capacidade comercial e de engenharia especializada para conduzir um programa de modernização genuinamente incremental e para negociar nos seus contratos uma verdadeira propriedade do código, e é normalmente o nível de governo mais bem colocado para fixar uma política de código aberto por defeito com escala suficiente para que a reutilização entre governos aconteça realmente.

Setor social e organizações sem fins lucrativos

As organizações sem fins lucrativos e de solidariedade raramente constroem grandes plataformas à medida, mas estão frequentemente do lado de quem recebe o software encomendado ou imposto por um financiador governamental — um portal de relato, um sistema de gestão de processos que uma subvenção ou contrato as obriga a usar — com pouca influência sobre a sua conceção, a sua dívida técnica ou o seu fornecedor. Uma organização do setor social que depende de um sistema imposto pelo governo herda os modos de falha desse sistema sem herdar qualquer alavanca para os corrigir, o que é mais uma razão por que as relações de financiamento baseadas em resultados precisam de ter em conta o encargo operacional da tecnologia imposta (ver Tópico 3.7 — Contratação pública e contratualização), e não apenas a métrica de resultados em si.

Organismos multilaterais e internacionais

Os organismos multilaterais e as agências de desenvolvimento promovem cada vez mais o software construído para a administração pública de um país como bem público digital reutilizável que outros países podem adaptar, em vez de cada governo encomendar um sistema equivalente a um fornecedor privado a custo pleno. O risco distintivo aqui é que um bem público digital construído para o contexto jurídico e administrativo de um país pode ser adotado noutro com demasiado pouca adaptação, importando pressupostos — sobre identidade, elegibilidade ou processo — que na realidade não se transferem; a promessa de uma infraestrutura aberta e partilhada é real, mas apenas quando uma capacidade genuína de adaptação local acompanha o código.

Modos de falha comuns

A passagem big-bang que falha na entrada em funcionamento. Um sistema legado crítico é substituído numa única passagem irreversível após anos de desenvolvimento sem exposição à produção real, e um defeito que só aparece à escala real ou num caso-limite que ninguém testou surge no primeiro dia de operação plena, sem forma de voltar ao sistema antigo porque este já foi desativado. O custo mede-se em pagamentos falhados, serviços negados ou interrupções que afetam exatamente os cidadãos que o sistema existe para servir, no pior momento possível — o momento em que todos contavam com o funcionamento da substituição.

Acumulação silenciosa de dívida técnica. A pressão dos prazos vence repetidamente o argumento do tempo necessário para corrigir atalhos conhecidos, e cada adiamento é individualmente defensável, até que a dívida acumulada torna mesmo uma pequena alteração desproporcionadamente cara e arriscada. O custo surge anos mais tarde sob a forma de um sistema que ninguém consegue modificar em segurança, de uma força de trabalho que discretamente deixou de tentar qualquer coisa que não os remendos mais urgentes e de um eventual programa de modernização muito maior e mais caro do que uma renovação contínua e mais pequena teria sido.

Dependência de fornecedor confundida com estabilidade. Um organismo público renova repetidamente o contrato do mesmo fornecedor porque mudar parece demasiado disruptivo para tentar, sem nunca testar quais seriam os custos reais de mudança nem negociar a propriedade do código e os formatos abertos de dados que manteriam esses custos geríveis. O custo é uma posição negocial permanentemente enfraquecida quanto a preço e condições, descoberta apenas quando a qualidade do serviço do fornecedor diminui ou os seus preços sobem e o organismo público verifica que não tem alternativa credível.

Agilidade cosmética. Uma equipa de entrega adota cerimónias ágeis — reuniões diárias, sprints, um backlog — enquanto o contrato, o financiamento e a estrutura de governação subjacentes continuam a pressupor uma especificação fixa e um único marco de avançar ou não, pelo que a equipa reporta a velocidade dos sprints enquanto efetivamente entrega face a um plano em cascata por baixo. O custo é que nenhum dos benefícios genuínos da agilidade — o feedback precoce dos utilizadores que altera a direção, o risco revelado cedo — se materializa, enquanto a aparência de prática moderna torna a rigidez subjacente mais difícil de ver e contestar pelos órgãos de supervisão.

Política de código aberto sem plano de sustentação. Um organismo público publica código-fonte para satisfazer uma política de código aberto por defeito mas trata a divulgação como um passo de conformidade pontual, sem recursos para rever contribuições externas, corrigir vulnerabilidades ou manter a documentação. O custo é um repositório publicado que parece aberto mas funciona como um beco sem saída sem manutenção, o que prejudica a confiança no programa mais amplo de código aberto por defeito mais do que nunca ter publicado teria feito.

Modelo de maturidade

Lista de verificação

• Inventarie a dívida técnica de cada sistema crítico e reveja o registo num ciclo fixo.
• Aplique um quadro documentado de construir ou comprar antes de se comprometer com qualquer software novo significativo.
• Para qualquer substituição de sistema legado, adote por defeito um método de migração incremental e exija uma justificação explícita para uma passagem big-bang.
• Confirme as condições de propriedade do código-fonte ou de escrow em cada contrato de software antes da assinatura.
• Publique o código-fonte ao abrigo de uma política de código aberto por defeito, com um processo documentado de exceção.
• Dote de recursos a manutenção contínua de cada repositório publicado ao abrigo dessa política, e não apenas o seu lançamento inicial.
• Exija formatos de dados abertos e documentados mesmo onde o software subjacente é proprietário.
• Estruture as barreiras de financiamento em torno do software funcional demonstrado e não de um único marco de especificação fixa.
• Construa e teste um produto mínimo viável com utilizadores reais antes de se comprometer com o âmbito completo.
• Acompanhe a frequência das implantações, as taxas de defeitos e a dívida técnica pendente como indicadores permanentes de governação.
• Avalie a capacidade interna de engenharia face ao que é necessário para ser um comprador inteligente e colmate as lacunas identificadas.
• Priorize a infraestrutura sem suporte e as integrações não documentadas antes da modernização cosmética.

Fontes principais

• GOV.UK Service Standard, Government Digital Service, Reino Unido — uma norma nacional de serviço digital que exige uma entrega iterativa e centrada no utilizador e normas abertas para os serviços públicos.
• Office of Management and Budget, Federal Source Code Policy (M-16-21), Estados Unidos — a política federal que exige que os organismos considerem a reutilização e a divulgação em código aberto do software governamental desenvolvido à medida.
• Free Software Foundation Europe, campanha Public Money, Public Code — a fundamentação, desenvolvida para um público europeu, para divulgar o código-fonte do software financiado com dinheiros públicos sob licenças livres e de código aberto.
• Ward Cunningham, «The WyCash Portfolio Management System» (relato de experiência OOPSLA 1992) — a declaração original da metáfora da dívida técnica.
• Digital Public Goods Alliance — uma iniciativa multiparticipada que mantém normas e um registo de software, dados e conteúdo abertos concebidos para servir objetivos públicos de desenvolvimento.

Referências

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/