Sari la conținut
De Obște

Platforma serviciilor publice digitale

De ce interoperabilitate incrementală

O platformă de interoperabilitate, peste noapte, nu se poate înfăptui. Interoperabilitatea reală se construiește în straturi și în ritmul în care instituțiile pot fi pregătite. Iată de ce începem cu accesul controlat prin Puntea și cu jurnalul de audit al Cronicii, nu cu automatizarea totală.

De ce Puntea, acum

Interoperabilitatea completă (schimbul de date automat, de la un sistem la altul, fără intervenție umană) este ultima etapă, nu prima. Ea se sprijină pe două straturi de fundație și pe pregătirea fiecărei instituții.

Interoperabilitatea se construiește în straturi. Înainte de automatizare sunt necesare un registru al accesului controlat și un jurnal de audit, exact rolul Punții și al Cronicii. Fără aceste fundații, un schimb automat de date ar rămâne fără urmă verificabilă și fără control asupra scopului. Automatizarea sistem-la-sistem este piesa care se așază la final, după ce straturile de fundație funcționează și instituțiile sunt pregătite.

Instituțiile pornesc din situații tehnologice diferite. În practică, sistemele existente se încadrează în câteva tipare:

  • sisteme dezvoltate de un furnizor extern fără livrarea codului sursă, cu sau fără un contract de mentenanță activ, nu pot deveni consumatoare de servicii peste noapte, iar orice integrare trebuie dezvoltată în cadrul contractual existent, dacă acesta există;
  • sisteme fără suport, cu sau fără cod sursă și cu sau fără contract de mentenanță corectivă;
  • sisteme dezvoltate intern (in-house): cazul cel mai flexibil, dar minoritar.

Ce cere integrarea sistem-la-sistem, pentru fiecare instituție. Pentru ca un sistem să devină automat consumator sau furnizor de servicii, este nevoie, de regulă, de:

  • acces la codul sursă al sistemului existent;
  • un cadru contractual de mentenanță sau dezvoltare;
  • bugetare;
  • procedură de achiziție (licitație);
  • specificații tehnice.

Realist, asta înseamnă luni de lucru pentru fiecare instituție și ani pentru o acoperire largă la nivel de sistem public. Cu alte cuvinte: timp și bani.

Pasul realist: integrăm ce e deja expus. Până când fiecare instituție își poate permite integrarea completă, Puntea folosește ceea ce există deja. Multe instituții au deja API-uri publicate și acorduri punctuale de interoperabilitate. Puntea le transformă în operațiuni controlate: funcționarul dintr-o altă instituție primește acces cu proces și scop declarate, la datele deja disponibile, iar fiecare utilizare rămâne consemnată în Cronica.

Om-în-buclă întâi: printr-un formular controlat, nu printr-un apel tehnic liber. Acestea sunt câștigurile imediate. Automatizarea sistem-la-sistem, fără intervenție umană, rămâne etapa următoare, când straturile de fundație sunt așezate și instituțiile sunt pregătite.

Cele două trasee spre interoperabilitate Schemă de integrare. O instituție care are nevoie de date din altă instituție are două trasee. Traseul lent (viitor, desenat punctat și estompat) trece prin trei situații tehnologice ale sistemelor existente, apoi printr-un lanț de precondiții în serie (cod sursă, cadru contractual, bugetare, licitație, specificații) până la un conector sistem-la-sistem și schimbul automat de date; durează luni sau ani și costă mult, per instituție. Traseul rapid (activ azi, desenat plin și în culoarea de brand) pornește de la un API deja expus printr-un acord de interoperabilitate, trece prin Puntea ca formular controlat către funcționarul din altă instituție și produce un rezultat filtrat; fiecare utilizare derivă o urmă în Cronica de audit. Traseul activ traversează traseul viitor prin două podețe (line hops), ca într-o schemă tehnică. Instituție care are nevoie de date din altă instituție Sistem al unui furnizor extern, fără cod sursă Sistem fără suport, cu/fără cod sursă Sistem intern (in-house) Cod sursă Cadru contractual Bugetare Licitație Specificații Conector sistem-la-sistem Schimb automat de date (fără intervenție umană) API deja expus (acord de interoperabilitate) Puntea: formular controlat Funcționar din altă instituție (proces + scop) Rezultat filtrat Cronica: audit luni–ani, cost ridicat, per instituție acces controlat acum, om-în-buclă Traseu activ: disponibil azi, prin Puntea Traseu viitor: automatizare sistem-la-sistem
Cele două trasee: integrarea sistem-la-sistem, lentă și costisitoare, versus accesul controlat prin Puntea la ce e deja expus.

Cum se înrolează un serviciu

Pe scurt: Adrian, administrator de servicii, propune API-ul propriu. Bianca, admin al platformei Puntea, îl avizează și îl publică pentru a fi consumat de funcționari. Pas cu pas:

  1. Administratorul de servicii propune serviciul

    Adrian, administrator de servicii, importă contractul tehnic (OpenAPI) al serviciului propriu și clasifică operațiunile: sensibilitate, parametri identificatori, câmpuri de răspuns, scopuri permise.

  2. Administratorul Puntea avizează și publică

    Bianca, administratorul platformei, verifică operațiunea și o publică pentru toate instituțiile. O instituție propune un serviciu, nu se auto-publică într-o platformă comună: operatorul Punții îl curează și îl pune la dispoziția tuturor. Propunătorul (instituția) și publicatorul (Puntea) rămân roluri distincte, iar contractul trece prin stările ciornă, validat, avizat și publicat.

  3. Funcționarii consumă serviciul

    Maria, funcționar, folosește operațiunea numai în procesul și scopul active ale instituției, printr-un formular controlat, nu printr-un apel tehnic liber.

  4. Fiecare utilizare lasă urmă

    Interogarea produce un eveniment în Cronica: cine, pentru ce proces, cu ce rezultat. Cetățeanul vizat își poate vedea interogările despre el.