Cómo diseñamos una plataforma GovTech modular

Una administración no compra software: adopta una forma de trabajar durante años. Por eso una plataforma GovTech se diseña con criterios distintos a los de un SaaS comercial. Estos son los principios con los que hemos construido oGovSystem y las razones técnicas detrás de cada uno.

1. Módulos autónomos, no un monolito con pestañas

Cada módulo —transparencia, participación, presupuestos, contratos, subvenciones, obras, datos abiertos, portal corporativo, cumplimiento, anonimización, canal de denuncias y registro de lobbies— funciona por separado y aporta valor por sí solo.

Esto responde a cómo compra y decide realmente una administración:

• El presupuesto llega por fases y por áreas distintas.
• La necesidad urgente suele ser una (una evaluación, una obligación legal nueva), no doce.
• Un despliegue completo de golpe multiplica el riesgo de fracaso del proyecto.

La consecuencia de diseño es que ningún módulo puede depender del estado interno de otro. Se comunican por contratos de datos explícitos, no por acoplamiento directo.

2. Una capa de datos común y canónica

La interoperabilidad no se resuelve con integraciones punto a punto, sino con un modelo canónico: un contrato, una partida presupuestaria, una subvención o una obra se representan igual con independencia de qué sistema los originó.

Sobre ese modelo se apoyan tres capacidades:

• Ingesta: conectores hacia el sistema contable, el gestor de expedientes, la plataforma de contratación y la BDNS.
• Normalización: validación, deduplicación, códigos normalizados y series históricas coherentes entre ejercicios.
• Exposición: la misma información alimenta a la vez la visualización pública, los indicadores de evaluación y el catálogo de datos abiertos.

Esto es lo que evita el problema clásico: el mismo dato publicado con tres cifras distintas en tres sitios distintos de la web municipal.

3. Publicar una sola vez, servir en muchos formatos

Cada dato que entra en la plataforma se publica simultáneamente como:

• Página web accesible y navegable.
• Visualización interactiva con filtros.
• Recurso descargable (CSV, JSON, XLSX).
• Registro del catálogo con metadatos DCAT-AP, federable con datos.gob.es.
• Endpoint de API para reutilizadores y para otros sistemas de la propia entidad.

El coste marginal de cada formato adicional es prácticamente cero cuando el modelo de datos es común; es altísimo cuando cada módulo guarda su propia versión.

4. Cumplimiento por diseño, no como capa final

Tres marcos condicionan la arquitectura desde el primer día:

• Esquema Nacional de Seguridad: la plataforma opera bajo certificación de categoría Media, lo que implica control de accesos, trazabilidad de operaciones, gestión de registros de actividad, cifrado y procedimientos de continuidad.
• RGPD y LOPDGDD: minimización de datos, base jurídica documentada por tratamiento y anonimización previa a cualquier publicación que implique documentos con datos personales.
• Accesibilidad: el Real Decreto 1112/2018 obliga al sector público a cumplir WCAG 2.1 AA. Eso condiciona el diseño de componentes, no solo la revisión final: contraste, foco visible, navegación por teclado, tablas de datos correctamente marcadas y alternativas textuales en cada visualización.

Añadir cualquiera de las tres cosas al final de un desarrollo cuesta un rediseño completo. Por eso son restricciones de partida.

5. Anonimización como servicio interno

Publicar documentos administrativos casi siempre implica tratar datos personales. La plataforma incorpora un servicio de detección y tacha de información personal que se invoca desde cualquier módulo antes de la publicación, con revisión humana sobre las propuestas automáticas.

Es un ejemplo del patrón general: capacidades transversales expuestas como servicio, nunca reimplementadas por módulo.

6. Identidad y perfiles diferenciados

Tres perfiles con necesidades opuestas conviven en el mismo sistema:

• Ciudadanía, que accede sin fricción y de forma anónima a lo público, y con identificación electrónica (Cl@ve, DNIe) solo cuando el proceso lo exige, como una votación con validación de empadronamiento.
• Personal municipal, con roles por área y permisos granulares.
• Sistemas externos, con credenciales de máquina y ámbitos limitados.

El principio es el de mínimo privilegio, con trazabilidad completa de quién publica, modifica o despublica cada contenido.

7. Sin lock-in: los datos siempre son de la entidad

Una plataforma pública no puede ser una cárcel de datos. Por eso:

• Todo el contenido es exportable en formatos abiertos y documentados.
• El catálogo se expone por API estándar.
• Los modelos de datos están publicados.
• La salida de la plataforma es un procedimiento previsto, no un obstáculo.

Puede parecer contraintuitivo desde el punto de vista comercial. En la práctica es lo contrario: reduce la percepción de riesgo en la decisión de compra y obliga al producto a retener por calidad.

8. Rendimiento y SEO público

Los portales institucionales son, para mucha gente, la puerta de entrada a la administración. Se diseñan con renderizado en servidor, URLs estables y persistentes, metadatos por página, datos estructurados Schema.org y sitemap automático. Cuando una obligación legal cambia de ubicación, se mantiene la URL anterior con redirección permanente: romper enlaces publicados en un boletín oficial no es una opción.

Qué significa esto para una administración

En términos prácticos: se puede empezar por un módulo, desplegar en semanas con los datos migrados, sumar módulos cuando haya presupuesto y salir con todos los datos si algún día se decide cambiar de proveedor.

Puedes ver los doce módulos en la página de plataforma, o hablar con nuestro equipo sobre cómo empezar un proyecto.