Salt la conținutul principal
FromNine
Meniu

Software și cloud

Software enterprise pe care propriile dumneavoastră echipe îl pot schimba în continuare.

Dezvoltăm produse SaaS, portaluri pentru cetățeni și angajați și aplicații de business esențiale, accesibile, sigure din proiectare și ușor de întreținut de echipele dumneavoastră mult timp după lansare.

Pentru companii de produs și instituții publice care deservesc utilizatori din mai multe țări, în mai multe limbi și sub regimuri juridice diferite.

Solicitați o discuțieModernizarea sistemelor
Software enterprise și SaaS: straturile capabilitățiiPatru straturi suprapuse în adâncime. De sus în jos: interfața accesibilă pe care o folosesc oamenii, modulele de domeniu care conțin regulile, serviciile de platformă pentru clienți multipli și identitate și, dedesubt, pipeline-ul de livrare securizată.01Interfețe accesibile02Module de domeniu și reguli03Clienți multipli, identitate, date04Pipeline de livrare securizată
  1. 01Domain-driven design pentru activități cu multe reguli, cum este gestionarea dosarelor
  2. 02Accesibilitate conform EN 301 549 și WCAG 2.2 AA încă de la primul design
  3. 03Documentație și decizii consemnate pe care echipele dumneavoastră le pot prelua

01 Probleme

Ce auzim înainte de o reconstrucție

  1. 01

    Fiecare modificare durează un trimestru

    Aplicația funcționează, dar nimeni nu îndrăznește să atingă nucleul. Modificările mici cer teste de regresie ample și o fereastră de lansare.

  2. 02

    Portalul nu îi servește pe cei pentru care există

    Nu funcționează cu un cititor de ecran, pe telefon sau pentru utilizatorii care au nevoie de o altă limbă. Reclamațiile sosesc înaintea auditului de accesibilitate.

  3. 03

    Modificarea cerută de un client o strică pe a altuia

    Produsul SaaS a crescut prin adaptări pentru fiecare client. Acum fiecare lansare este o negociere, iar unii clienți au rămas blocați pe versiuni vechi.

  4. 04

    Cunoștințele au plecat odată cu furnizorul

    Deciziile nu au fost niciodată consemnate. Echipa care a construit aplicația a plecat, iar codul este singura documentație.

  5. 05

    Clienții și autoritățile pun întrebări de securitate

    Achizițiile cer un SBOM, un proces pentru vulnerabilități și dovezi pentru Regulamentul privind reziliența cibernetică. Nimeni nu le are pregătite.

02 Ce livrăm

Ce livrăm

  1. 01 Dezvoltarea produselor SaaS

    Produse proiectate pentru a servi mulți clienți dintr-o singură bază de cod: modelul potrivit de separare a clienților, configurare în loc de adaptări și lansări care ajung la fiecare client.

    Ce facem

    • Alegerea modelului de separare: partajat, grupat sau izolat pentru fiecare client
    • Strategie de configurare și de feature flags
    • Integrarea măsurării consumului și a facturării
    • Trenuri de lansare cu implementare eșalonată pe clienți

    Ce primiți

    • Proiectarea separării și izolării clienților
    • Model de configurare cu limite clare
    • Proces de lansare cu revenire pentru fiecare client

  2. 02 Proiectarea domeniului pentru reguli complexe

    Domain-driven design acolo unde regulile sunt produsul: gestionarea dosarelor, eligibilitate, calcule cu multe prevederi legale. Alegem deliberat între un monolit modular și microservicii și, de cele mai multe ori, începem cu primul.

    Ce facem

    • Event storming cu experții în domeniu
    • Contexte delimitate și granițe între module
    • Reguli explicite și testabile
    • Decizii de arhitectură consemnate pentru alegerile mari

    Ce primiți

    • Modelul domeniului și harta contextelor
    • Bază de cod modulară, cu granițe impuse
    • Specificații executabile pentru regulile-cheie

  3. 03 Portaluri pentru cetățeni și angajați

    Interfețe construite pe un design system, accesibile implicit și pregătite pentru mai multe limbi încă de la prima lansare. În România înseamnă, de regulă, limba română, plus limbile pe care utilizatorii dumneavoastră le folosesc efectiv.

    Ce facem

    • Design system cu componente accesibile
    • Conținut scris în limbaj clar
    • Teste cu tehnologii de asistare, împreună cu utilizatori reali
    • Flux de localizare pentru fiecare limbă

    Ce primiți

    • Portal pe un design system reutilizabil
    • Raport de conformitate privind accesibilitatea
    • Flux pentru conținut și traduceri

  4. 04 Ingineria calității și dezvoltare securizată

    Automatizarea testelor la nivelurile potrivite, teste de contract între servicii, teste de performanță înainte de lansare și un ciclu de dezvoltare securizată bazat pe OWASP ASVS, SBOM și controale pentru lanțul de aprovizionare software.

    Ce facem

    • Strategie de testare și automatizare
    • Teste de contract și de performanță
    • Modelarea amenințărilor și verificare ASVS
    • Generarea SBOM și politică pentru dependențe

    Ce primiți

    • Suite de teste automate în pipeline
    • Raport de verificare a securității
    • Proces de tratare a vulnerabilităților pregătit pentru Regulamentul privind reziliența cibernetică

  5. 05 Modernizare incrementală

    Înlocuim o aplicație legacy capabilitate cu capabilitate, în spatele unei fațade de rutare, în timp ce activitatea continuă. Vedeți și Modernizarea sistemelor legacy.

    Ce facem

    • Harta capabilităților aplicației existente
    • Rutare după modelul strangler fig și încapsulare prin API
    • Migrarea datelor, cu rapoarte de reconciliere
    • Rulări în paralel pentru calculele critice

    Ce primiți

    • Secvența de modernizare, cu repere de business
    • Fațada și modulele noi în producție
    • Date reconciliate la fiecare trecere pe sistemul nou

  6. 06 Mentenabilitate și predare

    Software pe care echipele dumneavoastră îl pot prelua: cod lizibil, decizii consemnate, ghiduri operaționale și un plan de predare convenit la început, nu descoperit la final.

    Ce facem

    • Lucru în pereche cu dezvoltatorii dumneavoastră în timpul construcției
    • Decizii de arhitectură consemnate alături de cod
    • Ghiduri operaționale și pentru tura de permanență
    • Repere pentru transferul de cunoștințe

    Ce primiți

    • Plan de predare cu criterii de acceptare
    • Documentație în depozitele dumneavoastră de cod
    • Echipă internă instruită

03 Arhitectură

O arhitectură de referință ilustrativă

O formă tipică pentru o aplicație de business care înlocuiește una mai veche: un front-end accesibil, o fațadă de rutare care trimite fiecare capabilitate către sistemul vechi sau către cel nou, un strat de API-uri cu contracte clare și un nucleu modular organizat în jurul domeniului.

Separarea clienților și configurarea sunt servicii de platformă explicite, nu condiții împrăștiate prin cod. Dedesubt, fiecare build rulează teste și verificări de securitate și produce un SBOM.

Straturile din diagramă

Oameni
Cetățeni, clienți și angajați, pe orice dispozitiv și cu tehnologii de asistare.
Modernizare
Fațada de rutare, aplicația existentă și migrarea datelor cu reconciliere.
Platformă
Stratul de API-uri, identitatea, nucleul modular, separarea clienților și configurarea, datele operaționale.
Livrare securizată
Teste de contract și de performanță, verificări ASVS și un SBOM la fiecare build.
Exemplu ilustrativ

  1. Oameni

    • Cetățeni, clienți, angajați
    • Front-end accesibil

  2. Modernizare incrementală

    • Fațadă de rutare
    • Aplicația existentă
    • Migrare cu reconciliere

  3. Platformă

    • Strat de API-uri și contracte
    • Identitate și roluri
    • Nucleu modular: preluare, dosare, facturare
    • Clienți multipli, configurare, feature flags
    • Depozite de date operaționale

  4. Livrare securizată

    • Teste de contract și de performanță, verificări ASVS, SBOM la fiecare build
Nucleu modular în spatele unei fațade de rutare

Arhitectură ilustrativă, nu sistemul unui client.

Citiți diagrama ca text

Traseul principal pornește de la oameni, ajunge la un front-end accesibil, trece printr-o fațadă de rutare și un strat de API-uri și ajunge la un nucleu modular organizat în contexte delimitate.

Fațada trimite unele capabilități și către aplicația existentă, care este retrasă pas cu pas. Datele ei trec printr-o migrare cu reconciliere în depozitele de date operaționale.

Identitatea deservește stratul de API-uri. Serviciile pentru clienți multipli și configurare se află sub nucleu. O bandă de livrare securizată, dedesubt, acoperă testele de contract, testele de performanță, verificarea securității și SBOM-urile.

04 Aspecte și limite

Aspecte de inginerie și limite

  • Întâi monolitul modular

    Cum procedăm

    Pornim cu module clare într-o singură unitate de implementare și separăm servicii doar acolo unde scalarea, ritmul lansărilor sau responsabilitatea echipelor o cer.

    Limite și dependențe

    Microserviciile rezolvă probleme de organizare la fel de mult ca probleme tehnice. Fără echipe care să răspundă de ele, adaugă costuri și moduri noi de defectare.

  • Accesibilitatea este muncă de inginerie

    Cum procedăm

    Componente accesibile, verificări automate în pipeline și teste manuale cu tehnologii de asistare înainte de fiecare lansare majoră.

    Limite și dependențe

    Instrumentele automate găsesc doar o parte din probleme. Conformitatea deplină cere audituri manuale și, ideal, teste cu persoane cu dizabilități.

    Conținutul și documentele adăugate de editori după lansare trebuie să respecte același standard. Îi instruim pe editori, dar nu controlăm ce publică.

  • Modernizarea durează cât datele

    Cum procedăm

    Migrarea datelor este planificată pentru fiecare capabilitate, repetată și reconciliată, cu aprobarea business-ului la fiecare trecere pe sistemul nou.

    Limite și dependențe

    Calitatea datelor din sistemele legacy stabilește adesea ritmul. Curățarea lor este o sarcină de business la fel de mult ca una tehnică.

  • Reglementări pentru produsele software

    Cum procedăm

    SBOM-urile, tratarea vulnerabilităților și setările implicite sigure fac parte din pipeline-ul nostru standard, care pregătește produsele pentru Regulamentul privind reziliența cibernetică.

    Limite și dependențe

    Dacă și cum se aplică regulamentul produsului dumneavoastră este o întrebare juridică. Noi furnizăm dovezile de inginerie; evaluarea o fac consilierii dumneavoastră juridici.

05 Cum lucrăm

Cum lucrăm

Cicluri scurte, utilizatori reali de la început și predarea planificată din prima săptămână.

  1. 01

    Cartografiem domeniul

    Event storming cu oamenii care cunosc regulile și o hartă a capabilităților existente astăzi.

    RezultatHarta contextelor și primele decizii consemnate

  2. 02

    Livrăm o primă felie subțire

    O capabilitate de la un capăt la altul, prin fațadă, în producție, cu utilizatori reali.

    RezultatFelie funcțională în producție

  3. 03

    Creștem capabilitate cu capabilitate

    Fiecare lansare mută o capabilitate, datele și utilizatorii ei, cu reconcilierea și revenirea pregătite.

    RezultatPlan de lansare pe capabilități

  4. 04

    Predăm

    Dezvoltatorii dumneavoastră lucrează în pereche cu ai noștri, preiau tura de permanență și foaia de parcurs atunci când criteriile de predare sunt îndeplinite.

    RezultatPredare acceptată

06 Control uman

Unde controlul rămâne la oameni

În software-ul de business, controlul înseamnă să știți cine a schimbat ce, cine a aprobat și cum se poate reveni.

  • Product ownerii decid perimetrul

    Product ownerul dumneavoastră stabilește prioritățile și acceptă fiecare increment. Noi recomandăm, el decide.

  • Configurarea are un responsabil

    Setările clienților și feature flags se modifică printr-un proces auditat, de către rolurile pe care le stabiliți.

  • Trecerile pe sistemul nou sunt aprobate

    Fiecare mutare de pe sistemul vechi pe cel nou este aprobată de business, cu o revenire exersată.

  • Deciziile sunt consemnate

    Deciziile de arhitectură consemnate arată ce s-a ales, de către cine și de ce, astfel încât echipele viitoare să le poată revizui în cunoștință de cauză.

07 Tehnologii

Tehnologii cu care lucrăm

Back-end
  • Java și Kotlin
  • .NET
  • TypeScript și Node.js
  • Python
Front-end
  • React și Next.js
  • Angular
  • Design systems cu componente accesibile
  • Aplicații mobile native și cross-platform
Date
  • PostgreSQL
  • SQL Server și Oracle (în sisteme existente)
  • Event streaming
  • Motoare de căutare
Calitate și securitate
  • Playwright și teste de contract
  • Teste de încărcare și de performanță
  • SAST, DAST și scanarea dependențelor
  • SBOM în CycloneDX sau SPDX

Mențiunea unei tehnologii descrie experiența noastră de inginerie. Nu implică un parteneriat cu producătorul ei și nici o recomandare din partea acestuia.

08 Exemplu

Un exemplu ilustrativ

Exemplu ilustrativ

Un portal pentru cetățeni, comun pentru o asociație de comune

01Situația
Mai multe comune dintr-un județ, asociate pentru servicii comune, au fiecare propriul site și propriile formulare. Cetățenii depun cererile pe hârtie la registratură sau prin e-mail, iar fiecare site are alte probleme de accesibilitate.
02Ce am construi
Un singur portal pe un design system comun, cu autentificare prin ROeID, formulare de cereri accesibile și conținutul fiecărei comune păstrat în configurare, cu un singur flux de lansări.
03Unde decid oamenii
Fiecare primărie aprobă conținutul și formularele proprii, iar asociația decide asupra funcțiilor comune. Cererile depuse ajung la registratura primăriei, unde funcționarii le înregistrează și le instrumentează.
04Ce am măsura
Problemele de accesibilitate la fiecare lansare, ponderea cererilor depuse online și timpul necesar pentru ca o modificare să ajungă la toate comunele.

09 Pe sectoare

În sectorul dumneavoastră

  • Sector public și administrație

    Gestionarea dosarelor și portaluri pentru cetățeni care respectă OUG nr. 112/2018 privind accesibilitatea, folosesc autentificarea prin ROeID și se conectează la Platforma națională de interoperabilitate.

  • Servicii financiare

    Portaluri pentru clienți și aplicații de back-office cu jurnale de audit solide și procese de lansare care respectă controlul modificărilor.

  • Producție și industrie

    Configuratoare, portaluri de service și produse SaaS pentru producătorii de echipamente, conectate la ERP și la service-ul de teren.

România

O piață nouă este o lansare, nu o ramificare a codului

Un produs vândut în UE întâlnește Actul european privind accesibilitatea prin legi naționale care diferă în detalii, iar Regulamentul privind reziliența cibernetică printr-un singur regulament, cu obligații care se aplică în etape. În România, Legea nr. 232/2022 transpune Actul european privind accesibilitatea și se aplică de la 28 iunie 2025; microîntreprinderile care furnizează servicii sunt exceptate. Site-urile și aplicațiile mobile ale organismelor din sectorul public intră sub incidența OUG nr. 112/2018, cu Autoritatea pentru Digitalizarea României (ADR) ca autoritate de reglementare și supraveghere și cu EN 301 549 ca standard de referință.

Clienții din fiecare țară se așteaptă și la propria limbă, la propriile reguli de facturare și la propriile scheme de identitate: în România, RO e-Factura pentru facturi și ROeID pentru identificarea electronică.

Păstrăm aceste diferențe în configurare și în module clar delimitate, astfel încât o piață nouă să fie o lansare, nu o ramificare a codului. Dovezile de accesibilitate și documentația de securitate sunt produse de pipeline, pregătite pentru întrebările din procedurile de achiziție ale fiecărei piețe.

Întrebări despre software enterprise și SaaS

Dezvoltăm la comandă sau configurăm o platformă?

Configurați o platformă acolo unde procesul dumneavoastră este aproape de standard și dezvoltați la comandă acolo unde procesul vă diferențiază sau unde nicio platformă nu se potrivește regulilor. Lucrăm cu Salesforce, SAP și Odoo, dar și cu cod dezvoltat la comandă, așa că nu avem niciun motiv să impunem un anumit răspuns. Serviciul nostru de Arhitectură și consultanță face această alegere explicită.

Puteți garanta că portalul nostru este accesibil?

Construim conform EN 301 549 și WCAG 2.2 AA, testăm automat și manual și livrăm un raport de conformitate care include problemele cunoscute. Nu promitem zero probleme; promitem să le găsim, să le raportăm și să le corectăm pe cele care intră în perimetrul nostru.

Puteți moderniza fără o migrare de tip big bang?

Da, și chiar vă recomandăm acest lucru. O fațadă de rutare ne permite să mutăm câte o capabilitate pe rând, în timp ce aplicația existentă continuă să funcționeze, cu datele reconciliate la fiecare pas.

Poate echipa noastră să preia software-ul?

Acesta este planul implicit. Criteriile de predare se convin la început, dezvoltatorii dumneavoastră lucrează în pereche cu ai noștri în timpul construcției, iar deciziile consemnate și ghidurile operaționale stau în depozitele dumneavoastră de cod.

Ce înseamnă Regulamentul privind reziliența cibernetică pentru produsul nostru?

Dacă introduceți pe piața UE software cu elemente digitale, regulamentul vă poate aduce obligații privind proiectarea securizată, tratarea vulnerabilităților și documentația. Noi construim dovezile de inginerie: SBOM-uri, un proces pentru vulnerabilități și setări implicite sigure.

Spuneți-ne ce trebuie să funcționeze în continuare în timp ce se schimbă

Vă propunem prima capabilitate de mutat și ce va deține echipa dumneavoastră la final.

Solicitați o discuțieModernizarea sistemelor