Tema 4.0 — Arquitectura técnica, nube y sistemas heredados

En la salud y la atención, la arquitectura técnica es una decisión de seguridad clínica, seguridad y dinero público tomada con años de antelación: las plataformas que estableces y los sistemas heredados que dejas en su lugar determinan silenciosamente si la atención puede ser segura, conectada, y asequible mucho después de que las personas que las eligieron se hayan ido.

Por qué esto importa en la salud y la atención#

La arquitectura es el conjunto de elecciones estructurales de larga duración debajo de tus servicios digitales: qué se ejecuta dónde, cómo se conectan los componentes, qué construyes frente a qué compras, y qué mantienes vivo del pasado. Estas elecciones rara vez son visibles para pacientes o clínicos, y rara vez emocionan a las juntas directivas. Sin embargo, dan forma a todo lo que se sitúa encima. Un patrimonio bien arquitecturado te permite añadir un nuevo servicio rápidamente, compartir datos de forma segura, y recuperarte rápido cuando algo se rompe. Uno mal arquitecturado hace que cada cambio sea lento, cada integración frágil, y cada incidente peor.

En la salud y la atención las consecuencias son altas porque los sistemas son trascendentales. Cuando un sistema envejecido de administración de pacientes se cae, las ambulancias se desvían y las clínicas cancelan. Cuando se explota un sistema operativo no soportado, se exponen registros confidenciales y los servicios se detienen —como el NHS aprendió en 2017 cuando el ataque de ransomware WannaCry se propagó a través de máquinas ejecutando software que ya no se podía parchear. Esa interrupción no fue un ataque inteligente y dirigido; fue la consecuencia predecible de deuda técnica acumulada en sistemas críticos. Las decisiones de arquitectura son, por lo tanto, decisiones de seguridad, las enmarque alguien así o no.

También son decisiones de equidad y confianza. Los sistemas heredados que no pueden compartir datos dejan a los pacientes más complejos —aquellos que tocan muchos servicios— con los registros más fragmentados. Las plataformas cerradas que te bloquean a un único proveedor drenan dinero que podría financiar la atención. Y el público razonablemente espera que el NHS funcione con tecnología moderna, segura, y bien mantenida; la brecha entre esa expectativa y el patrimonio real es en sí misma un riesgo para la confianza.

Finalmente, aquí es donde se compromete una gran cantidad de dinero público durante mucho tiempo. La parte más costosa de un sistema rara vez es su compra; es la década de alojamiento, licencias, mantenimiento, y eventual reemplazo que sigue. Los líderes que tratan la arquitectura como "algo que maneja el equipo técnico" están delegando algunos de los compromisos financieros más grandes y duraderos que hace la organización. Este tema está escrito para que puedas exigir responsabilidad por esas decisiones sin ser ingeniero.

Conceptos clave#

La arquitectura empresarial es la disciplina de alinear los procesos de negocio, la información, las aplicaciones, y la tecnología de una organización para que apoyen la estrategia coherentemente en lugar de crecer por accidente. Toma la vista de toda la organización: qué capacidades necesitas, qué sistemas las proporcionan, y dónde están las brechas y duplicaciones. La arquitectura de soluciones es la disciplina más estrecha, a nivel de proyecto, de diseñar cómo se construirá un servicio específico y encajará en el patrimonio más amplio. Ambas se sitúan dentro de la idea más amplia de arquitectura de sistemas —el modelo estructural de cómo se combinan los componentes, interfaces, y comportamientos en un todo funcional. Los líderes no necesitan practicar estas disciplinas, pero deberían insistir en que existan, porque su ausencia es cómo los patrimonios se vuelven inmanejables.

La arquitectura se guía por principios de arquitectura: un conjunto corto y acordado de declaraciones —como "reutilizar antes de comprar, comprar antes de construir" o "construir según estándares abiertos"— que hacen posibles decisiones consistentes sin que cada elección se escale. Los principios se hacen cumplir, ligeramente, por una autoridad de diseño: un pequeño grupo que revisa decisiones técnicas significativas. La versión saludable de una autoridad de diseño habilita en lugar de bloquear; existe para prevenir el daño y la duplicación evitables, no para ralentizar a los equipos o hacer de guardián por sí misma.

La computación en la nube es la entrega de computación —servidores, almacenamiento, bases de datos, redes— como un servicio bajo demanda a través de internet, en lugar de desde hardware que posees en tu propio edificio. Una nube pública es operada por un proveedor de terceros y compartida entre muchos clientes; una nube privada está dedicada a una organización; una nube híbrida combina las dos, a menudo manteniendo algunas cargas de trabajo en la infraestructura existente mientras mueve otras fuera. Muchos gobiernos, incluyendo el del Reino Unido, han adoptado una política de "nube primero", lo que significa que los equipos deberían considerar la nube pública antes que otras opciones y justificar no usarla. Porque la nube se factura por consumo en lugar de comprarse una vez, controlar ese gasto se ha convertido en su propia disciplina —FinOps, la práctica de unir la ingeniería y las finanzas para que los equipos tengan visibilidad de, y responsabilidad por, lo que realmente cuesta su uso de la nube. A nivel de aplicación, el software como servicio (SaaS) entrega una aplicación terminada a través de la web que el proveedor aloja y mantiene, así que tú la configuras en lugar de operarla. La infraestructura y el alojamiento —dónde y cómo se ejecutan físicamente tus sistemas— se sitúan debajo de todo esto, y cada vez más llevan un coste de carbono que pertenece a la decisión (véase el Tema 8.5 — Sostenibilidad y cero neto).

Un sistema heredado es un sistema envejecido pero del que todavía se depende, que es difícil de cambiar, a menudo ejecutando software no soportado para el cual ya no se emiten parches de seguridad. El legado se acumula como deuda técnica —el coste futuro de elecciones expeditivas hechas en el pasado. Un poco de deuda es normal e incluso sensato; la deuda no gestionada a escala se convierte en una responsabilidad de seguridad y protección, porque los sistemas de los que más personas dependen se convierten en los sistemas que nadie se atreve a tocar. Gestionar esto es el trabajo de la gestión de cartera de aplicaciones: mantener un inventario claro de cada aplicación, su coste, condición, y valor de negocio, para que puedas racionalizar el patrimonio —retirando, reemplazando, o consolidando sistemas— y dar de baja de forma segura en lugar de dejar que la cosa antigua siga funcionando silenciosamente.

Los patrimonios modernos se mantienen unidos por interfaces de programación de aplicaciones (API): interfaces definidas a través de las cuales un sistema ofrece una capacidad a otro. Las API bien diseñadas te permiten ensamblar plataformas —servicios reutilizables sobre los que construyen muchos equipos— mientras mantienes los componentes débilmente acoplados y reemplazables. Una disciplina útil aquí es la "plataforma mínima viable": construye solo la capacidad compartida que genuinamente reduce el trabajo de otros, y nada más. Sustentando el diseño seguro está el seguro por diseño, el principio de que la seguridad se incorpora desde el principio en lugar de añadirse después. Y el marco financiero para todo esto es el coste total de propiedad (TCO): el coste completo de por vida de un sistema, no su precio de compra —la lente a través de la cual debería juzgarse la elección de construir/comprar/configurar, y el riesgo de bloqueo de proveedor.

Buenas prácticas#

1. Acordar un conjunto corto de principios de arquitectura y usarlos para decidir. Escribe un puñado de principios claros y memorables —reutilizar antes de comprar antes de construir, construir según estándares abiertos, nube donde tenga sentido, seguro por diseño, diseñar para toda la vía de atención— y deja que los equipos tomen la mayoría de las decisiones por sí mismos aplicándolos. Los principios solo funcionan si genuinamente se usan para decir sí y no, y solo si hay suficientemente pocos para recordar. Esto se conecta directamente con el Tema 1.1 — El modelo operativo y el Tema 1.2 — Estrategia digital y hoja de ruta, que establecen la dirección a la que sirven los principios.

2. Operar una autoridad de diseño que habilite en lugar de bloquear. Establece un grupo pequeño, senior, y multidisciplinario para revisar decisiones técnicas significativas —aquellas que son costosas, difíciles de revertir, afectan a muchos servicios, o conllevan riesgo de seguridad y protección. Dale una ruta rápida y ligera para que las elecciones rutinarias no se arrastren a través de ella, y mantenla a un estándar de servicio: debería ayudar a los equipos a encontrar una buena respuesta, no simplemente rechazar. Una autoridad de diseño que se convierte en un cuello de botella será evadida, y la arquitectura en la sombra es peor que ninguna.

3. Adoptar la nube deliberadamente, carga de trabajo por carga de trabajo, no como un eslogan. Trata "nube primero" como un valor predeterminado sobre el que razonar, no una instrucción de mover todo. Evalúa cada carga de trabajo para adecuación, residencia de datos, resiliencia, coste a escala, y el esfuerzo de migrar, y sé honesto en que trasladar sin cambios una aplicación heredada a menudo solo reubica el problema a un coste mayor. Sopesa la dimensión de carbono explícitamente, ya que dónde y cómo alojas afecta las emisiones (véase el Tema 8.5 — Sostenibilidad y cero neto), y diseña para la portabilidad para que un futuro movimiento entre proveedores siga siendo posible.

4. Mantener una cartera de aplicaciones viva y gestionar la deuda técnica como un riesgo nombrado. Mantén un inventario preciso de cada aplicación, su propietario de negocio, coste, capacidad de soporte, y el riesgo que conlleva, y revísalo regularmente. Pon la deuda técnica y el software no soportado en el registro de riesgo corporativo con la misma seriedad que el riesgo clínico o financiero, porque eso es lo que es. Lo que no puedes ver, no puedes financiar, priorizar, ni retirar de forma segura, y los patrimonios que nunca se inventarían son exactamente los que fallan sin advertencia.

5. Racionalizar el patrimonio y dar de baja de forma segura. Retira activamente los sistemas duplicados, obsoletos, y de fin de vida en lugar de dejarlos persistir "por si acaso", porque cada sistema en vivo es una superficie de ataque, un coste de licencia, y una carga de mantenimiento. La baja de servicio es un proyecto por derecho propio: migra o archiva los datos bajo reglas claras de retención, confirma que nada sigue dependiendo del sistema, comunícate con los usuarios, y verifica antes de apagar. Hecho bien, la racionalización libera dinero y reduce el riesgo; hecho descuidadamente, destruye registros o rompe una dependencia que nadie documentó.

6. Preferir estándares abiertos, API, y componentes débilmente acoplados. Diseña para que las capacidades se expongan a través de API documentadas y versionadas, para que un componente pueda reemplazarse sin reconstruir todo a su alrededor. Esta es la base arquitectónica para la interoperabilidad discutida en el Tema 4.3 — Interoperabilidad y estándares de datos, y es tu principal defensa contra el bloqueo. Cuesta un poco más por adelantado que una conexión directa y cableada, y se recupera muchas veces la primera vez que necesitas cambiar de proveedor o añadir un servicio.

7. Construir la plataforma mínima viable, y nada más. Cuando crees una plataforma compartida sobre la que otros construyan, resiste el impulso de hacerla completa desde el primer día. Proporciona la capacidad reutilizable más pequeña que genuinamente elimina trabajo para los equipos, prueba que se usa, y hazla crecer en respuesta a la demanda real. Las plataformas sobreconstruidas se convierten en su propio legado —costosas, rígidas, y resentidas— mientras que una plataforma delgada y bien operada gana adopción y evoluciona con la necesidad.

8. Hacer que la arquitectura de seguridad y el seguro por diseño sean no negociables. Incorpora el pensamiento de seguridad en el diseño desde el primer boceto, no como una puerta previa al lanzamiento: minimiza la superficie de ataque, aplica el privilegio mínimo, segmenta las redes, y asume que los componentes serán sondeados. En la salud y la atención esto es inseparable de la seguridad clínica y la gobernanza de la información (Tema 1.6 — Seguridad clínica y gestión de riesgos; Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad), porque una brecha es tanto un daño de datos como, cuando detiene sistemas, un evento de seguridad del paciente. El software no soportado e imparcheable es una decisión de seguridad que estás tomando por defecto —así que tómala deliberadamente, con mitigaciones, o no la tomes en absoluto.

9. Decidir construir, comprar, o configurar según el coste total de propiedad, no el precio de etiqueta. Para cada capacidad, compara construir a medida, comprar un producto, y configurar una plataforma existente según su coste completo de por vida —alojamiento, licencias, integración, soporte, actualizaciones, y eventual salida— no el precio inicial. Favorece comprar o configurar para necesidades básicas y reserva construir para diferenciación genuina, y sopesa el bloqueo que crea cada opción. Trabaja esto con colegas comerciales (Tema 6.3 — Contratación y aspectos comerciales), porque el momento más barato para asegurar interfaces abiertas y derechos de salida es antes de firmar.

10. Tratar el gasto en la nube como una disciplina compartida de ingeniería y finanzas (FinOps). Da a los equipos visibilidad clara de lo que cuestan sus servicios etiquetando los recursos de nube a propietarios, dimensiona apropiadamente las instancias frente al uso real, y apaga los recursos inactivos o sobreaprovisionados en lugar de pagar por ellos mes tras mes. Haz que los equipos que operan un servicio sean responsables de su coste de funcionamiento, para que las personas mejor situadas para reducir el desperdicio sean las que ven la factura. La nube de pago por uso sin esta disciplina consume silenciosamente presupuesto que debería estar financiando la atención, y la deriva rara vez se nota hasta que una factura fuerza la pregunta.

11. Arquitecturar para el coste como un requisito no funcional de primer nivel, sopesado frente al carbono y la resiliencia. Trata el coste de la forma en que tratas el rendimiento, la seguridad, y la disponibilidad: una propiedad para la que diseñas deliberadamente, estimas antes de construir, y revisas a medida que crece el uso. Sopésalo explícitamente frente al carbono (véase el Tema 8.5 — Sostenibilidad y cero neto) y frente a la resiliencia, porque los tres a menudo se mueven juntos —pero nunca persigas la factura más baja a expensas de la seguridad, la capacidad de recuperación, o los resultados del paciente. La respuesta correcta es el coste más bajo que aún cumple con tus obligaciones de seguridad clínica y resiliencia, no la opción más barata de forma aislada.

Preguntas para debatir con tu equipo#

1. ¿Cuáles de nuestros sistemas críticos no están soportados o son imparcheables hoy, y cuál es nuestra exposición real si uno es atacado o falla? Comienza desde los sistemas sin los cuales los servicios clínicos y operativos genuinamente no pueden funcionar, y establece concretamente cuáles ejecutan software que ya no recibe actualizaciones de seguridad o soporte del proveedor. Pregunta qué sucedería —a pacientes, personal, datos— si cada uno fuera golpeado por ransomware o simplemente se detuviera, y cuánto tiempo tomaría la recuperación. Distingue los sistemas en los que has aceptado conscientemente el riesgo, con mitigaciones en marcha, de aquellos cuya fragilidad nadie ha evaluado. Considera si esta exposición es visible en el registro de riesgo corporativo o enterrada en una hoja de cálculo que ninguna junta directiva ha visto. Reflexiona sobre WannaCry: el daño no vino de la sofisticación sino de deuda conocida y no abordada en sistemas críticos. Si no puedes responder esto con evidencia, esa brecha es en sí misma tu hallazgo más urgente, porque no puedes financiar un riesgo que no has nombrado.

2. ¿Dónde estamos bloqueados, y qué nos costaría realmente dejar nuestra plataforma más grande? Muchas organizaciones descubren el precio real de un sistema cerrado solo cuando intentan cambiarlo. Trabaja a través de qué se necesitaría realmente para salir de tu plataforma clínica o corporativa más grande: si puedes extraer tus datos en una forma usable y estándar, qué interfaces propietarias tendrían que deshacerse, y qué dice tu contrato sobre propiedad y salida. Considera si "la nube" se ha convertido silenciosamente en un bloqueo de un tipo diferente, con datos y herramientas tan enredados en un proveedor que irse es poco práctico. Sopesa esto frente a la apertura de alternativas y cualquier plataforma nacional que podrías reutilizar en su lugar. Esto no es un argumento para cambiar de proveedor constantemente; se trata de entender tu influencia antes de tu próxima negociación, y no dejar que la hoja de ruta de un proveedor se convierta silenciosamente en tu única opción.

3. ¿Estamos invirtiendo lo suficiente en mantener y racionalizar lo que ya tenemos, o solo en lo nuevo y visible? Los sistemas nuevos atraen financiación y atención; el trabajo poco glamoroso de parchear, actualizar, consolidar, y retirar de forma segura rara vez lo hace, que es exactamente cómo se acumula la deuda. Pregunta qué proporción de tu presupuesto digital realmente va a mantener el patrimonio existente seguro y actualizado frente a construir cosas nuevas, y si alguien posee ese equilibrio deliberadamente. Discute si la baja de servicio alguna vez se dota de recursos apropiadamente, o si los sistemas antiguos simplemente persisten porque apagarlos no es el trabajo de nadie. Considera las aplicaciones duplicadas haciendo lo mismo en toda la organización, y qué se necesitaría para consolidarlas. Piensa en quién, a nivel de junta directiva, es responsable de la salud del patrimonio en su conjunto en lugar de proyectos individuales. Una organización que solo financia lo nuevo está pidiendo prestado contra su propia seguridad futura, y el reembolso siempre vence en el peor momento posible.

4. ¿Realmente sabemos cuánto cuesta nuestra nube, quién posee esa factura, y si el gasto está bajo control? La nube de pago por uso puede consumir silenciosamente presupuesto que debería estar financiando la atención, y la deriva rara vez se nota hasta que una factura fuerza la pregunta. Pregunta si los recursos de nube se etiquetan a los equipos y servicios que los poseen, si alguien dimensiona apropiadamente las instancias frente al uso real, y si los recursos inactivos o sobreaprovisionados alguna vez se apagan. Discute si las personas que operan un servicio ven y responden por su coste de funcionamiento, o si el gasto en la nube aterriza como una única línea inexplicada en un presupuesto central que nadie puede descomponer. Considera si el coste se trata como un requisito no funcional de primer nivel —estimado antes de construir y revisado a medida que crece el uso— o solo se descubre después del hecho. Sé honesto sobre la tensión entre la autonomía de ingeniería y el control financiero, y sobre sopesar el coste frente al carbono y la resiliencia en lugar de simplemente perseguir la factura más baja. Una respuesta honesta nombra quién sostiene la disciplina FinOps y muestra la evidencia de que está funcionando, en lugar de asumir que la nube es más barata porque es moderna.

5. Cuando necesitamos una nueva capacidad, ¿cómo decidimos entre construirla, comprarla, y configurar algo que ya tenemos —y sobre qué base? El instinto de construir a medida, o de comprar el producto con la mejor demostración, a menudo gana antes de que alguien haya comparado el coste completo de por vida. Trabaja a través de cómo se tomaron realmente tus últimas elecciones significativas: si se sopesaron el alojamiento, las licencias, la integración, el soporte, las actualizaciones, y la eventual salida, o solo el precio inicial. Pregunta si reservas construir para diferenciación genuina y por defecto compras o configuras para necesidades básicas, o si las construcciones personalizadas proliferan silenciosamente porque un equipo las prefirió. Considera quién está en la sala para estas decisiones —colegas comerciales y clínicos además de ingenieros— y si el bloqueo que crea cada opción se evalúa antes de firmar en lugar de descubrirse después. Reflexiona sobre si tus principios de arquitectura ("reutilizar antes de comprar, comprar antes de construir") genuinamente vinculan estas elecciones o se ignoran silenciosamente. Una respuesta honesta puede señalar decisiones reales donde el coste total de propiedad, no el precio de etiqueta, cambió el resultado.

6. ¿Tenemos la capacidad interna de arquitectura para sostener nuestras propias decisiones, o dependemos de los proveedores a los que se supone que debemos exigir responsabilidad? La arquitectura es donde se hacen los compromisos más grandes y duraderos, sin embargo muchas organizaciones han vaciado la misma capacidad necesaria para tomarlos bien, confiando en los proveedores cuyos productos están bajo evaluación para decirles cómo se ve lo bueno. Pregunta si tienes habilidad creíble de arquitectura empresarial y de soluciones de tu propio lado, y si tu autoridad de diseño está dotada de personal para habilitar a los equipos o meramente para sellar de goma. Discute si las decisiones significativas y difíciles de revertir realmente se prueban frente a principios acordados, o si efectivamente se delegan a cualquier proveedor que esté más cerca del problema. Considera cómo siquiera reconocerías una mala recomendación arquitectónica si no tuvieras experiencia independiente para desafiarla. Sopesa el coste de construir y retener esta capacidad frente al coste mucho mayor del bloqueo y el retrabajo que produce su ausencia. Una respuesta honesta distingue las decisiones que genuinamente puedes poseer de aquellas que actualmente tomas por confianza.

En la práctica: un ejemplo de salud y atención#

El patrimonio técnico de un fideicomiso hospitalario de agudos ha crecido orgánicamente durante dos décadas. En su corazón se sitúa un sistema de administración de pacientes ejecutándose en un sistema operativo que el proveedor dejó de soportar hace dieciocho meses; a su alrededor hay más de doscientas aplicaciones, muchas compradas departamentalmente, varias haciendo trabajos superpuestos, y nadie mantiene una lista completa. Un cuasi-incidente —un intento de ransomware bloqueado más por suerte que por diseño— impulsa a la junta directiva a hacer una pregunta que nunca antes había hecho: ¿qué, exactamente, estamos ejecutando, y qué tan expuestos estamos?

El director de información digital resiste el instinto de lanzar un único programa heroico de "reemplazar todo", y hace primero el trabajo aburrido. El fideicomiso construye una cartera de aplicaciones viva: cada sistema, su propietario de negocio, su capacidad de soporte, su coste, y su riesgo. La imagen es sobria —una quinta parte de las aplicaciones están en software no soportado, y una docena de capacidades duplicadas ya disponibles en otro lugar— pero por primera vez es visible, y las peores exposiciones van directamente al registro de riesgo corporativo donde la junta directiva puede verlas.

A partir de ese inventario, el fideicomiso toma decisiones deliberadas guiadas por un puñado de principios de arquitectura acordados. El sistema no soportado de administración de pacientes se prioriza para reemplazo, adquirido como un producto configurable con derechos contractuales de API abierta y extracción de datos para que el fideicomiso no quede bloqueado de nuevo. Las cargas de trabajo adecuadas se mueven a la nube pública, evaluadas una a la vez en lugar de por eslogan, con el carbono y la portabilidad sopesados junto al coste. Una pequeña autoridad de diseño revisa las decisiones significativas y despeja rápidamente las rutinarias. Doce aplicaciones departamentales superpuestas se consolidan a tres, y los sistemas retirados se dan de baja apropiadamente —datos migrados bajo reglas claras de retención, dependencias verificadas, usuarios informados, y solo entonces apagados.

Nada de esto hace titulares. Pero dieciocho meses después, el fideicomiso sabe qué opera, su deuda más peligrosa se está pagando según un plan financiado en lugar de esperar que desaparezca, y una nueva integración de registro de atención compartido se entrega en semanas porque los sistemas de reemplazo exponen API abiertas. El cuasi-incidente se convirtió en el momento en que el fideicomiso comenzó a gestionar su arquitectura en lugar de ser gestionado por ella.

Perspectivas sectoriales#

Startup#

Una startup de salud digital tiene el lujo de poco legado y debería protegerlo ferozmente. Construye nativo en la nube desde el principio, expón API abiertas, y trata el seguro por diseño como una funcionalidad central en lugar de un coste posterior, porque los compradores cautelosos del NHS examinarán de cerca tu arquitectura de seguridad y términos de extracción de datos. Mantén tu propia plataforma mínima viable genuinamente delgada, resistiendo la tentación de sobrediseñar para una escala que aún no tienes. Tu ruta más rápida hacia acumular deuda técnica paralizante es enviar código expeditivo bajo presión de inversores y nunca pagarlo, así que haz elecciones deliberadas y visibles sobre qué deuda asumes. Paradójicamente, diseñar para que un cliente pueda extraer sus datos e irse es lo que se gana la confianza que los mantiene.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una clínica de un solo emplazamiento, o un pequeño proveedor de tecnología de salud que ya superó la etapa de startup— carga con los mismos deberes que un gran fideicomiso pero con una fracción de los recursos y rara vez alguna capacidad de TI dedicada. Aquí la arquitectura es mayormente la disciplina de comprar bien: favorece el software como servicio de buena reputación para que el proveedor cargue con el alojamiento, la aplicación de parches, y la seguridad que no puedes dotar de personal tú mismo, y lee el contrato en busca de derechos de extracción de datos y salida antes de firmar, porque el bloqueo muerde más fuerte cuando no tienes influencia. Mantén un inventario simple del puñado de sistemas de los que dependes y sabe cuáles todavía están soportados, ya que incluso un pequeño patrimonio puede ocultar una máquina sin parches que detiene la consulta. Insiste en que los proveedores cumplan con estándares reconocidos como el Data Security and Protection Toolkit en lugar de intentar evaluar la seguridad desde cero. Cuando el efectivo es ajustado, la tentación es mantener funcionando un sistema antiguo y no soportado para evitar una factura, pero esa es una decisión de seguridad que deberías tomar deliberadamente, no por deriva.

Gran organización#

Un gran fideicomiso o proveedor carga con décadas de sistemas acumulados y no puede simplemente empezar de nuevo. La estrategia realista es la evolución disciplinada: mantén una cartera viva, pon capas abiertas y basadas en API frente a lo que debe permanecer, y paga la deuda más peligrosa según un plan financiado y priorizado en lugar de en pánicos ocasionales. Opera una autoridad de diseño que sea respetada porque habilita la entrega, no temida porque la bloquea, y haz de la deuda técnica un riesgo permanente a nivel de junta directiva con un propietario nombrado. Protégete contra el bloqueo en cada renovación, y trata la baja de servicio como trabajo real y dotado de recursos en lugar de una idea de último momento. Esta es la misma disciplina de reutilización e interfaz abierta que gobierna las plataformas operativas centrales en el Tema 5.4 — Planificación de recursos empresariales (ERP).

Gobierno#

Los organismos nacionales y regionales establecen las condiciones en las que opera todo el sector, y sus elecciones de arquitectura se propagan hacia afuera. Las cosas más valiosas que puede hacer el gobierno son exigir estándares abiertos, proporcionar plataformas nacionales reutilizables para que las organizaciones locales construyan una vez, y establecer expectativas de nube, seguridad, y sostenibilidad que eleven el piso en todas partes. Fundamentalmente, el gobierno debe financiar el trabajo nacional poco glamoroso —remediación de sistemas heredados, mantenimiento de terminología, apoyo de baja de servicio— que ninguna organización individual financiará sola pero del que todos dependen. Un estándar firmemente aplicado y suficientemente bueno, reutilizado ampliamente, vence a uno teóricamente superior implementado inconsistentemente. Este rol de administración se conecta con el Tema 9.1 — Trabajo con los gobiernos locales y nacionales y con cómo colaboran los socios en el Tema 9.0 — Colaboración con organizaciones asociadas.

Modos de fallo comunes#

• Patrimonio invisible. Ejecutar cientos de aplicaciones sin un inventario preciso, así que la exposición es desconocida, la duplicación pasa desapercibida, y la primera señal de fragilidad es un apagón o una brecha.
• Deuda oculta a la junta directiva. Mantener el software no soportado y la deuda técnica como una nota técnica al pie en lugar de un riesgo corporativo nombrado, así que nunca se financia hasta que falla.
• La nube como eslogan. Trasladar sin cambios el legado a la nube pública por principio, reubicando el problema a un coste mayor, o enredando tan profundamente datos y herramientas en un proveedor que se convierte en un nuevo bloqueo.
• La autoridad de diseño como cuello de botella. Dejar que la gobernanza de arquitectura se convierta en una puerta lenta que los equipos evaden, produciendo arquitectura en la sombra no documentada que es peor que ninguna.
• Construir cuando deberías configurar. Elegir construcciones a medida para necesidades básicas, según el precio de etiqueta en lugar del coste total de propiedad, y heredar una década de mantenimiento que no presupuestaste.
• Nunca dar de baja. Dejar sistemas obsoletos funcionando "por si acaso", cada uno una superficie de ataque, un coste de licencia, y un drenaje de mantenimiento que nadie posee.
• Seguridad añadida. Tratar la seguridad como una puerta previa al lanzamiento en lugar de una entrada de diseño, así que la superficie de ataque se establece mucho antes de que alguien la evalúe.
• Bloqueo por defecto. Firmar plataformas sin interfaces abiertas o derechos de extracción de datos, y descubrir el coste de la trampa solo cuando intentas irte.

Modelo de madurez#

Lista de verificación#

• Una cartera de aplicaciones viva registra el propietario, coste, capacidad de soporte, y riesgo de cada sistema, y se revisa regularmente.
• Los sistemas críticos no soportados e imparcheables están identificados y se sitúan en el registro de riesgo corporativo, no en una hoja de cálculo técnica.
• Un conjunto corto y acordado de principios de arquitectura se usa genuinamente para tomar y justificar decisiones.
• Una autoridad de diseño revisa decisiones significativas y difíciles de revertir y despeja rápidamente las rutinarias, habilitando en lugar de bloquear.
• La adopción de la nube se evalúa carga de trabajo por carga de trabajo, sopesando residencia, resiliencia, coste, portabilidad, y carbono.
• La deuda técnica tiene un propietario nombrado y un plan de remediación financiado, no solo extinción de incendios ocasional.
• Los sistemas duplicados y obsoletos se racionalizan, y la baja de servicio está dotada de recursos con verificaciones de migración de datos, retención, y dependencias.
• Las nuevas capacidades exponen API abiertas y versionadas para que los componentes puedan reemplazarse sin reconstruir a su alrededor.
• La seguridad se diseña desde el principio —superficie de ataque mínima, privilegio mínimo, segmentación— no se añade antes del lanzamiento.
• Las decisiones de construir/comprar/configurar se toman según el coste total de propiedad y el bloqueo, con derechos de salida y extracción de datos asegurados antes de firmar.

Fuentes clave#

• NHS England — estrategia de nube, estándares tecnológicos, y el Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — principios de diseño seguro y orientación de seguridad en la nube.
• Gobierno del Reino Unido (GDS/CDDO) — el Technology Code of Practice y la política de nube primero.
• National Audit Office — informes sobre sistemas heredados del NHS, el ataque WannaCry, y programas habilitados por TI.
• The Open Group — TOGAF, el marco de arquitectura empresarial.
• Government Digital Service — el concepto de "plataforma mínima viable" en el manual de servicio de GOV.UK y la comunidad de diseño.

Referencias#

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