Digitalizarea statului: de ce nu începe cu „cum arată site-urile”, ci cu arhitectura de date

Problema este că există un risc major să facem exact ce am mai făcut și în trecut: să punem „ruj” peste o arhitectură veche, fragmentată și incoerentă.

SUDD rezolvă în principal stratul de prezentare – ceea ce vede utilizatorul. Dar dacă, în spate, rămân aceleași baze de date izolate, aceleași sisteme care nu comunică între ele și aceleași procese rupte de realitatea digitală, atunci nu facem decât să uniformizăm interfețele peste același haos structural.

Adevărata problemă – și adevărata miză – este arhitectura fundamentală a datelor și a interoperabilității.

Lecția Estoniei: de jos în sus, nu invers

Estonia nu a început cu „hai să arate toate site-urile la fel”. A început cu:

• identitate digitală solidă pentru cetățeni și companii,

• registre de bază interconectate (populație, firme, proprietăți),

• o infrastructură de schimb de date între instituții (X-Road),

• abia apoi servicii publice construite peste această fundație.

Rezultatul? Un stat care funcționează digital pentru că are o coloană vertebrală de date și relații, nu pentru că are interfețe frumoase.

Ideea de bază: statul ca sistem de entități și relații

Conceptul poate fi explicat simplu:

1. Fiecare entitate are un identificator unic și stabil

   • Persoană → CNP (sau echivalent digital modern)

   • Firmă → CUI

   • Instituție → ID unic (primărie, școală, spital etc.)

   • Roluri → entități în sine (medic, profesor, elev etc.)

2. Datele sunt stocate la nivelul fiecărei entități, relațiile sunt primul strat de arhitectură
   Informația „despre” o persoană, o firmă sau o instituție rămâne la entitatea respectivă, acolo unde este corect să fie întreținută și actualizată. La nivel central nu se dublează totul, ci se construiește în primul rând un strat de relații între entități, cu valabilitate în timp:

   • Persoana X este pacientul medicului Y între data A și data B

   • Persoana X este elev la școala Z între anul A și anul B

   • Persoana X este profesor la școala Z între anul C și anul D

   • Firma F are o relație contractuală cu instituția I între data A și B

   Când „centrala” are nevoie de informații, ea le cere de la entitatea sursă, strict pe cele relevante pentru acel scop, nu copiază și nu agregă inutil „zgomot” de date.

3. Statul devine un graf de entități și relații, nu un depozit de copii de date
   Arhitectura nu se bazează pe baze de date paralele care duplică informația, ci pe un sistem în care știi cine este cine și ce relații există între entități, iar datele concrete sunt furnizate la cerere de sistemele care le administrează legitim.

4. Comunicarea se face prin API-uri standardizate
   Toate instituțiile vorbesc între ele prin același limbaj tehnic, cu autentificare, autorizare, trasabilitate și audit.

5. Abia peste această fundație construim interfețele și serviciile
   SUDD, portaluri, aplicații mobile și ghișee digitale devin doar „fețe” diferite ale aceluiași sistem coerent din spate.

De ce contează ordinea?

Pentru că, dacă începem cu interfețele, riscăm să:

• cheltuim bani pe „fațade”,

• păstrăm aceleași sisteme care nu comunică,

• și să plătim din nou peste câțiva ani pentru adevărata reformă.

Dacă începem cu arhitectura de date și interoperabilitate, atunci:

• orice aplicație nouă se leagă natural la sistem,

• orice instituție nouă intră într-un ecosistem deja coerent,

• orice serviciu nou devine mai simplu, mai ieftin și mai sigur de construit.