Arhitectura deschisă
Arhitectura deschisă — matricea completă.
Fiecare cerință din caietul de 167 de pagini, pusă lângă răspunsul dat de un stack open source dimensionat realist, cu judecată explicită despre ce chiar e necesar pentru o platformă care transportă date între instituții. Document sub licență deschisă — oricine poate prelua, adapta, contesta.
Metodologie
Matricea care urmează parcurge, linie cu linie, cele douăsprezece componente funcționale descrise în caietul de sarcini al Platformei Naționale de Interoperabilitate. Pentru fiecare cerință selectată — aproximativ șaptezeci dintr-un total de peste o sută douăzeci, păstrând proporțional ponderea pe fiecare componentă — apar patru coloane: numărul cerinței originale, rezumatul faptic al textului din caiet, soluția propusă din stack-ul deschis prezentat în Episodul 05, și, în coloana a patra, judecata „la ce ne trebuie?".
Judecata nu e opinie — e aplicarea unui principiu arhitectural clar, documentat în Episodul 03: platforma transportă date între instituții, nu le stochează ca sursă de adevăr. Tot ce confundă platforma cu un depozit analitic, cu un motor de workflow, cu un catalog de licențe proprietar, primește o etichetă distinctă.
Există cinci etichete de judecată, folosite consistent în toată matricea:
- Necesar Funcționalitate reală, nevoia e validă și proporțională. SSO, RBAC, logging, HA.
- Necesar, redimensionat Nevoia e validă, caietul exagerează dimensiunea sau complexitatea.
- Scope greșit Platforma nu e locul acestei funcționalități. Analitică pe date pe care nu le deține, orchestrare de procese într-un bus de mesaje.
- Tehnologie moartă Standardul sau produsul e depreciat oficial de industrie — WSRP, BPEL, UDDI clasic, SAML 1.1.
- Favorizare vendor Cerința e scrisă după un produs comercial specific, fără justificare obiectivă. Label Security, Internet Directory numit nominal.
O cerință poate primi mai multe etichete dacă e cazul — de exemplu, Flashback Query este simultan „scope greșit" (platforma nu stochează ce să interoghezi istoric) și „favorizare vendor" (formularea reproduce numele comercial al unei funcții proprietare).
3.8.1 Portal
Portalul public și panoul de administrare al platformei. Caietul cere SSO, RBAC, căutare agregată — necesare. Cere și WSRP, standard abandonat în 2008. Propunerea: dezvoltare proprie în Rust (Axum + Leptos), cu căutare Tantivy și SSO prin FusionAuth. Aproximativ 70% cerințe necesare, restul redimensionabile sau învechite.
3.8.2 Management documente
Componenta DMS cerută ca produs comercial, cu cod sursă livrat. Alfresco Community acoperă cerințele de bază sub LGPL; semnarea digitală calificată și geocodingul se adaugă prin module. Aproape toate cerințele sunt legitime, dar caietul impune „același producător" pentru toate submodulele — o formulare care elimină integratorii.
3.8.3 Baza de date
Cea mai restrictivă componentă — aici apar cerințele cu nume de produs camuflate. Flashback, Label Security, cluster multi-master, framework low-code — toate au alternative standard. Platforma transportă date, nu le stochează ca sursă de adevăr. Din această cauză, interogarea istorică nu are caz real de utilizare.
3.8.4 Business Intelligence
Raportare și dashboards peste datele platformei. Cerințele de vizualizare, LDAP, export sunt necesare. Cerința de machine learning intern și writeback e supradimensionată — o platformă de interoperabilitate nu face analitică predictivă pe date pe care nu le deține.
3.8.5 Interoperabilitate / ESB
Inima platformei — bus-ul care rutează mesaje între instituții. Cerința de BPEL arată confuzie conceptuală: un ESB implementează paradigma EIP (Enterprise Integration Patterns), nu orchestrare de procese. Cerința de UDDI ține de un standard abandonat. Restul sunt legitime și acoperite complet de WSO2 Micro Integrator.
3.8.6 API Management
Gestiunea ciclului de viață al API-urilor expuse către instituții partenere. Toate cerințele de bază — DevPortal, rate limiting, OAuth, OIDC, SAML — sunt legitime și acoperite de WSO2 API Manager. Cerințele periferice de form builder și billing sunt utile, dar nu critice în prima fază.
3.8.7 Identitate (IdM / IAM)
Platforma centrală de identitate. SSO, MFA, federare, provizionare — toate necesare. Dar două cerințe ridică steaguri: numirea unui produs LDAP specific și cererea de „management acces bazat pe BPEL". Ambele trădează copierea unui catalog comercial. FusionAuth Enterprise acoperă majoritatea, cu completări pentru access review și SoD.
3.8.8 Acces privilegiat (PAM)
Securizarea conturilor administrative. Cerințele principale — session recording, RBAC, parole dinamice — sunt necesare și acoperite de Teleport cu Vault. Cerința de certificare Common Criteria poate fi relaxată prin demonstrarea echivalenței prin SOC 2 și FedRAMP, ambele deținute de Teleport.
3.8.9 Monitorizare
Supravegherea infrastructurii și aplicațiilor. Cerințele de monitorizare OS, rețea, baze de date, LDAP — toate legitime, acoperite complet de Zabbix cu template-urile oficiale. Singura cerință deplasată e distribuirea de patch-uri — monitorizarea detectează, nu remediază.
3.8.10 Disaster Recovery
Backup și replicare pentru continuitate. Cerințele sunt toate rezonabile și acoperite de Veeam cu suplimentare PostgreSQL streaming. Nicio cerință nu are probleme arhitecturale — e una dintre cele mai curate secțiuni ale caietului.
3.8.11 SIEM
Colectare și corelare evenimente de securitate. Toate cerințele sunt legitime și acoperite de Wazuh (SIEM, XDR, FIM — același producător). Singura observație: licențierea pe volum cerută în caiet penalizează opțiunile bune. Wazuh nu are limită — avantaj concret de cost.
3.8.12 Concentrator VPN
Acces securizat pentru personalul de operare și instituții partenere. WireGuard plus OpenVPN acoperă toate cerințele. Cerința de criptare post-cuantică e prematură — niciun furnizor nu o livrează production-ready în 2026. Cerința de secure boot cu TPM aparține stratului de hardware, nu celui VPN.
Ce iese din matrice
Aproximativ 60% din cerințele analizate sunt necesare — lucruri firești pe care orice platformă națională le cere: SSO, RBAC, cluster HA, backup, session recording, auditul accesului, federare de identitate. Pe aceste cerințe stack-ul deschis răspunde fără echivoc, cu produse cu suport comercial și cu decenii de practică în sectorul public și privat.
Încă 12% sunt necesare, dar redimensionabile — nevoia e reală, caietul însă cere cluster multi-master acolo unde primary-standby e suficient, funcții ML în BI deși datele nu ajung niciodată în platformă, criptare post-cuantică pe care nimeni nu o livrează production-ready în 2026. Aceste cerințe se rezolvă prin dialog tehnic, nu prin achiziții mai scumpe.
Restul de aproximativ 28% se distribuie pe trei etichete problematice: circa 10% scope greșit (Flashback pe o platformă care nu stochează, algoritmi ML într-un tool de raportare, distribuire patch-uri într-un SIEM), 7% tehnologie moartă (BPEL, WSRP, UDDI clasic, SAML 1.1) și 10% favorizare vendor prin numirea de produse comerciale sau reproducerea denumirilor lor de marketing (Label Security, Oracle Internet Directory, Flashback Query). Unele cerințe poartă două etichete simultan, de aceea suma depășește 100%.
Concluzia e simplă. Două treimi din caiet cer lucruri necesare — și pot fi livrate cu 5–8 milioane de euro, nu 33. Restul de o treime e fie supradimensionare, fie scope greșit, fie favorizare — exact diferența între cifra din oferta pregătită și cifra pe care ar plăti-o un cumpărător public neutru. Nu e o chestiune de preț. E o chestiune de claritate asupra a ceea ce face, de fapt, o platformă de interoperabilitate.
Reutilizare
Preia. Adaptează. Contestă.
Matricea e publicată sub Creative Commons Atribuire–Distribuire în condiții identice 4.0. Orice ofertant o poate pune în propria propunere tehnică, orice jurnalist o poate cita, orice cetățean o poate trimite unei persoane care are mandat să decidă. Singura obligație: atribuirea către autor și păstrarea aceleiași licențe pe derivate.
Codul sursă al site-ului și al specificațiilor arhitecturale e pe github.com/iello/magistrala, sub licența MIT. Issue-uri pentru corecții factuale și sugestii de surse suplimentare — deschise. Contestațiile motivate sunt mai valoroase decât acordul.
Pentru pontaje, observații tehnice sau clarificări: contact@interoperabilitate.ro.