Arhitectura unei administrații coerente

O administrație poate avea multe aplicații și totuși să ofere servicii fragmentate. O cerere traversează instituții, competențe, registre și contracte pe care cetățeanul nu ar trebui să le coordoneze singur. Problema nu este doar lipsa tehnologiei, ci dificultatea de a lua decizii coerente asupra unui sistem instituțional distribuit.

Arhitectura enterprise (EA) este disciplina care leagă obiectivele publice de capabilități, servicii, procese, informații, aplicații și infrastructură. Ea descrie situația curentă, starea-țintă și tranziția dintre ele. În acest context, „enterprise” înseamnă instituția sau ansamblul de instituții care livrează un rezultat public, nu o companie și nici un produs IT.

Public Framework propune un vocabular și un metamodel comun, PFML, pentru a păstra aceste relații explicite și verificabile. Necesitatea unei capacități instituționale de arhitectură este susținută de diagnosticul OECD pentru România și de practicile internaționale. Superioritatea Public Framework față de alternative nu este însă demonstrată de aceste surse; trebuie evaluată separat. ^{[1] [6]}

Recomandarea acestui document este o adoptare graduală: un mandat clar pentru un pilot, un serviciu interinstituțional delimitat, o arhitectură minimă utilizabilă, reguli de decizie și o evaluare a rezultatelor. Nu propunem cartografierea întregului stat înaintea oricărei îmbunătățiri și nu promitem economii fără măsurare.

Ce arată cercetarea despre România

Analiza OECD din 2023 recomandă consolidarea conducerii și coordonării guvernării digitale, gestionarea investițiilor pe întregul ciclu de viață, dezvoltarea competențelor, responsabilități clare pentru date și o abordare unitară a serviciilor. Recomandările privesc capacitatea de a transforma administrația, nu simpla achiziție de sisteme. ^[1]

Nota de țară din Digital Government Outlook 2026 oferă un reper mai recent publicat: România are 0,24 în Digital Government Index 2025, față de media OECD de 0,70; în OURdata Index are 0,59, peste media de 0,53. Există deci atât decalaje, cât și progrese, iar un diagnostic credibil trebuie să le recunoască pe ambele. ^[2]

Limită de interpretare: datele ediției 2025 acoperă anii 2023–2024. DGI măsoară fundamentele guvernării digitale, iar OURdata robustețea politicilor de date deschise. Niciunul nu măsoară direct calitatea fiecărui serviciu, maturitatea EA sau impactul Public Framework. Nu putem deduce dintr-un scor național că un anumit instrument va produce automat o îmbunătățire.

Unde intervine arhitectura

Un proiect local poate optimiza o etapă și transfera costul către altă instituție sau către solicitant. Un registru poate avea un API funcțional, dar definiții incompatibile cu ale consumatorului. Un serviciu poate fi mutat în cloud fără simplificarea procedurii. Acestea sunt mecanisme de risc, nu constatări de audit despre fiecare instituție românească.

EA face vizibile dependențele înaintea deciziei de investiție: cine are mandatul, cine deține serviciul, ce date sunt necesare, ce capacități există deja și cine suportă costurile schimbării. Valoarea sa trebuie verificată prin deciziile îmbunătățite și rezultatele serviciului.

Lanțul cauzal propus este: cunoaștere comună → decizii coordonate → implementare mai coerentă → rezultate publice măsurabile. Fiecare legătură are condiții: modele actualizate, oameni competenți, autoritate de decizie și resurse pentru schimbare. Diagramele singure nu produc rezultatul.

• Pentru guvern: vizibilitate asupra portofoliului, dependențelor dintre reforme și capacităților reutilizabile; o bază comună pentru prioritizarea investițiilor.
• Pentru ministere: coordonarea instituțiilor subordonate fără uniformizarea artificială a tuturor proceselor; identificarea componentelor comune și a particularităților legitime.
• Pentru instituții: cerințe mai clare, analiză de impact, continuitatea cunoașterii și o relație mai echilibrată cu furnizorii.
• Pentru cetățeni și firme: potențial pentru mai puține documente și deplasări, termene mai previzibile și servicii accesibile. Acestea sunt obiective de evaluat, nu beneficii deja obținute.

Guvernul canadian folosește criterii comune de arhitectură în evaluarea inițiativelor, atât la nivel guvernamental, cât și departamental. GDS cere rezolvarea problemei complete a utilizatorului, echipe multidisciplinare, definirea succesului și publicarea performanței. Exemplele arată cum poate fi conectată arhitectura la livrare; nu justifică importarea mecanică a unui model administrativ. ^{[6] [8]}

Documentul folosește trei tipuri de surse: diagnostice despre guvernarea digitală, cadre normative și de practică și evaluări independente ale măsurării rezultatelor. Aceste categorii răspund la întrebări diferite. O recomandare nu este o evaluare de impact; existența unui cadru nu dovedește succesul implementării.

Auditul GAO din 2012 asupra a 27 de agenții este relevant tocmai prin avertismentul său: toate definiseră integral sau parțial obiective pentru arhitectură, 11 stabiliseră integral sau parțial metode ori indicatori, dar numai 5 măsuraseră și raportaseră integral sau parțial rezultate și beneficii. Este o constatare istorică, nu un scor actual al administrației SUA. ^[7]

Concluzia rezonabilă este că arhitectura are nevoie de mecanisme de realizare și verificare a valorii. Nu este rezonabil să atribuim EA toate economiile unui program de consolidare IT sau să extrapolăm procente dintr-o țară în alta.

Pentru Public Framework rămân deschise întrebări empirice: este PFML suficient de expresiv? Este învățat și întreținut cu un efort acceptabil? Ajută echipele să găsească dependențe relevante? Este mai util decât instrumentele deja folosite? Rezultatele negative și costul administrativ trebuie publicate alături de reușite.

Cadrul European de Interoperabilitate distinge patru niveluri, susținute de guvernanță. O integrare funcționează durabil numai dacă sunt tratate împreună. ^[3]

EIRA oferă o arhitectură de referință și building blocks pentru proiectarea serviciilor publice interoperabile. Public Framework trebuie să documenteze mapările relevante, nu să declare compatibilitate doar pe baza asemănării termenilor. ^[4]

Regulamentul (UE) 2024/903 instituie cadrul pentru interoperabilitatea transfrontalieră a serviciilor publice digitale transeuropene. Evaluările de interoperabilitate se raportează la stabilirea unor cerințe obligatorii care afectează această interoperabilitate, în condițiile regulamentului. Nu orice proiect IT intră automat în aceeași obligație, iar regulamentul nu impune adoptarea Public Framework. ^[5]

Modelele pot organiza dovezile necesare unei evaluări, dar nu înlocuiesc analiza juridică, evaluarea de securitate ori obligațiile de protecție a datelor. Reutilizarea nu înseamnă acces nelimitat la date.

Public Framework propune o reprezentare comună a relațiilor dintre mandat, instituție, serviciu, proces, informație și tehnologie. Diferențiatorul urmărit este trasabilitatea administrativă: de ce există un serviciu, cine răspunde de el și ce trebuie schimbat când se modifică o regulă sau o dependență.

PFML este limbajul de modelare al inițiativei. Un model util trebuie să permită referințe stabile, versiuni, proveniența informațiilor și identificarea responsabilului pentru actualizare. Aceste cerințe reprezintă criterii de evaluare a cadrului și instrumentelor, nu o declarație că orice funcție este deja implementată sau verificată.

Ipoteza de testat este că un metamodel adaptat administrației reduce ambiguitatea și efortul de coordonare. Dacă pilotul arată că profilarea unui standard existent rezolvă aceeași problemă cu un cost mai mic, acea opțiune trebuie luată în considerare. Un limbaj nou nu este un obiectiv în sine.

Propunere de organizare, nu descrierea unui mandat existent. Guvernul stabilește regulile comune; ministerele coordonează domeniile; instituțiile dețin modelele și rezultatele serviciilor. Coordonarea nu presupune o bază centrală cu toate datele operaționale și nici aprobarea centrală a fiecărei modificări locale.

Pentru pilot, un grup de arhitectură multidisciplinar ar reuni decidentul responsabil, echipa serviciului, arhitectul, specialistul juridic, responsabilul cu datele, securitatea și achizițiile. Furnizorul contribuie tehnic, dar nu substituie responsabilitatea instituțională.

Revizuirea trebuie să fie proporțională cu riscul. Modificările locale care respectă regulile comune pot avea un traseu simplificat; schimbările interinstituționale, datele sensibile și dependențele critice necesită evaluare comună. Excepțiile se motivează, se aprobă de persoana competentă și primesc un termen de reexaminare. Conflictele de interese se declară, iar deciziile și alternativele respinse se păstrează.

Guvernanța inițiativei Public Framework trebuie separată de guvernanța unui serviciu public. Menținătorii cadrului pot propune versiuni și reguli, dar nu pot atribui competențe legale instituțiilor. Recunoașterea sau adoptarea oficială ar necesita un proces distinct.

Arhitectura trebuie introdusă în punctele în care se schimbă decizii, nu adăugată ca document justificativ după contractare. Propunem patru porți de decizie, folosind pe cât posibil mecanismele existente:

1. Înainte de finanțare: problema utilizatorului, rezultatul urmărit, situația curentă, opțiunile de reutilizare și costul total sunt comparate. Se decide dacă investiția este justificată.
2. Înainte de achiziție: cerințele serviciului, datele, interfețele, securitatea, accesibilitatea, drepturile de utilizare și condițiile de ieșire sunt explicite. Se decide ce se cumpără și ce rămâne responsabilitate internă.
3. Înainte de acceptanță: livrarea este verificată față de cerințe, inclusiv integrarea, migrarea, documentația și capacitatea operațională. Acceptarea unei diagrame nu ține loc de testarea serviciului.
4. În exploatare: indicatorii și costurile sunt revizuite, modelul este actualizat, iar componentele depășite pot fi retrase controlat.

Fiecare decizie păstrează un set minim: opțiuni analizate, argumente, responsabil, versiunea modelului, riscuri, excepții și data revizuirii. Contractele ar trebui să prevadă livrarea documentației în formate reutilizabile și transferul cunoașterii, în limitele drepturilor contractuale și ale legislației aplicabile.

Costul total include modelare, instruire, integrare, migrare, licențe, securitate, operare și retragerea sistemelor vechi. Nu considerăm „economie” o cheltuială mutată la altă instituție sau o sarcină transferată cetățeanului.

Propunem un pilot pe un serviciu interinstituțional, ales după relevanța pentru utilizatori, disponibilitatea datelor, sprijinul conducerii și posibilitatea de a observa rezultate. Nu este anunțul unui pilot deja contractat.

Etapa 1 — Mandat și bază de comparație

Se stabilesc proprietarul serviciului, instituțiile participante, problema delimitată, responsabilitățile, resursele și criteriile de oprire. Se măsoară traseul actual, inclusiv canalele asistate, întârzierile, completările și costurile. Se documentează ce nu poate fi măsurat încă.

Etapa 2 — Model minim și verificare

Echipa modelează temeiul legal, actorii, pașii, datele, registrele, aplicațiile și dependențele relevante pentru problema aleasă. Funcționarii care execută procedura și utilizatorii validează modelul. Se verifică dacă PFML poate exprima cazurile fără ambiguități și ce informații rămân în afara sa.

Etapa 3 — O schimbare implementabilă

Se alege o îmbunătățire concretă: eliminarea unei verificări redundante, clarificarea unei responsabilități sau reutilizarea legală a unei date. Se compară alternativa cu și fără modelare și se implementează numai după verificările necesare. Un exemplu de autorizare este ilustrativ; procedura reală și temeiul ei trebuie stabilite în pilot.

Etapa 4 — Evaluare și decizie

Se compară rezultate la volume, complexitate și niveluri de calitate similare. Dacă este posibil, se folosește un serviciu comparabil sau o introducere etapizată pentru a separa efectul schimbării de sezonalitate, legislație ori personal suplimentar. O comparație simplă înainte/după nu dovedește singură cauzalitatea.

Extinderea se justifică numai dacă există o îmbunătățire relevantă, costuri de întreținere acceptabile, responsabilitate instituțională și niciun risc critic nerezolvat. Pragurile cantitative se convin înainte de implementare, după măsurarea bazei inițiale. În lipsa acestor condiții, se revizuiește sau se oprește abordarea; nu se extinde pentru a justifica investiția deja făcută.

Tabloul de evaluare propus măsoară rezultate, nu producția de documente. Pentru fiecare indicator se fixează definiția, sursa, perioada, responsabilul și limita de interpretare înainte de intervenție. Recomandarea GAO de a utiliza indicatori repetabili, semnificativi și legați de obiective este esențială aici. ^[7]

Economiile bugetare, costurile viitoare evitate și timpul eliberat se raportează separat. Timpul economisit de un funcționar poate crește capacitatea de lucru fără să reducă bugetul. O investiție viitoare evitată este un scenariu contrafactual, nu numerar recuperat.

Beneficiul net se evaluează pe un orizont declarat, incluzând toate costurile incremental atribuibile și analiza sensibilității la volum, durată și adopție. Nu dublăm același beneficiu la două instituții. Orice monetizare a timpului cetățeanului trebuie să declare ipotezele și să fie raportată separat de bugetul public. Acest whitepaper nu stabilește un randament garantat sau un efect asupra PIB.

Evitarea unei noi birocrații

Un metamodel excesiv poate consuma mai mult decât valoarea deciziilor pe care le sprijină. Contramăsura propusă este un set minim de artefacte, proporțional cu riscul și revizuit după utilizarea reală. Un model nefolosit trebuie simplificat sau retras, nu întreținut ritualic.

Evitarea unui nou tip de dependență

Portabilitatea trebuie probată prin export, import și păstrarea sensului relațiilor, nu doar prin disponibilitatea unui fișier. Licențele, guvernanța specificației și politica de compatibilitate trebuie clarificate înainte de adoptare. Un instrument open source nu elimină automat dependența de un furnizor sau de o echipă.

Securitate, date și transparență proporțională

Modelele pot dezvălui infrastructură critică, vulnerabilități sau informații personale. Propunem separarea vederilor publice de cele restricționate, minimizarea datelor și controlul accesului. Un catalog de arhitectură nu trebuie să devină un depozit de dosare personale. Publicarea se face numai după analiza conținutului și a obligațiilor aplicabile.

Alternative reale

Instituțiile pot îmbunătăți guvernanța folosind cadrele și instrumentele existente, pot adopta doar un vocabular comun sau pot folosi un profil de interoperabilitate fără un limbaj nou. Pilotul trebuie să compare aceste opțiuni. Public Framework este justificat dacă demonstrează valoare suplimentară și un cost rezonabil, nu doar pentru că este o inițiativă locală.

Principala limită a cercetării este că sursele consultate susțin necesitatea coordonării și a măsurării, dar nu reprezintă o evaluare independentă a Public Framework. Documentul nu include interviuri, un audit național sau rezultate proprii de implementare.

România are nevoie de o capacitate durabilă de a înțelege și coordona transformarea serviciilor publice. Arhitectura enterprise oferă o disciplină pentru această capacitate, cu condiția să fie integrată în conducere, investiții și livrare. Cercetarea susține această direcție; nu susține un monopol metodologic sau o promisiune automată de eficiență.

Propunerea Public Framework este să facem verificabilă legătura dintre mandatul public și implementarea sa. Primul pas recomandat este o evaluare deschisă a cadrului și un pilot delimitat, cu responsabilități, criterii de acceptare și rezultate publicabile. O extindere națională ar necesita validare, resurse, legitimitate instituțională și guvernanță care depășesc scopul acestui document.

Consultarea trebuie să răspundă la patru întrebări: ce decizie nu putem lua bine astăzi, ce informație arhitecturală ne lipsește, ce aduce în plus Public Framework și cum vom ști dacă intervenția a meritat?

Versiunea 0.1 este o bază de discuție. Următoarea revizie ar trebui să includă observații din administrație, verificare juridică și metodologică, mapări testate și, când vor exista, rezultate de pilot. Referirea la OECD, Comisia Europeană sau alte instituții nu implică afiliere, certificare ori susținere din partea acestora.