Ingeniería de Software y Plataformas del Sector Público

Por qué esto importa para el valor público

Casi cada servicio público que toca hoy un ciudadano —registrar un nacimiento, reclamar un beneficio, pagar una factura de impuestos, reservar una fecha de tribunal— funciona con software en algún lugar detrás del mostrador o la pantalla. Ese software rara vez es una compra única; se convierte en parte de la infraestructura permanente del estado, a menudo sobreviviendo a la administración que lo encargó, al proveedor que lo construyó, y al lenguaje de programación en el que se formaron sus ingenieros. Un organismo público no experimenta el software de la forma en que experimenta un edificio o una carretera, donde la condición del activo es visible; el software se degrada invisiblemente, y la factura por esa decadencia llega años después como una emergencia.

La tensión que impulsa este tema es estructural. El software es inherentemente iterativo —los requisitos se vuelven más claros a medida que los usuarios interactúan con un sistema funcional, y la mejor práctica de ingeniería es construir algo pequeño, aprender, y adaptar. Los ciclos de contratación pública y rendición de cuentas (véase el Tema 3.7 — Contratación Pública y Encargo de Servicios de Servicios), por el contrario, se construyeron para obras de capital y contratos de defensa: una especificación fija, una única adjudicación grande, pagos por hito, y un análisis de viabilidad aprobado años antes de que comience la entrega. Cuando una legislatura o un auditor espera un contrato de precio fijo y alcance fijo y un equipo de ingeniería necesita cambiar de rumbo después del primer lanzamiento, el desajuste aparece como ampliación de alcance, sobrecoste presupuestario, o un sistema especificado correctamente en 2019 y obsoleto para cuando se entrega.

Las plataformas para cuya construcción existe la práctica de ingeniería de este tema —sistemas de identidad compartidos, rieles de pago, herramientas de gestión de casos reutilizadas entre departamentos— son el tema del Tema 5.1 (véase el Tema 5.1 — Gobierno Digital y Transformación Digital); este tema trata sobre la disciplina de construir y comprar el software que hace confiable, reemplazable, y propiedad del organismo público que depende de él en lugar de del proveedor que resultó escribirlo primero, a cualquier plataforma de este tipo, o a cualquier servicio individual.

Conceptos fundamentales

La decisión de construir frente a comprar es la elección entre encargar software a medida escrito para la necesidad de una organización y adoptar software de mercancía configurable ya construido para un mercado de compradores similares. Comprar usualmente es más barato y de menor riesgo para una necesidad que no es genuinamente distintiva —nómina, correo electrónico, gestión de casos estándar— mientras construir solo se justifica donde el requisito es lo suficientemente diferente como para que ningún producto configurable encaje, o donde la capacidad en sí misma es un activo estratégico que la organización necesita poseer y evolucionar.

La deuda técnica es una metáfora, acuñada por el ingeniero de software Ward Cunningham en 1992, para el coste acumulado de elegir una forma expedita de entregar software ahora sobre una forma más completa que habría tomado más tiempo. La deuda técnica, como la deuda financiera, no está inherentemente mal contraerla —el propio punto de Cunningham era que entregar código funcional rápidamente y refactorizarlo después puede ser la decisión correcta— pero la deuda que nunca se paga acumula interés como entrega más lenta, más defectos, y riesgo creciente, y un organismo público que no puede ver su deuda no puede decidir si pagarla o dejar que se acumule.

Un sistema heredado es una tecnología, aplicación, o plataforma antigua que permanece en uso activo a pesar de estar desactualizada, a menudo porque reemplazarla es caro o porque nadie que quede en la organización entiende completamente qué hace. Los sistemas heredados son especialmente persistentes en el gobierno: los sistemas centrales de impuestos, beneficios, y seguridad social escritos décadas atrás en lenguajes como COBOL —el Lenguaje Común Orientado a Negocios, diseñado en 1960 para la computación administrativa— todavía procesan transacciones para millones de ciudadanos, porque los sistemas funcionan y el conocimiento institucional necesario para retirarlos con seguridad a menudo se ha retirado primero él mismo.

La modernización de software es el término general para convertir, reescribir, o migrar un sistema heredado a una arquitectura, lenguaje, o plataforma actual. La modernización de software abarca un espectro desde una reescritura completa hasta opciones más conservadoras como reanfitrionar el mismo código en infraestructura moderna, y la elección entre ellas es tanto una decisión de gestión de riesgo como una técnica.

El patrón de higuera estranguladora es un enfoque de modernización incremental, nombrado por una enredadera que crece alrededor de un árbol anfitrión y gradualmente lo reemplaza, en el que se construye nueva funcionalidad junto a un sistema heredado y el tráfico se redirige hacia ella pieza por pieza, en lugar de reemplazar todo el sistema en un único corte. El patrón de higuera estranguladora importa porque permite que cada incremento se pruebe, revierta, o pause sin derribar todo el servicio —lo opuesto a un reemplazo de gran explosión, donde se apaga el sistema antiguo y se enciende el nuevo en un único momento sin forma de volver atrás si algo está mal.

La dependencia de proveedor ocurre cuando un cliente se vuelve tan dependiente de la tecnología patentada, los formatos de datos, o los términos contractuales de un proveedor que cambiar a otro proveedor conlleva coste o riesgo prohibitivos. La dependencia de proveedor es un peligro particular en el software del sector público porque el comprador es un cliente recurrente con capacidad práctica limitada de alejarse de un sistema que ejecuta un servicio crítico, lo que debilita su posición negociadora en cada renovación posterior.

El software libre y de código abierto es software distribuido bajo una licencia que otorga a los usuarios la libertad de usar, estudiar, modificar, y redistribuir el código fuente. El software libre y de código abierto sustenta una política de código abierto por defecto, bajo la cual un organismo público recurre por defecto a publicar el código fuente que encarga a menos que una razón específica —sensibilidad de seguridad, derechos de terceros— justifique retenerlo; el fundamento usualmente se resume como 'dinero público, código público': el software pagado una vez con fondos públicos no debería necesitar pagarse de nuevo, en una jurisdicción diferente, por un organismo público diferente que resuelve el mismo problema.

Un bien público digital es software, datos, o contenido abiertos, publicados bajo una licencia abierta, diseñados para ayudar a cumplir un objetivo de desarrollo o gobernanza pública en lugar de generar un retorno comercial. Los bienes públicos digitales reencuadran la publicación de código abierto de un gobierno como parte de una infraestructura más amplia y compartida de la que otros gobiernos y organizaciones de la sociedad civil pueden apoyarse directamente, no solo un gesto de transparencia interno.

El desarrollo ágil de software es un término paraguas para los enfoques iterativos de construcción de software que favorecen el software funcional, la entrega frecuente, y responder al cambio sobre seguir un plan fijo acordado de antemano. El desarrollo ágil de software contrasta con el modelo en cascada, un enfoque secuencial en el que los requisitos, el diseño, la construcción, y las pruebas cada uno se completan totalmente antes de que comience el siguiente; el atractivo de la cascada para los organismos públicos siempre ha sido que sus hitos se mapean claramente en un contrato de precio fijo y un ciclo presupuestario anual, que es por qué gran parte del derecho de contratación todavía la asume, incluso donde la entrega es genuinamente ágil.

Un producto mínimo viable es la versión más pequeña de un servicio que se puede lanzar a usuarios reales para probar si funciona y aprender qué construir después. El concepto de producto mínimo viable, adaptado a los manuales de servicio digital del sector público, da a un equipo iterativo una forma defendible de mostrar a un financiador o un auditor algo real y funcional mucho antes de que se complete el alcance completo —siempre que el proceso de rendición de cuentas acepte un lanzamiento genuinamente mínimo en lugar de tratarlo como el producto terminado bajo un nombre diferente.

Mejores prácticas

1. Recurra por defecto a comprar para necesidades no diferenciadas, y reserve construir para lo que es genuinamente distintivo. Las necesidades de nómina, correo electrónico, y gestión de casos general rara vez son lo suficientemente diferentes de las de cualquier otra organización como para justificar software a medida; construya solo donde el requisito, la escala, o la necesidad de poseer y evolucionar la capacidad durante décadas sea genuinamente diferente de lo que ofrece el mercado.
2. Haga visible la deuda técnica antes de decidir cuánta llevar. Mantenga un registro de atajos conocidos, arreglos diferidos, y dependencias no soportadas para cada sistema en servicio, revisado en un ciclo fijo, de modo que llevar deuda un año más sea una compensación deliberada en lugar de que nadie mire.
3. Nunca planifique un único corte irreversible como la única ruta fuera de un sistema heredado crítico. Prefiera enfoques incrementales como el patrón de higuera estranguladora que permiten que cada pieza se pruebe, revierta, y despliegue gradualmente; un reemplazo de gran explosión de un sistema del que dependen millones concentra años de riesgo en un único fin de semana sin forma de volver atrás si algo falla.
4. Trate el código fuente que paga su organización para que se escriba como un activo que posee, no un servicio que alquila. Negocie el depósito en garantía de código fuente o la propiedad directa en el punto de contratación, no después de que haya comenzado una disputa, ya que un proveedor que sostiene la única copia del código de su servicio crítico es dependencia de proveedor por diseño.
5. Publique el código fuente como abierto por defecto, y exija una justificación específica para retenerlo. Una política de código abierto por defecto, aplicada consistentemente, convierte el software a medida de cada departamento en un activo compartido entre todo el gobierno en lugar de un coste único, y permite a expertos externos encontrar fallos de seguridad que un equipo interno solo pasaría por alto.
6. Escriba contratos de software que hagan la entrega iterativa legal, no solo técnicamente posible. Un contrato que solo paga frente a una especificación fija acordada en la firma fuerza a un equipo a elegir entre la práctica ágil honesta y el cumplimiento contractual; use puertas de financiación escalonadas vinculadas a software funcional demostrado en lugar de un único hito al final.
7. Financie la modernización como un programa continuo, no un proyecto de capital único. Un sistema heredado modernizado una vez y luego dejado durante otros veinte años acumula el mismo riesgo con el que comenzó; presupueste para la renovación continua e incremental de la forma en que una autoridad de carreteras presupuesta para reasfaltado, no un gran reemplazo una vez por generación.
8. Elija estándares abiertos y formatos de datos portables incluso al comprar software comercial. Exigir que el sistema de un proveedor almacene y exporte datos en formatos abiertos y documentados mantiene bajos los costes de cambio incluso donde el propio software es patentado, y a menudo es una salvaguarda a corto plazo más alcanzable contra la dependencia que insistir en que todo sistema sea de código abierto.
9. Construya un producto mínimo viable y muéstrelo a usuarios reales antes de comprometerse con el alcance completo. Lanzar una versión genuinamente mínima, luego iterar sobre lo aprendido, capta supuestos equivocados mientras todavía son baratos de arreglar, en lugar de después de que se haya construido un sistema a escala completa contra ellos.
10. Mantenga la capacidad de ingeniería interna suficiente para ser un comprador inteligente, incluso donde la entrega se contrata externamente. Un organismo público que ha vaciado su experiencia técnica no puede evaluar la propuesta de un proveedor, detectar señales de alerta temprana de un proyecto problemático, o negociar su salida de la dependencia, sea lo que sea que digan sus reglas de contratación en papel.
11. Retire el perfil de riesgo de un sistema heredado antes que su interfaz de usuario. Priorice reemplazar los lenguajes no soportados, la infraestructura sin parchear, y las integraciones no documentadas —los fallos que causan interrupciones y brechas— antes que la modernización visual, que conlleva mucho menos riesgo operativo.
12. Mida la salud de la entrega con indicadores de ingeniería, no solo la varianza de presupuesto y calendario. La frecuencia de despliegue, las tasas de defectos, y la antigüedad del elemento de deuda técnica no abordado más antiguo le dicen a una junta de gobierno más sobre si un programa tendrá éxito que si actualmente está dentro del presupuesto, a menudo el último indicador en moverse.

Preguntas para discutir con su equipo

¿Realmente sabemos cuánta deuda técnica llevamos, sistema por sistema? La mayoría de los organismos públicos pueden declarar su presupuesto de capital para el año pero no pueden declarar, con ninguna confianza, cuánto de su patrimonio de software funciona con componentes no soportados, lógica no documentada, o código que nadie que quede en el personal entiende completamente. Use esta pregunta para pedir a cada propietario de sistema en la sala que estime, honestamente, cuán confiado está de que su equipo podría cambiar con seguridad su sistema más crítico sin romper algo que nadie anticipó. Discuta qué se necesitaría para convertir esas estimaciones en un registro real, revisado en un ciclo fijo, en lugar de conocimiento tribal que se va cuando lo hace un ingeniero clave. Considere, también, quién decide actualmente cuánta deuda es aceptable llevar, y si esa decisión es deliberada o por defecto.

Si nuestro sistema heredado más crítico necesitara reemplazarse comenzando hoy, ¿estaríamos planificando un corte de gran explosión o una migración incremental —y por qué? El instinto de reemplazar un sistema antiguo todo de una vez a menudo está impulsado por ciclos presupuestarios y conveniencia de gestión de programa en lugar de necesidad técnica, y concentra un riesgo enorme en un único momento. Use esta pregunta para recorrer, concretamente, cómo se vería realmente una migración incremental de estilo higuera estranguladora de su sistema heredado más crítico, pieza por pieza. Discuta qué le está impidiendo elegir esa ruta hoy —financiación estructurada en torno a una única fecha de lanzamiento, un proceso de gobernanza que quiere un hito limpio, o una restricción técnica genuina que hace imposible la migración incremental para este sistema.

¿Quién realmente posee el código fuente del software que ha pagado su organización para que se construya, y podríamos probarlo? Muchos organismos públicos descubren, solo cuando una relación con un proveedor se agria, que el contrato nunca aseguró la propiedad clara o el depósito en garantía del código del que dependen sus servicios críticos. Use esta pregunta para extraer los contratos de sus tres sistemas a medida más importantes y comprobar, específicamente, qué dice cada uno sobre la propiedad del código, el depósito en garantía, y el derecho a llevar el código a otro proveedor. Discuta qué pasaría mañana si su proveedor primario para cualquiera de esos tres sistemas quebrara o se negara a continuar la relación.

¿Dónde estamos recurriendo por defecto al software cerrado y patentado por hábito, cuando un enfoque de código abierto por defecto nos serviría igual de bien o mejor? Las políticas de código abierto por defecto existen precisamente porque la mayoría de los organismos públicos resuelven problemas superpuestos independientemente, cada uno pagando el coste completo del software que otro organismo público ya ha construido y podría haber compartido. Use esta pregunta para identificar un sistema actualmente en construcción o especificación y pregunte si ya existe un equivalente como software de código abierto en otro lugar del gobierno, o si el que está construyendo podría publicarse útilmente para que otros lo reutilicen. Discuta qué barrera específica —preocupación de seguridad, hábito de contratación, falta de una política clara— realmente está impidiendo esa reutilización, en lugar de asumir que no es relevante aquí.

¿Nuestro proceso de contratación y rendición de cuentas realmente permite la entrega ágil honesta, o simplemente reetiqueta los hitos de cascada como sprints? Es común que un equipo ejecute ceremonias nominalmente ágiles mientras todavía se financia, gobierna, e informa frente a una especificación fija acordada en la firma del contrato, lo que recrea cada modo de fallo de cascada bajo una etiqueta ágil. Use esta pregunta para rastrear un programa digital en vivo desde su análisis de viabilidad hasta su informe de gobernanza actual y pregunte si la estructura de financiación toleraría que el programa cambiara de dirección basándose en lo que le enseñó un lanzamiento temprano genuino. Discuta qué necesitaría cambiar en cómo se financia e informa el programa para que la entrega iterativa sea real en lugar de cosmética (véase el Tema 3.7 — Contratación Pública y Encargo de Servicios de Servicios).

¿Tenemos suficiente capacidad de ingeniería interna para ser un comprador inteligente de los sistemas de los que más dependemos? Una organización que ha contratado externamente todo su juicio técnico, no solo su capacidad de entrega, no puede decir si la propuesta de un proveedor es sólida, si un proyecto está silenciosamente dirigiéndose hacia problemas, o cuál es realmente un precio justo por el trabajo. Use esta pregunta para preguntar cuántas personas en su organización podrían revisar creíblemente una propuesta de arquitectura técnica para su sistema más importante, y cómo ha cambiado ese número en los últimos cinco años. Discuta qué se necesitaría para reconstruir esa capacidad donde se ha erosionado, y qué pierde su organización, tanto en posición negociadora como en riesgo de entrega, por cada año que pasa sin ella.

En la práctica: un ejemplo de valor público

Un gobierno regional ficticio —solo ilustrativo, no una descripción de ninguna jurisdicción real— ejecutaba sus reclamaciones de beneficio por desempleo mediante un sistema escrito por primera vez hace más de treinta años, mantenido por un número decreciente de ingenieros que entendían su lenguaje de programación original. El volumen de reclamaciones había crecido mucho más allá de lo que habían anticipado los diseñadores del sistema, las ejecuciones de procesamiento nocturnas cada vez más frecuentemente no lograban completarse antes de que comenzaran las transacciones de la mañana, y el liderazgo tecnológico de la agencia advirtió que una interrupción no planificada que afectara los pagos de beneficios ahora era cuestión de cuándo, no de si.

El primer instinto de la agencia fue una respuesta convencional a un problema que se sentía urgente: encargar un único contrato grande para reemplazar todo el sistema con una plataforma moderna, especificada completamente de antemano, entregada frente a un calendario fijo de dos años con un fin de semana de corte al final. Una revisión previa a la implementación encargada por el comité de auditoría de la agencia planteó una pregunta difícil antes de firmar el contrato: qué pasaría con los pagos de beneficios para varios cientos de miles de reclamantes si el nuevo sistema tuviera un defecto no descubierto en su primera semana de operación completa y en vivo, con el sistema antiguo ya desmantelado y sin forma de volver atrás.

La agencia cambió de rumbo. Mantuvo el sistema heredado funcionando como el sistema de registro y comenzó a construir nueva funcionalidad de admisión de reclamaciones y evaluación de elegibilidad junto a él, usando un enfoque de higuera estranguladora: cada nuevo módulo se lanzó primero a un pequeño porcentaje de nuevas reclamaciones, se verificó frente al producto paralelo del sistema antiguo, y se expandió solo una vez que coincidieron sus resultados. Dentro de dieciocho meses, la mayoría de las nuevas reclamaciones funcionaban mediante componentes modernos mientras el sistema original manejaba una carga de casos residual decreciente, con la capacidad de enrutar cualquier caso individual de vuelta a la ruta antigua si algo parecía mal. La agencia también exigió, en cada nuevo contrato emitido para este trabajo, que el código fuente fuera propiedad de la agencia y se publicara como código abierto una vez completada la revisión de seguridad, de modo que otros gobiernos regionales que enfrentaran el mismo problema de mainframe envejecido pudieran adaptar los componentes en lugar de repetir la misma construcción desde cero.

El reemplazo completo de las últimas funciones residuales del sistema heredado tomó casi cuatro años —más tiempo, en papel, de lo que prometía el plan original de gran explosión de dos años. Pero ningún reclamante experimentó jamás una interrupción no planificada durante la transición, cada incremento era lo suficientemente pequeño como para revertirse dentro de horas cuando se encontraba un defecto, y dos gobiernos regionales vecinos comenzaron a adaptar el código de evaluación de elegibilidad publicado de la agencia para sus propios sistemas dentro del primer año de su publicación.

Cuatro lentes sectoriales

Gobierno local

El gobierno local típicamente ejecuta un gran número de sistemas más pequeños y desconectados en lugar de un puñado de plataformas de escala nacional, lo que significa que la deuda técnica se acumula a través de muchas aplicaciones contratadas y mantenidas por separado en lugar de en un único sistema insignia visible. Las autoridades locales usualmente tienen la menor capacidad de ingeniería interna de cualquier nivel de gobierno, lo que hace especialmente fuerte el caso de comprar software de mercancía configurable sobre construcciones a medida, y hace de las plataformas compartidas regionales o nacionales —el tema del Tema 5.1 (véase el Tema 5.1 — Gobierno Digital y Transformación Digital)— una ruta de particular alto valor para evitar que cada autoridad reconstruya por separado la misma capacidad.

Gobierno nacional

El gobierno nacional es donde tienden a situarse los sistemas heredados más antiguos y consecuentes —la administración central de impuestos, seguridad social, y beneficios— porque estos a menudo estuvieron entre los primeros esfuerzos de computarización a gran escala en el gobierno y ahora conllevan lo más alto en juego para cualquier fallo de modernización. El gobierno nacional típicamente tiene la capacidad comercial y de ingeniería especializada para ejecutar un programa de modernización genuinamente incremental y para negociar propiedad de código real en sus contratos, y usualmente es el nivel de gobierno mejor posicionado para fijar una política de código abierto por defecto con suficiente escala detrás como para hacer que la reutilización entre todo el gobierno realmente ocurra.

Sector social y sin ánimo de lucro

Las organizaciones sin ánimo de lucro y benéficas rara vez construyen ellas mismas grandes plataformas a medida, pero frecuentemente están en el extremo receptor de software encargado o mandatado por un financiador gubernamental —un portal de informes, un sistema de gestión de casos que un contrato o subvención les exige usar— con poca influencia sobre su diseño, su deuda técnica, o su proveedor. Una organización del sector social que depende de un sistema mandatado por el gobierno hereda los modos de fallo de ese sistema sin heredar ninguna de la influencia para arreglarlos, lo que es una razón más por la que las relaciones de financiación basadas en resultados necesitan contabilizar la carga operativa de la tecnología mandatada (véase el Tema 3.7 — Contratación Pública y Encargo de Servicios de Servicios), no solo la propia métrica de resultado.

Multilateral e internacional

Los organismos multilaterales y las agencias de desarrollo cada vez más promueven el software construido para la administración pública de un país como un bien público digital reutilizable que otros países pueden adaptar, en lugar de que cada gobierno encargue un sistema equivalente a un proveedor privado a coste completo. El riesgo distintivo aquí es que un bien público digital construido para el contexto legal y administrativo de un país se puede adoptar en otro lugar con muy poca adaptación, importando supuestos —sobre identidad, elegibilidad, o proceso— que en realidad no se transfieren; la promesa de infraestructura compartida y abierta es real, pero solo donde una capacidad de adaptación local genuina acompaña al código.

Modos de fallo comunes

El corte de gran explosión que falla en el lanzamiento. Un sistema heredado crítico se reemplaza en un único corte irreversible después de años de desarrollo sin exposición de producción en vivo, y un defecto que solo aparece a escala real o en un caso extremo que nadie probó sale a la superficie el primer día de operación completa, sin forma de revertir al sistema antiguo porque ya se ha desmantelado. El coste se mide en pagos perdidos, servicios negados, o interrupciones que afectan exactamente a los ciudadanos a los que existe para servir el sistema, en el peor momento posible —el momento en que todos dependían de que funcionara el reemplazo.

Acumulación silenciosa de deuda técnica. La presión de plazo repetidamente gana el argumento contra el tiempo necesario para arreglar atajos conocidos, y cada aplazamiento es individualmente defendible, hasta que la deuda acumulada hace que incluso un pequeño cambio sea desproporcionadamente caro y riesgoso. El coste sale a la superficie años después como un sistema que nadie puede modificar con seguridad, una fuerza laboral que silenciosamente ha dejado de intentar cualquier cosa excepto los parches más urgentes, y un eventual programa de modernización mucho más grande y caro de lo que habría sido la renovación continua y más pequeña.

Dependencia de proveedor confundida con estabilidad. Un organismo público renueva repetidamente el contrato del mismo proveedor porque cambiar parece demasiado disruptivo para intentar, sin jamás probar cuáles serían realmente los costes de cambio genuinos o negociar la propiedad del código y los formatos de datos abiertos que mantendrían esos costes manejables. El coste es una posición negociadora permanentemente debilitada sobre precio y términos, descubierta solo cuando declina la calidad del servicio del proveedor o sube su precio y el organismo público descubre que no tiene una alternativa creíble.

Ágil cosmético. Un equipo de entrega adopta ceremonias ágiles —reuniones de pie, sprints, una cartera— mientras el contrato, la financiación, y la estructura de gobernanza subyacentes todavía asumen una especificación fija y un único hito de ir/no ir, así que el equipo informa velocidad de sprint mientras en realidad entrega frente a un plan en cascada por debajo. El coste es que ninguno de los beneficios genuinos de ágil —la retroalimentación temprana de usuarios cambiando el rumbo, el riesgo sacado a la superficie temprano— se materializa, mientras la apariencia de práctica moderna hace más difícil que los organismos de supervisión vean y cuestionen la rigidez subyacente.

Política de código abierto sin plan de sostenimiento. Un organismo público publica código fuente para satisfacer una política de código abierto por defecto pero trata la publicación como un paso de cumplimiento único, sin recursos para revisar contribuciones externas, parchear vulnerabilidades, o mantener documentación. El coste es un repositorio publicado que parece abierto pero funciona como un callejón sin salida sin mantener, lo que daña la confianza en el programa más amplio de código abierto por defecto más de lo que lo habría hecho nunca publicar en absoluto.

Modelo de madurez

Lista de verificación

• Inventariar la deuda técnica de cada sistema crítico y revisar el registro en un ciclo fijo.
• Aplicar un marco documentado de construir frente a comprar antes de comprometerse con cualquier software nuevo significativo.
• Para cualquier reemplazo de sistema heredado, recurrir por defecto a un método de migración incremental y exigir una justificación explícita para un corte de gran explosión.
• Confirmar los términos de propiedad de código fuente o depósito en garantía en cada contrato de software antes de la firma.
• Publicar el código fuente bajo una política de código abierto por defecto, con un proceso de excepción documentado.
• Dotar de recursos el mantenimiento continuo de cada repositorio publicado bajo esa política, no solo su publicación inicial.
• Exigir formatos de datos abiertos y documentados incluso donde el software subyacente sea patentado.
• Estructurar las puertas de financiación en torno a software funcional demostrado en lugar de un único hito de especificación fija.
• Construir y probar un producto mínimo viable con usuarios reales antes de comprometerse con el alcance completo.
• Rastrear la frecuencia de despliegue, las tasas de defectos, y la deuda técnica pendiente como indicadores de gobernanza permanentes.
• Evaluar la capacidad de ingeniería interna frente a lo que se necesita para ser un comprador inteligente, y cerrar las brechas identificadas.
• Priorizar la infraestructura no soportada y las integraciones no documentadas antes que la modernización cosmética.

Fuentes clave

• GOV.UK Service Standard, Government Digital Service, Reino Unido —un estándar nacional de servicio digital que exige entrega iterativa y centrada en el usuario y estándares abiertos para los servicios públicos.
• Oficina de Administración y Presupuesto, Federal Source Code Policy (M-16-21), Estados Unidos —la política federal que exige a las agencias considerar la reutilización y publicación de código abierto para el software gubernamental desarrollado a medida.
• Free Software Foundation Europe, campaña Public Money, Public Code —el fundamento, desarrollado para una audiencia europea, para publicar el código fuente de software financiado públicamente bajo licencias libres y de código abierto.
• Ward Cunningham, 'The WyCash Portfolio Management System' (informe de experiencia OOPSLA 1992) —la declaración original de la metáfora de la deuda técnica.
• Digital Public Goods Alliance —una iniciativa multi-parte interesada que mantiene estándares y un registro para software, datos, y contenido abiertos diseñados para servir objetivos de desarrollo público.

Referencias

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/