¿Una administración reactive? Un modelo por y para la sociedad del dato

Con la vuelta al cole yo he continuado con mi curso de Ciencia de Datos, en el que me toca este semestre estadística y big data. El caso es que estaba iniciando el módulo de big data (que ya os digo que me va a costar) me encontré con algo que había oido en el pasado pero que no había mirado nunca con detalle: el Manifiesto Reactive. Este documento establece unos principios para el diseño de sistemas informáticos orientados a mejorar la experiencia de usuario (UX) en el tiempo del big data, los sistemas dispersos y la interconexión constante. Así que pensé¿una Administración reactive?

Dirá quien lea esto “madre mía, menudo rollo de ingeniería” y, sin embargo, creo que aplicar los principios Reactive para el diseño de la Administración (y de la eAdministración) es recomendable para resolver parte de sus problemas. Además, me parece que acabaremos con un modelo así, sea mañana o de aquí a 20 años. Ahora verás por qué.

La ilustración del barco de Teseo que ilumina este artículo.
El barco de Teseo, que cambió tudas sus piezas pero siguió siendo el mismo barco. Fuente

¿Qué es el manifiesto Reactive?

El manifiesto Reactive es una guía de principios orientados a crear arquitecturas adaptadas a la UX. Parte de la necesidad de adaptarse a entornos complejos como los actuales. Cada vez más es frecuente (ya es lo normal) que un servicio digital grande sea el cúmulo de múltiples fuentes. Datos, sistemas y herramientas de procesado no se ubican en el mismo entorno ni en la misma estructura. La pelicula que estamos viendo por streaming puede tener parte de su contenido en un servidor, parte en otro, y su ensamblaje o la asignación de colas depende de sistemas ubicados en otros espacios. Esto es enormemente eficaz a la hora de asegurar el funcionamiento.

Sin embargo, cualquiera familiarizado con aparatos sabe que la probabilidad de averías aumenta exponencialmente con cada elemento nuevo que se introduce. Una lavadora con 3 programas tiene menos probabilidades de averiarse que una de 15. Igualmente, en un sistema distribuido, hay más probabilidades de encontrar fallos o de desajustarse que un sistema simple.

Aquí entra el tema del manifiesto Reactive: principios de arquitectura a seguir no solo para evitar fallos de funcionamiento, sino para mejorar al máximo la experiencia de las personas. Se trata de cosas como que tarde más o menos lo mismo en hacer lo mismo, tener siempre el mismo resultado ante las mismas operaciones, que no se pierdan decisiones o peticiones…

¿Cuales son estos principios?

Responsividad

Un servicio debe ser responsivo: responder a las peticiones de las personas. Si quieres ver un capítulo de “La casa de papel” el sistema debe garantizar que veas ese capítulo cuando lo pidas y sin cortes. Es la base de todo y, posiblemente lo más difícil de lograr. Sólo es posible si se consiguen los otros principios.

Las administraciones públicas son responsivas a medias. En el plano off-line, nos encontramos con que muchas veces el reconocimieto de un derecho o recibir una prestación llega tarde. Son casos como las listas de espera eternas de duración indefinida en muchas cuestiones que son vitales. Cosas como las ayudas de la dependencia o las legiones de interinos dan buena cuenta de ello. En el plano on-line nos encontramos con que la capacidad de responder supera con mucho las obligaciones ciudadanas. Es el caso del ROLECE, como por ejemplo, facturación o contratación electrónica: tenemos obligados que no tienen medios físicos con los que cumplir su obligación.

Resiliencia.

La resiliencia es la capacidad del sistema de sobreponerse a los errores y fallos. Es decir, cuando un componente falla hay otro u otros que pueden hacerse cargo de la tarea. Esto se hace a través de:

  • réplica: sistemas que hacen funciones similares)
  • aislamiento (poder funcionar aislando el elemento defectuoso)
  • delegación (el sistema defectuoso puede enviar a otro sus peticiones).

Es decir, si se rompe algo (sea más o menos importante) el sistema sigue funcionando.

En el caso de la Administrción pública nos encontramos con el triste ejemplo de la pandemia. La caída o saturación de determinados sistemas ante la demanda ha supuesto un fallo general en momentos puntuales. En lo digital encontramos que recursos básicos no parezacan sustituibles. Si se cae Clave, se cae gran parte de la administración de España a nivel estatal, autonómico o local. Esto ocurre en no pocos elementos también a escala doméstica: si no te entra autofirma, olvídate de hacer trámites en múltiples portales.

Elasticidad

El sistema debe ser capaz de poder adaptar su rendimiento a la escala de la demanda. Para ello necesita disponer de los recursos para poder gestionarlo y evitando cuellos de botella. No encontraremos a Twitter diciendo “espera para tuitear que hay demasiada gente hablando de Trump”.

En la administración pública la elasticidad es la que nos dan los recursos humanos y tecnológicos que hemos montado. El atasco del Ingreso Mínimo Vital es un claro ejemplo de esto: miles de personas demandando un derecho que tiene cierta complejidad gestionado por una cantidad limitada de personas. Es potencialmente imposible evitar, con nuestro planteamiento estos problemas que, lamentablemente, son frecuentes. Un nuevo trámite, un nuevo derecho u obligación, un requisito para acceder a algo, son cuestiones relativamente frecuentes que demandan elasticidad.

En el “on line” pasa cuando hay un pico: la caída del servicio de la renta o de las inscripciones a oposiciones para la AGE . Aunque hay casos en los que esto es inevitable con unos recursos limitados debe haber maneras de evitar que la saturación signifique una caída. Esto se puede hacer con sistemas de cascadas o de gestión de colas, o con estructuras descentralizadas.

Basado en mensajes.

El sistema basado en mensajes es la base de este tingaldo. Los diversos agentes que hay se comunican entre ellos de manera asíncrona. Esto permite el aislamiento (un sistema no implica a los demás) y permitiendo localizar la ubacación de cada dato y sistema. A raíz de este modelo podemos escalar un sistema, gestionar colas de demandas y evitar los bloqueos.

Aquí se da una confluencia de fallos de la eAdministración, al menos en España. La estructura multinivel de los gobiernos , una una interoperabilidad altamente compleja y “dictada” y la falta de herramientas estandar, junto con la creación de proyectos titánicos e ingobernables como el Registro Único, Habilita o Notifica nos llevan en sentido contrario. No puedo imaginar lo que puede suponer, el día que llegue el Registro Único, una caída de dicho registro. Se que algunos dirán “pues que no se caiga”…Pues malas noticias, los sistemas centralizados con mucha demanda se caen y cuando se caen lo hacen estrepitosamente. No tenemos un sistema de mensajes sencillo manejable y universal (que no se crea por ley, sino haciendo herramientas más eficaces) es que nos lanzamos de cabeza a herramientas en el sentido contrario: mas grandes, más centralizadas, más complejas.

Infografía que recoge los principios de la administración reactive
Infografía sobre los sistemas reactivos que puede asumir la Administración.

¿Por qué es necesario hacer una Administración reactive?

El enfoque de administración reactive es necesario para adaptar la administración a nuestra sociedad. La complejidad, volatilidad, masificación y la fluidez de datos nos llevan a esto.

Aumento de estructuras y de servicios

La administración crea cada vez más servicios y elabora estructuras más amplias y complejas. No hablamos de una aumento del tamaño del sector público, sino de lna diversificación y especialización para gestionar asuntos específicos. Esto supone la imbricación de diferentes actores gubernamentales en tramos administrativos.

La administración reactive trabajaría en un entorno de agencias distribuidas a lo largo de diferentes administraciones es, precisamente, basarnos en la estructura de mensajes. Es cada vez más difícil encontrar un sistema que tenga todos los datos para operar de manera eficiente. Cada vez tiene menos sentido pedir a la ciudadanía que transmita sus propios datos a diferentes agencias. El intercambio de mensajes es la solución.

Liquidificación de la sociedad

En una sociedad marcada por el consumo de información tan rápido los picos de demanda son algo inevitable. Evidentemente podemos optar por meter estructuras más redundantes para evitar el sonrojo de que se caiga un servicio. La opción más lógica sería minimizar las grandes estructuras a servicios muy básicos (como la Plataforma de Intermediación) con una estructura responsiva y elástica y luego abrir la comunicación entre diferentes agencias y organizaciones.

Interdependencia administrativa

No es lógico tener cientos de administraciones con cientos de datos repetidos y repartidos a lo largo de todo el mundo. La disponibilidad de datos mínimos necesarios para cada caso y la capacidad de intercambiar mensajes agilizaría la arquitectura de cada organización y la colaboración administrativa. Tener un registro de habilitados será posiblemente menos eficaz que tener una identificación de cada organización de sus habilitados y que, al realizar el servicio, se verifique esa legitimidad. Además, tardaríamos muchos menos años de lo que está tardando habilita).

Adaptabilidad a la organización

Siempre recuerdo a aquel catedrático de derecho que decía que la estandarización tecnológica no era una imposición. Me temo que ese catedrático nunca se ha encontrado con esas situaciones de programas o datos deprecados o dejados de mantener. Lo cierto es que la tensión entre estandarización y adaptabilidad de un sistema de información es un clásico.

Un sistema basado en mensajes permitiría que cada agencia u organización genere los sistemas que necesite y comunique lo necesarios a otras. En la administración reactive, la definición de los esquemas de mensajes (en lugar de limitarnos a soltar un chorrazo de especificaciones de interoperabilidad) permitiría abordar un modelo tecnológico más adaptado a cada caso.

Impulsar la profesionalización y especialización.

Si podemos crear un sistema en el que cada organización genere sus propios recursos digitales podemos explotar más sus capacidades. No paramos de hablar de ciencia de datos, de algoritmos, de IA, pero esto suele requerir una especialización en los datos acumulados y en su uso difícilmente compatible con grandes sistemas estandar. Es más, ¿Cómo vamos a hacer un sistema de interoperabilidad que aborde todos los modelos de datos que puedan necesitar todas las organizaciones? Aunque fuera posible ¿sería viable? Mi opinión es que no.

Esto no significa que cada organización tenga exclusivamente sus sistemas: se pueden crear modelos compartidos, hubs, estructuras en la nube, etc… pero hacer un cafe para todos como se propone hasta ahora no parece viable y, creo, ni deseable.

Capacidad de responder

La capacidad de responder de la administración de cara a la ciudadanía es un todo. El problema es que la Administración se ha centrado en España en digitalizar todo y luego ver qué ofrece, en vez de ir ofreciendo y tomando decisiones de por donde avanzar. Esto hace que los trámites más simples sean complejos y que la capacidad de respuesta del sistema sea el más lento necesario.

Este enfoque es más parecido al de otros países (Dinamarca, Australia, Reino Unido, Estados Unidos) que aparentemente van bien en sservicios digitales han abordado sus proyectos de esta manera. A lo mejor me equivoco y a partir de abril todo, absolutamente todo es más fácil. Sin embargo, tengo mis dudas no sólo de la estabilidad de los titánicos sistemas españoles, sino del impacto en la satisfacción de la ciudadanía con sus resultados.

Hagamos una administración reactive

Cuando se habla de eAdministración para cambiar las administraciones hablamos generalmente de cambios “intermedios”. No sólo procesos y trámites, sino también estructuras (generalmente internas). Lo cierto es que creo que debemos ir más allá y cambiar el propio concepto de la administración. Organizaciones más pequeñas, más especializadas, estructuras de datos más compartidas y mecanismos estandar de colaboración. Esto permitiría posiblemente resolver gran parte de estos problemas que hemos señalado y que no parece que vayan a minimizarse.

Evidentemente un cambio así llevará (en caso de darse) muchos años y, para los que les gusta el término resistencia al cambio, aquí les daría juego. En todo caso, apuestas como la Oficina del Dato puede ser de gran interés. Si consiguiéramos que la transferencia tecnológica, la colaboración flexible y arquitecturas más abiertas a compartir (más APIs y menos plataformas) podríamos hacer una administración más adecuada para lo que está por venir. Quizá sería cambiar, como en el barco de Teseo todas las piezas, pero es el espíritu (y no las propias piezas) las que hacen que ese barco sea el de Teseo.

Comparte este artículo

Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email

Acerca del autor

Regístrate y consigue los últimos artículos en tu mail.

icono mail suscribete
SUSCRIBIRME

Deja una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.