Por Sergio Jiménez. Analítica Pública web.- 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 oído 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é.
En este post
podrás ver:
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.
¿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 servicios 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.
No hay comentarios:
Publicar un comentario