Cuadro del Alquimista de Rijckaert
Director general buscando si el plan de transformación digital va mejor con datos o con documentos. Fuente.

Cuando uno empieza a comparar modelos de e-Administración empieza a ver algunas diferencias sustantivas. Una de las que me resulta más interesante es la ortientación utilitaria de los planes. Esto quiere decir, sobre qué elemento vamos a centrar la atención y las acciones en las etapas de diseño para que luego sea el elemento nuclear de la acción organizativa. En este caso hasta la fecha he encontrado dos enfoques diferenciados: los documentos y los datos. Puede parecer una disquisición filosófica, pero tanto el debate que generó este tema en el INAP social como las implicaciones reales de diseño hacen que sea, en realidad, uno de los aspectos más determintantes en el desarrollo del e-gobierno. Así que es la hora de preguntarse muy seriamente cuál es la esencia de la eAdministración, datos o documentos.

La piedra filosofal de la e-administración.

Hace años tuve la locura oportunidad de hacer un curso de diseño de arquitectura de datos. El profesor del curso insistía siempre en la primera instrucción siempre: mirar cuál es el grano. Es decir, cuál es la unidad mínima sobre la que construir esa base de datos. A decir verdad la comprensión de este aspecto hacía que un modelo fuera sencillo de hacer y sobre todo, que fuera sostenible y escalable.

El debate sobre documentos o datos es igual. Según comprendamos cuál es la materia prima indivisible, el átomo, la unidad mínima de operación, define lo versatil, sostenible y escalable del modelo de e-Administración. Es, en definitiva saber cuál es la esencia de la acción administrativa.

Sin embargo, al hablar de e-Administración pasa como con la alquimia: la tecnología es la magia, pero el elemento sobre el que operemos hará que el cambio sea para “un poco más de lo mismo” o para “hacer mucho más”.

El documento como base.

Empecemos por el elemento que ha servido como gasolina de la acción administrativa hasta ahora: el documento. Hasta la fecha la indisoluble unidad entre el documento y el dato era una realidad evidente. Un documento contiene datos y la validez del documento implica, por definición, la validez de los datos que contiene. En los casos en los que un dato tenía que ser rectificado, se precisaba un documento ulterior que lo indicara con igual o mayor validez.

Este modelo es, pese a lo que parezca, bastante seguro y eficiente. El documento tiene una firma, esa firma hace a una persona responsable de su veracidad, y es un elemento probatorio prácticamente indiscutible.

El dato como base

La disociación entre datos y soporte es un fenómeno relativamente nuevo y bastante transformador. Pensemos en lo que ha significado, por ejemplo, poder consumir películas o música sin un elemento físico que lo sustente. Por un lado, ha tenido un impacto muy severo en la industria creando todo el problema del intercambio de datos (e-mule, naposter, megapload o los torrents). Por el otro, ha permitido el afloramiento de industrias enormes, pujantes y transformadoras como Netflix o Spotify.

Este modelo aporta una enorme versatilidad, rapidez y ubicuidad. Puedes ver lo que quieras, desde donde quieras cuando quieras. Sin embargo, hay un papel importante de demandas de infraestructuras, soporte, seguridad e inversión base. Es decir, Netflix o Spotify son negocios enormes que son un éxito apuntalado en una deuda ingente (en modo de inversores), en gran medida por infraestructura y derechos. Y eso sin contar que una brecha de seguridad en Netflix no es ni la cuarta parte de grave que, por ejemplo, en el registro de la propiedad.

¿Qué hay que tener en cuenta?

En términos generales uno diría que un modelo es mejor que otro, pero realmente no es algo tan simple. Existen una serie de elementos que hacen más o menos viable una u otra opción. O, mejor dicho, hay unas condiciones que priman más una opción frente a otra

Aspectos organizativos

Lo primero a tener en cuenta es qué condiciones de la organización influyen en esta elección. Podríamos decir que una estructura basada en documentos es más viable en una organización con una estructura más descentralizada porque identifica y ordena responsabilidades. Es decir, si el ministerio A puede necesitar documentos del ministerio B para poder realizar un procedimiento, y tienen igual jerarquía y técnicas muy diferenciadas, un documento será más rápido y fiable que el modelo de los datos.

Sin embargo, si tenemos una organización con la suficiente centralización para garantizar que un modelo de datos y de seguridad se cumple en todas las condiciones y casos, el documento se convierte en un elemento más prescindible. Por ejemplo, si el ENS y el ENI tuvieran el predicamento (y la viabilidad) que el legislador esperaba, posiblemente el aspecto documental sea innecesario.

Aspectos técnicos

El segundo elemento que diría es el técnico. Un modelo basado en documentos tiene una dependencia tecnológica menos importante que un modelo orientado en datos. ¿Por qué? Porque un documento como norma general es autoexplicativo y relativamente autonomo. Es decir, es más fácil consultar una hoja excel o un texto en word (si tienen un formato más o menos estándar y tienes una herramienta ofimática) que hacer una llamada a los datos via API o webservice.

La orientación a datos requiere, como mínimo entornos para poder leerlos y procesarlos. Esto hace que, incluso con entornos estandar, utilizar productos (o crearlos) bastante menos estandar y masivos que las herramientas ofimáticas. Esto precisa que los datos tengan una cierta homogeneidad para que su acceso y manejo sea relativamente estándar e interoperable. En caso contrario nos encontramos con dos escenarios negativos no necesariamente exclutentes. En primer lugar, un entorno fragmentado, es decir, diferentes aplicaciones para hacer procesos similares. Por otro lado puede haber entornos masivos poco competitivos: una plataforma general, poco adaptada a especificidades de alta dependencia.

Si esa normalización y estandarización se garantiza y se permite una interacción a nivel de API, es evidentemente más rápido.

Aspectos normativos

Otro plano a tener en cuenta es el normativo. El modelo normativo-administrativo incide en las condiciones generales de funcionamiento. Es decir, un país con derecho administrativo precisa definir ex-ante las características del procedimiento con gran detalle. Esto significa una regulación, entre otras cosas, del mecanismo que certifica la validez de actos que se suponen auténticos. En este sentido, un documento como decía, es más “estable” y autoexplicativo. Defines los atributos del documento, que es indiferente a la tecnología (si es estandar) y listo. Una vez que tienes un mecanismo que acote autenticación y datado, no necesitas mucho más.

Sin embargo regular los atributos de elementos tan volátiles (y con unas definiciones más complejas) como los datos es más complicado. Lógicamente habría que validar cada uno de los registros y el conjunto de las bases de datos. A mi (y no soy ni mucho menos un experto, vaya por delante) me cuesta mucho imaginar la prescripción normativa de la validez de bases de datos y registros “en crudo”, por complejidad y por la propia manera de actuar del legislador aquí.

Evidentemente, puedes optar por un enfoque más mixto, aligerar el control de los datos y cargarlo en los documentos, pero eso supone, a fin de cuentas, centrarse en documentos.

Aspectos culturales

Por último tenemos los aspectos culturales. En mi experiencia sobre este debate hay un núcleo de personas muy aferradas al documento. Entienden que es este el que asegura y garantiza el cumplimiento de la legalidad de la acción pública. Es decir, cuesta mucho disociar el contenido (datos) del continente (documento), centrando el control en el último.

Es cierto que, en términos técnicos un documento (más aún si está estructurado) no deja de ser una colección de datos. Sin embargo, tenerlos en un solo bloque y que recojan toda la información que permita controlarse de manera sencilla por cualquiera que lo pueda leer, democratiza mucho el control.

El modelo de datos requiere una importante confianza en la validez de todos los datos y en los mecanismos de control que la asegura. Auditorías de seguridad, de control de datos, logs, confiar en que quede constancia y atribución de ataques…

Implicaciones a futuro.

Con todos estos condicionantes ya nos hacemos una idea de qué podemos elegir. Ahora la cuestión es plantearnos qué supone a futuro cada uno de estos enfoques.

Infografía de síntesis
Infografía que recoge los datos del artículo

Escalabilidad

El modelo basado en datos puede crecer y replicarse más fácilmente. Una vez que tenemos la arquitectura, hacerla crecer, almacenarla y trasladarla a otros sitios es más sencillo. Es más, si utilizamos estas arquitecturas para integrar diferentes fuentes y datos podemos generar más datos. Es más maleable.

El modelo orientado en documentos tiene limitaciones importantes. El crecimiento se basa en la capacidad de crear y validar documentos aislados, que son también la base de la validez y el intercambio. Es decir, podemos aprovechar la arquitectura hasta cierto punto para generar otros documentos, pero limitados al ritmo de generarlos.

Interoperabilidad

La interoperabilidad es el siguiente punto. En términos reales un modelo de datos para funcionar debe ser interoperable. Si no lo es, acaba siendo un modelo de documentos. Si no podemos intercambiar datos, tenemos que generar documentos para poder enviarlos y consultarlos. Esto es una condición. En caso de que no se dé, el modelo tendrá datos hasta cierto momento. Si una administración tiene un intercambio de datos de padrón en casi todo su territorio, pero en otros no, al final ahí acaba el modelo hacia datos. La interoparabilidad “automática” requiere una definición homogenea de modelos de datos, tipos, conservación, ubicación…

Sin embargo un modelo de documentos es “altamente interoperable” pero poco automático. Pocas cosas son más infalibles que leer un documento y entrar los datos a mano. Sin embargo, coincidiremos que es lento. Existe la posibilidad de extraer datos de un documento estructurado y sacar los datos. Sin embargo, aunque eso automatiza la captura genera una ralentización que tiene un impacto en términos de tiempo. No es lo mismo hacer una llamada de API que permita bajar 50000 registros que descargar via webservice 50000 documentos, extraer los datos y subirlos.

Reutilización y transparencia

La reutilización de los documentos es especialmente baja. Es decir, incluso en modelos restructurados, extraer datos y operarlos es algo complejo. Sin embargo, también es cierto que hay determinados niveles de información cuyo reflejo en simples datos es poco relevante. Por ejemplo, documentos relativos a un contrato público o a una certificación de unas instalaciones, el documento tiene un valor superior. Evidentemente, estos documentos pueden, en muchos casos, reconstruirse a partir de datos, pero normalmente no son aceptados de la misma manera. Podéis verlo si presentáis el CSV de vuestro título universitario en un proceso selectivo.

Sin embargo, la generación, actualización y mantenimiento de datos es especialmente complicado si no hay una arquitectura transaccional que lo haga. Es decir, si tienes un sistema que, por ejemplo, lleve toda la gestión de personal del ayuntamiento que genere todos los datos de remuneraciones, mantener los datos es fácil. Sin embargo, si esto no está automatizado, es un martirio hacer esta gestión y luego subir los datos. Un poco lo que pasa con los contratos. Lo malo es que, normalmente, estas estructuras son especialmente grandes, caras y lentas de instaurar.

Conclusión ¿Y tu de quién eres?

En términos digitales y técnicos un modelo de eAdministración basado en datos es superior. Más rápida, más ágil, más versatil, con más potencial. Eso no evita que genere importantes problemas a la hora de generar infraestructuras, acceso, fiabilidad y mantenimiento.

Por otro lado, la eAdministración más centrada a documentos tiene una menor explotabilidad tecnológica, pero un coste, inversión y visibilidad mayor.

La cuestión, como suelo decir, no es tanto optar por un modelo u otro, sino ser consecuente con ellos. En el caso de España, en mi opinión, la apuesta es clara por los documentos, pero ni la legislación ni el plan de transformación digital (ni parte del discurso político) están diciendo lo mismo. En ese caso nos encontramos una importante frustración e impotencia entre los que se creen lo que se dice y se encuentran lo que se hace.

Si tuviera que apostar, iría a por el modelo de datos, pero esto supone un tiempo de travesía en el desierto importante. No sólo por la lentitud de los resultados, sino por la necesidad de centralizar, normalizar y conceptualizar una estructura enorme. Si queremos llegar a ese auténtico cambio, no creo que podamos hacerlo de otra manera.


https://analiticapublica.es/wp-content/uploads/2019/01/docus-o-datos-410x1024.pnghttps://analiticapublica.es/wp-content/uploads/2019/01/docus-o-datos-150x150.pngSergio JimenezTransformación Digital Para Administraciones PúblicasDirector general buscando si el plan de transformación digital va mejor con datos o con documentos. Fuente. Cuando uno empieza a comparar modelos de e-Administración empieza a ver algunas diferencias sustantivas. Una de las que me resulta más interesante es la ortientación utilitaria de los planes. Esto quiere decir,...El blog de  Sergio Jiménez sobre Transformación Digital para Organizaciones Públicas