Când aplicația proprie devine greu de modificat: este arhitectura cauza și ce urmează?

Se schimbă un preț și cineva trebuie să-l modifice în cinci locuri: în ecranul de ofertare, în modelul de factură, în două rapoarte și într-un fișier Excel pe care contabilitatea îl ține separat. Sau un partener cere o conexiune la sistemul dumneavoastră și nimeni nu poate spune cum ar putea aplicația să o ofere.

Multe companii au o astfel de aplicație, despre care nu a auzit nimeni din afara firmei. A fost făcută acum câțiva ani, intern sau de un furnizor mic, pentru că niciun produs nu se potrivea cu felul în care lucrează. Procesul de bază trece și astăzi, zilnic, prin ea, iar ea păstrează ani de reguli despre cum funcționează firma. Regulile acestea au valoare, indiferent ce se întâmplă cu codul.

Modificările lente și conexiunile greu de făcut sunt motive să priviți mai atent. Ele nu spun încă ce anume nu merge și nu înseamnă că aplicația trebuie înlocuită. Cauza poate fi arhitectura, adică structura de sub ecrane. La fel de bine poate fi documentația lipsă, dependența de o singură persoană sau felul în care sunt legate sistemele. Fiecare cauză are o rezolvare potrivită, de altă mărime.

Situația se vede cel mai clar într-o firmă care a crescut de când a fost făcută aplicația. Aplicația susține în continuare bine procesul intern, iar un produs standard potrivit nu există, dar firma îi cere acum mai mult decât a prevăzut proiectul inițial.

Ghidul explică ce verificați înainte să decideți, ce înseamnă arhitectura prin ceea ce firma poate schimba, conecta, controla și recupera, ce variante comparați, unde ajută AI și unde nu, și cum se planifică o refacere în etape, atunci când este justificată.

Ce observați și ce altceva ar putea explica situația

Fiecare observație de mai jos este un motiv de verificare. Niciuna nu stabilește singură cauza și nu există un număr de observații de la care o aplicație trebuie înlocuită.

Dacă verificările indică mereu aceeași cauză de structură, o schimbare mai mare devine justificată. Dacă indică documentația lipsă, un ecran care lipsește sau o conexiune nesupravegheată, rezolvarea este mai mică.

Arhitectura, pe înțelesul tuturor

Orice aplicație are câteva decizii de structură, chiar dacă nu le-a numit nimeni. Primele versiuni se fac pentru a demonstra că un proces funcționează, cu buget limitat, de cine este disponibil, așa că aceste decizii rămân de obicei nespuse: un singur tabel pentru tot ce ține de un client, aceleași drepturi pentru toți utilizatorii, reguli de business scrise direct în ecrane, nicio cale definită prin care alte sisteme să se conecteze, nicio evidență a celor care au modificat datele. Pentru firma de atunci, au fost alegeri rezonabile. Devin scumpe când firma se schimbă.

Fiecare decizie se poate citi ca o întrebare de afaceri:

A lămuri aceste decizii nu înseamnă luni de proiectare înainte să funcționeze ceva. Înseamnă că deciziile greu de întors se iau devreme, iar restul poate evolua pe parcurs. Un model de date care permite o a doua țară costă puțin dacă este prevăzut acum; a doua țară poate aștepta până devine reală.

Comparați variantele potrivit mărimii problemei

Refacerea este o variantă dintre mai multe și, de obicei, cea mai mare. Adesea, celelalte sunt suficiente.

O intervenție mai mare devine potrivită când dovezile arată în aceeași direcție: aceeași cauză de structură apare la mai multe modificări blocate, costul unei modificări crește constant, creșterea planificată nu încape în structura actuală, iar variantele mai mici nu o pot rezolva. Fără aceste dovezi, variantele mai mici sunt de obicei investiția mai bună. Prin serviciul de modernizare a aplicațiilor comparăm aceste variante înainte ca cineva să se angajeze în cea mai mare dintre ele.

Ce schimbă AI și ce rămâne la fel

Programarea asistată de AI scurtează o parte din muncă. Inginerii o folosesc pentru a citi cod vechi, a schița teste, a scrie componente bine definite și a produce documentație, iar ea îi poate ajuta să formuleze ipoteze despre regulile de business pe care le conține sistemul vechi.

Proiectul întreg nu se ieftinește în aceeași măsură. Scrierea codului este doar o parte din livrare. Rămân înțelegerea activității, stabilirea soluției, migrarea și reconcilierea datelor, testarea, conectarea altor sisteme, instruirea oamenilor și operarea rezultatului, iar fiecare are nevoie de oameni care răspund pentru ea. Regulile deduse din codul vechi sunt ipoteze până când oamenii care folosesc sistemul le confirmă, iar testele pe date reale le susțin. O regulă care nu a fost scrisă niciodată, de exemplu excepția pentru un anumit client, este exact genul pe care un instrument care citește cod îl poate rata.

Altă întrebare este dacă sistemele dumneavoastră pot folosi AI. Extragerea datelor din documente, asistenții care răspund la întrebări despre datele firmei și agenții care pregătesc lucrări pentru aprobare au nevoie de date curate, de drepturi de acces clare, de o interfață pe care să o poată apela și de o evidență a ceea ce s-a făcut. Raportul DORA 2025 al Google, bazat pe un sondaj cu aproape 5.000 de specialiști în tehnologie și publicat în septembrie 2025, arată că echipele care lucrează pe arhitecturi slab cuplate, cu un ciclu rapid de feedback, câștigă de pe urma AI, în timp ce echipele legate de sisteme strâns cuplate și de procese lente văd beneficii mici sau deloc. Același raport constată că adoptarea AI este asociată cu o stabilitate mai scăzută a livrărilor de software, pe care o leagă de practici slabe de testare și de feedback. Este un sondaj, deci arată asocieri și nu dovedește că arhitectura produce diferența, iar concluziile privesc echipele de software în general, nu firma dumneavoastră.

Alte două surse oferă context, ambele cu ton de avertizare. În iunie 2025, Gartner a estimat că peste 40% dintre proiectele cu agenți AI vor fi anulate până la finalul lui 2027, din cauza costurilor în creștere, a valorii neclare pentru afacere și a controlului insuficient al riscurilor, și a menționat că integrarea agenților în sistemele vechi poate fi complicată din punct de vedere tehnic. În raportul State of IT Modernization, publicat pe 15 septembrie 2026 pe baza unui sondaj cu factori de decizie IT din SUA și Marea Britanie, firma de servicii IT Ensono arată că 78% consideră sistemele vechi mai importante pentru organizația lor decât acum doi ani, mai ales datorită datelor și regulilor de business pe care le conțin, iar 54% spun că AI accelerează modernizarea. Același comunicat precizează că 71% dintre proiectele de modernizare și-au depășit costurile planificate. Ensono vinde servicii de modernizare, cifra Gartner este o estimare, nu o măsurătoare, și niciuna nu descrie piața dumneavoastră. Împreună, ele sugerează că cunoașterea din sistemul existent merită păstrată, că AI poate accelera o parte din muncă și că o modernizare neplanificată se greșește ușor.

Dacă este momentul să acționați depinde, așadar, de situația dumneavoastră. Amânarea costă atunci când creșterea este planificată: aplicația adună mai multe date de migrat, soluții de avarie și integrări de înlocuit. Când procesul este stabil, planurile firmei nu cer mai mult de la aplicație, iar documentarea acoperă riscul, amânarea poate fi decizia corectă.

Dacă refaceți: un plan în etape

O refacere nu trebuie să însemne un singur weekend în care se trece de la sistemul vechi la cel nou. Abordarea pe care o preferăm construiește sistemul nou în jurul celui vechi:

1. Înțelegem întâi sistemul actual. Urmărim procesul împreună cu oamenii care îl desfășoară, citim codul și datele și notăm regulile, inclusiv pe cele neoficiale.
2. Proiectăm nucleul. Modelul de date, granițele dintre module, interfețele, regulile de acces și felul în care va fi operat sistemul.
3. Mutăm câte o parte pe rând. Începem cu zona care blochează cel mai mult activitatea sau care se schimbă cel mai des. Sistemul vechi și cel nou funcționează în paralel, iar datele dintre ele sunt reconciliate.
4. Retragem aplicația veche în etape, fiecare cu o soluție de revenire, până când nimic nu mai depinde de ea.

Obiectivul este ca activitatea firmei să continue pe tot parcursul. Un plan de migrare, reconcilierea periodică între sistemul vechi și cel nou și o soluție de revenire pentru fiecare etapă susțin acest obiectiv. Cât de deplin se poate atinge depinde de sistem, de exemplu de cât de adânc este împărțit modelul lui de date între procese, iar unele etape pot cere o scurtă întrerupere planificată. Stabilim ce este fezabil în etapa de analiză, înainte ca cineva să se angajeze.

Când refacerea nu este răspunsul potrivit

Tratați cu prudență ideea unei refaceri în aceste situații:

• Între timp a apărut un produs care acoperă procesul. Piața se schimbă. Dacă un produs vă acoperă astăzi procesul fără soluții de avarie, adoptarea lui este de obicei mai ieftină.
• Problema este între sisteme, nu în interiorul unuia. Dacă cel mai mult efort se duce pe reintroducerea datelor dintr-un program în altul, o integrare poate rezolva problema la o fracțiune din cost.
• Activitatea firmei nu se schimbă. Dacă aplicația susține un proces stabil și nimic din planurile firmei nu îi cere mai mult, stabilizați-o, documentați-o și păstrați-o.
• Cauza este documentația lipsă sau dependența de o singură persoană. Scrierea regulilor și instruirea unei a doua persoane rezolvă situația fără a schimba arhitectura.

Cum lucrăm la o refacere

Etapa de analiză durează de obicei 1-2 săptămâni. Petrecem timp cu oamenii care folosesc aplicația, citim sistemul existent și definim arhitectura, prima versiune și un interval de investiție. O primă versiune funcțională urmează de regulă în 6-10 săptămâni, în funcție de integrări, de calitatea datelor și de cât de multe lucruri sunt încă necunoscute. Aceasta este o primă versiune care acoperă o parte din proces; tranziția completă depinde de mărimea sistemului și se planifică în etape după analiză. Codul, documentația și conturile proiectului aparțin organizației dumneavoastră.

Este o alegere asumată. Pe 29 septembrie 2026, Gartner a estimat că, până în 2028, 70% dintre companii vor renunța la sistemele cu agenți AI construite pentru ele de echipele de ingineri trimise de furnizori, pentru că se confruntă cu costuri tot mai mari și nu le pot dezvolta singure. Recomandarea Gartner este ca proprietatea și condițiile de ieșire să fie stabilite înainte de începerea lucrului, iar succesul să fie măsurat după capacitatea companiei de a opera și adapta singură rezultatul. Estimarea se referă la agenții AI, dar concluzia se aplică oricărui sistem construit de un furnizor.

Pe această muncă se sprijină serviciul nostru de dezvoltare software personalizat, iar ea pornește din experiența fondatorilor: înainte de Solandrix, Dragoș a lucrat ca administrator de baze de date, lider tehnic și CTO, iar Lorelai a transformat ani la rând procese operaționale în cerințele pe care un sistem trebuie să le îndeplinească.

Întrebări frecvente

Cum aflăm dacă arhitectura este problema?

Urmăriți ultimele modificări lente și ultimele cereri refuzate până la cauza lor. Dacă același motiv de structură revine, de exemplu reguli scrise în cod, părți strâns legate între ele sau lipsa unei interfețe pentru alte sisteme, arhitectura este o cauză probabilă. Dacă cauzele sunt documentația lipsă, disponibilitatea unei singure persoane sau conexiuni nesupravegheate, se potrivesc corecturi mai mici. O analiză de 1-2 săptămâni poate stabili care este situația.

Putem folosi aplicația actuală pe durata refacerii?

Acesta este obiectivul. Sistemul nou preia pe rând câte o zonă, cele două funcționează în paralel acolo unde este nevoie, datele dintre ele sunt reconciliate, iar fiecare etapă are o soluție de revenire. Dacă se poate face fără nicio întrerupere depinde de sistem și se stabilește în etapa de analiză.

Va construi AI noul sistem în locul nostru?

AI ajută o mare parte din munca de inginerie: citirea codului vechi, schițarea testelor, scrierea componentelor bine definite și a documentației. Arhitectura, modelul de date, verificarea fiecărei reguli de business împreună cu oamenii care o folosesc, precum și migrarea și testarea rămân la inginerii care răspund pentru rezultat.

Aplicația noastră a fost făcută de alt furnizor. Puteți lucra cu ea?

Da. Analiza pornește de la cod, de la baza de date, de la documentația existentă și de la oamenii care știu cum este folosită aplicația în realitate. Acolo unde cunoașterea este la o singură persoană sau la un singur furnizor, documentarea ei face parte din proiect.

Cât durează și cui aparține rezultatul?

Analiza durează de obicei 1-2 săptămâni, iar o primă versiune funcțională urmează de regulă în 6-10 săptămâni, în funcție de integrări, de calitatea datelor și de necunoscute; tranziția completă depinde de mărimea sistemului și se planifică în etape după analiză. Costul depinde de amploarea proiectului, de integrări și de calitatea datelor, iar estimarea vine separat pentru fiecare etapă. Codul, documentația și conturile proiectului aparțin organizației dumneavoastră.

Dacă aplicația dumneavoastră devine tot mai greu de modificat

Folosiți formularul de contact și trimiteți-ne patru lucruri: ce face aplicația, cine o folosește, ce s-a schimbat în firmă de când a fost construită și ce trebuie să susțină de acum înainte. Vă răspundem cu varianta pe care am analiza-o prima, fie că este documentarea și stabilizarea, corecturi țintite, o integrare, reproiectarea unei părți sau proiectarea versiunii următoare, și cu ce ar trebui să confirme etapa de analiză.