Arhitectură înainte de stack.

• P—01Boundaries clareFiecare parte a sistemului are un perimetru cunoscut. Ce este înăuntru poate fi schimbat; ce este la graniță se negociază explicit.
• P—02Contracte expliciteInteracțiunea dintre componente trece prin ceva scris — schemă, API, eveniment — nu prin cunoștințe informale despre cum funcționează celălalt modul.
• P—03Separarea responsabilitățilorBusiness logic-ul, accesul la date, transportul și prezentarea sunt straturi distincte. Amestecarea lor este cea mai frecventă cauză de rigiditate.
• P—04Comportament observabilUn sistem care nu poate spune ce a făcut nu poate fi operat. Observability se proiectează odată cu funcționalitatea, nu după primul incident.
• P—05State controlatStarea are un loc definit, un ciclu de viață și un singur mod de a fi modificată. Starea duplicată devine, în timp, stare contradictorie.
• P—06Componente înlocuibileOrice serviciu extern, bibliotecă sau furnizor va fi, la un moment dat, schimbat. Costul acelei schimbări se decide la momentul integrării.
• P—07Acces sigurIdentitatea, permisiunile și limitele de acces fac parte din arhitectură, nu dintr-un strat adăugat înainte de lansare.
• P—08Failure gestionatDependențele cad, rețeaua întârzie, fișierele lipsesc. Sistemul trebuie să aibă un comportament definit pentru fiecare dintre aceste cazuri.
• P—09Evoluție incrementalăSchimbarea se face în pași care pot fi verificați și, la nevoie, întorși. Migrațiile mari, „dintr-o dată", sunt cele care blochează echipe luni întregi.

1. 01ProducerExpune o capabilitate. Poate schimba implementarea oricând, cât timp respectă forma promisă.
2. 02ContractSchemă, tipuri, erori, autentificare, versiune. Partea care nu se schimbă fără o decizie explicită.
3. 03ConsumerFolosește capabilitatea fără să știe nimic despre interiorul ei — și fără să se rupă la fiecare release.

1. 01EntityCe reprezintă datul în realitate: un client, o comandă, un document, un eveniment.
2. 02OwnershipCare sistem este sursa de adevăr și cine are dreptul să o modifice.
3. 03StorageModelul potrivit formei datelor — relațional, document, fișier, serie de evenimente.
4. 04AccessCine citește, cine scrie, în ce condiții și cu ce urmă lăsată în audit.
5. 05UseProdus, raportare, integrare, AI — toate pe aceeași definiție, nu pe copii divergente.

• 01Arhitectură de componenteComponentele au responsabilități clare și limite de reutilizare. Ceea ce se repetă în trei locuri devine o singură definiție.
• 02Design systemsTipografie, spațiere, culoare, stări și componente definite o singură dată, folosite consecvent în tot produsul.
• 03AccessibilityStructură semantică, navigare de la tastatură, focus vizibil, contrast. Nivelul de conformitate se stabilește per proiect.
• 04Responsive behaviorAceleași informații, reorganizate pentru contextul de utilizare — nu un desktop micșorat până devine inutilizabil.
• 05State managementCe este stare de server, ce este stare de interfață și ce este stare de sesiune — separate conceptual, tratate diferit.
• 06PerformanțăCe se încarcă întâi, ce se amână, ce se cachează. Percepția de viteză se construiește din ordinea în care apar lucrurile.
• 07Progressive loadingInterfața arată structura înainte să aibă toate datele, în loc să țină ecranul gol până la ultimul răspuns.
• 08Error statesFiecare eroare spune ce s-a întâmplat și ce poate face utilizatorul mai departe. Un mesaj generic mută problema la suport.
• 09Consecvență de interacțiuneAceeași acțiune se comportă la fel peste tot. Predictibilitatea reduce mai mult efortul decât orice ecran de ajutor.

Digital Experiences →

1. 01User / EventPunctul de pornire: o întrebare, un document nou, o schimbare de stare într-un flux.
2. 02ContextCe știe sistemul despre situație: utilizator, permisiuni, entitatea în lucru, istoricul relevant.
3. 03RetrievalInformația adusă din surse reale, filtrată după ce are voie să vadă cel care întreabă.
4. 04ModelComponenta care interpretează și formulează — nu sursa adevărului și nici arbitrul final.

1. 05ToolsAcțiunile pe care le poate declanșa: căutare, calcul, citire sau scriere într-un sistem, cu limite.
2. 06ValidationVerificarea rezultatului înainte să producă efecte: format, reguli de business, praguri de încredere.
3. 07Action / OutputRezultatul intră înapoi în produs, în flux sau în date — cu sursele și cu urma pașilor.

1. 01Documents / DataSursele reale: contracte, proceduri, specificații, tichete, date operaționale.
2. 02IndexConținutul devine căutabil, cu metadata care spune de unde vine și pentru cine este vizibil.
3. 03RetrievalSe aduc fragmentele relevante pentru întrebarea concretă, nu tot ce conține cuvântul căutat.
4. 04ContextMaterialul selectat se compune într-un context coerent, cu sursele atașate.
5. 05Product / AIRezultatul apare acolo unde se lucrează: în produs, în flux, în ecranul operatorului.

• 01ToolsFiecare instrument are un scop îngust, o intrare definită și un rezultat previzibil. Un instrument vag produce comportament vag.
• 02API-uriInstrumentele folosesc aceleași contracte ca restul sistemului, cu aceleași verificări — nu o cale ocolitoare creată pentru AI.
• 03AcțiuniCe poate schimba efectiv în sistem este o listă explicită, nu o consecință a ceea ce se întâmplă să fie accesibil.
• 04Permisiuni delimitateFiecare execuție rulează cu drepturile utilizatorului sau ale unei identități de serviciu cu scop restrâns.
• 05ValidareRezultatul este verificat înainte de a produce efecte: formă, reguli de business, coerență cu starea curentă.
• 06RetriesUn pas eșuat se reia în limite definite, fără să repete acțiuni care au produs deja efecte.
• 07Human checkpointsAcțiunile ireversibile sau cu impact extern trec printr-o confirmare umană, cu tot contextul necesar afișat.
• 08Execution traceSe poate reconstitui ce pași au fost executați, în ce ordine, cu ce intrări și cu ce rezultat operațional.

Nu construim autonomie nelimitată. Construim sisteme în care fiecare acțiune automată are un perimetru, o verificare și un loc unde poate fi oprită.

• 01ComputeContainer, serverless sau instanțe dedicate — în funcție de profilul de trafic, de latență și de modul de operare acceptabil.
• 02StorageDate operaționale, fișiere, object storage, arhivă. Fiecare cu propriile cerințe de durabilitate și acces.
• 03NetworkingCe este expus public, ce rămâne intern, cum comunică serviciile între ele și pe unde intră traficul.
• 04EnvironmentsMedii separate, cu resurse și date proprii, astfel încât o verificare să nu poată afecta producția.
• 05ConfigurațieCe diferă între medii este declarat explicit, versionat și separat de cod.
• 06SecretsCredențialele nu stau în cod și nu circulă prin canale de comunicare. Accesul la ele este limitat și înregistrat.
• 07ScalingCe component scalează, la ce semnal și până unde. Scalarea automată fără limite este o problemă de cost, nu o soluție.
• 08Backups & recoveryUn backup are valoare doar dacă restaurarea a fost testată. Obiectivele de recuperare se stabilesc împreună cu organizația.
• 09Managed servicesAcolo unde un serviciu gestionat reduce efortul de operare fără să blocheze arhitectura, este alegerea rezonabilă.

Alegerea furnizorului de infrastructură se face per proiect, în funcție de cerințele de găzduire, integrare și conformitate ale organizației.

1. 01DevelopmentUnde se construiește. Rapid, izolat, cu date de lucru — niciodată cu date reale de producție.
2. 02TestUnde se verifică automat comportamentul: reguli, integrări, regresii, cazuri de eroare.
3. 03StagingCât mai aproape de producție ca formă și configurație. Ultimul loc unde o problemă costă puțin.
4. 04ProductionUnde sistemul are utilizatori reali, date reale și consecințe reale.

1. 01CommitSchimbarea intră versionată, cu autor și context.
2. 02BuildAceleași surse produc același artefact, reproductibil.
3. 03TestVerificări automate: unitare, de integrare, de regresie.
4. 04ValidateVerificări de calitate, securitate și dependențe.
5. 05DeployLivrare în etape, cu posibilitate de oprire și de întoarcere.
6. 06ObserveSe urmărește comportamentul real după livrare, nu doar succesul pipeline-ului.

1. 01UserO identitate verificată — persoană sau serviciu — cu apartenență cunoscută în organizație.
2. 02RoleSetul de responsabilități care descrie ce face acel utilizator în sistem.
3. 03PermissionsDrepturile concrete rezultate din rol, plus limitele impuse de context.
4. 04Data / Action / SystemCe poate citi, ce poate modifica și ce poate declanșa, verificat la fiecare cerere.

• 01TraficMai multe cereri simultane. Se rezolvă prin capacitate, cache și reducerea lucrului per cerere.
• 02Volum de dateAceleași interogări devin mai lente pe zece milioane de rânduri. Se rezolvă prin model, indexare, partiționare și arhivare.
• 03Lucru concurentMai mulți utilizatori pe aceleași înregistrări. Se rezolvă prin blocare, versionare și fluxuri care evită coliziunile.
• 04Procesare de fundalCozile cresc mai repede decât capacitatea de consum. Se rezolvă prin paralelizare, prioritizare și limitare.
• 05Complexitate organizaționalăMai multe echipe pe același sistem. Se rezolvă prin granițe și contracte, nu prin infrastructură.
• 06Sarcină de integrareMai multe sisteme conectate, fiecare cu ritmul și disponibilitatea lui. Se rezolvă prin asincron, izolare și contracte stabile.
• 07Vizibilitate operaționalăLa scară, ce nu este măsurat nu este cunoscut. Observability devine ea însăși o cerință de scalare.

Prima întrebare nu este „cum scalăm", ci „ce anume crește". Răspunsurile arată complet diferit.

• D—01Tipul produsuluiUn produs SaaS, o platformă internă, un portal public și un sistem de procesare au profiluri complet diferite de utilizare și de risc.
• D—02Contextul echipeiCine va menține sistemul după livrare. O tehnologie pe care nimeni din organizație nu o poate opera devine o dependență, nu un avantaj.
• D—03Peisajul de integrareCe sisteme există deja, ce interfețe expun și cât de rigid este ce nu poate fi schimbat.
• D—04Caracteristicile datelorStructură, volum, rată de schimbare, relații, cerințe de istoric și de căutare.
• D—05LatențăCe trebuie să fie instantaneu pentru utilizator și ce poate aștepta câteva secunde sau câteva minute.
• D—06ScalăCe anume crește, cât de repede și în ce direcție — trafic, date, utilizatori, integrări sau echipe.
• D—07Constrângeri de conformitateCerințe legale sau interne privind locul datelor, accesul, păstrarea și auditul.
• D—08Modelul de deploymentCloud, infrastructură proprie sau mixt — decis de context organizațional, nu de preferință tehnică.
• D—09Maturitatea operaționalăCe poate fi operat realist: monitorizare, intervenție, actualizări, răspuns la incidente.
• D—10Mentenabilitate pe termen lungCât de ușor va fi de înțeles și de modificat sistemul de către cineva care ajunge la el peste trei ani.

Discutăm categorii tehnice și opțiuni reprezentative în funcție de context. Folosirea unei tehnologii sau a unui furnizor nu implică un parteneriat formal cu producătorul acesteia.

• 01ReplaceComponenta este înlocuită complet. Justificat când costul de menținere depășește costul de reconstrucție și granițele sunt clare.
• 02RefactorStructura internă se schimbă, comportamentul rămâne. Cea mai ieftină cale când problema este organizarea codului, nu tehnologia.
• 03ReplatformAceeași aplicație, alt mediu de rulare. Rezolvă probleme de operare, cost sau scalare, fără a atinge logica.
• 04IsolatePartea problematică este delimitată clar, ca să nu se răspândească mai departe și să poată fi tratată separat.
• 05WrapSistemul vechi primește o interfață modernă în față. Restul arhitecturii poate avansa fără să îl aștepte.
• 06MigrateTrecerea se face incremental, cu ambele variante funcționale o perioadă și cu o cale de întoarcere.

Nu rescriem un sistem doar pentru că un framework este vechi. Rescriem atunci când vechimea lui produce o limitare pe care organizația o simte: un cost, un risc sau o schimbare imposibilă.

Product Modernization →

1. ABuild Când capabilitatea ține de logica proprie a produsului sau de ceea ce diferențiază organizația. Aici, o soluție generică ar impune procesul altcuiva.
2. BBuy Când există o capabilitate matură, standardizată, pe care nimeni nu câștigă nimic reconstruind-o. Costul real nu este licența, ci integrarea și dependența.
3. CIntegrate Când valoarea vine din legarea sistemelor existente. Ce lipsește nu este o funcționalitate nouă, ci un traseu coerent între cele care există deja.

• 01
  Understand

  Constrângerile reale ale organizației — operaționale, legale, de echipă — apar aici. Ele elimină, de obicei, jumătate din opțiunile tehnice.

• 02
  Map

  Procesele, datele și sistemele existente arată unde trebuie să treacă granițele arhitecturii.

• 03
  Architect

  Se stabilesc straturile, contractele, modelul de date și deciziile tehnologice — cu motivele scrise, nu doar cu rezultatul.

• 04
  Build

  Prima parte construită confirmă sau infirmă arhitectura. Aici se corectează ce nu s-a văzut pe diagramă.

• 05
  Validate

  Comportamentul este verificat pe cazuri reale, inclusiv pe cele de eroare, nu doar pe traseul fericit.

• 06
  Operate

  Producția arată ce a fost subestimat: latență, volum, dependențe, moduri de utilizare neprevăzute.

• 07
  Evolve

  Cerințele noi testează dacă granițele alese chiar permit schimbarea. Acesta este examenul final al oricărei arhitecturi.

Vezi Process →

1. 01Current systemCe funcționează astăzi, cu granițele și contractele deja stabilite.
2. 02New requirementO cerință care nu a fost prevăzută — pentru că nicio arhitectură nu prevede tot.
3. 03Change boundarySe identifică exact ce parte se modifică și ce rămâne neatins. Aici se plătește calitatea granițelor.
4. 04TestTestele existente confirmă că restul sistemului nu a fost afectat.

1. 05DeployLivrare în etape, cu cale de întoarcere pregătită.
2. 06ObserveSe urmărește comportamentul real, nu doar absența erorilor.
3. 07Stable systemSistemul revine într-o stare stabilă, cu o capabilitate în plus și fără datorie ascunsă.

• T—01Viteză vs. flexibilitateO structură mai simplă livrează mai repede; una mai generală acceptă mai ușor schimbări. Alegerea depinde de cât de sigur este contextul.
• T—02Simplitate vs. distribuireServiciile separate rezolvă independența, dar adaugă rețea, consistență și operare. Costul se plătește zilnic.
• T—03Consistență vs. disponibilitateUnele operațiuni trebuie să fie corecte imediat; altele pot fi corecte în câteva secunde. Cele două cerințe nu se pot maximiza simultan.
• T—04Build vs. buyControl complet și cost de menținere, sau viteză și dependență. Decizia se ia pe componentă, nu pe sistem.
• T—05Sincron vs. asincronRăspunsul imediat este simplu de înțeles; procesarea separată este mai rezistentă, dar cere gestionarea stării intermediare.
• T—06Automatizare vs. control umanAutomatizarea scade efortul și crește viteza; verificarea umană scade riscul. Pragul se stabilește pe impactul acțiunii.
• T—07Capabilitate AI vs. determinismUn model acoperă mai multe cazuri, dar cu rezultate variabile. O regulă acoperă mai puțin, identic de fiecare dată.
• T—08Abstractizare vs. transparențăAbstracția reduce repetiția, dar ascunde ce se întâmplă. Prea multă abstracție face debugging-ul mai scump decât codul economisit.

Nu rezolvăm aceste tensiuni o dată pentru totdeauna. Le rezolvăm de fiecare dată, explicit, și scriem motivul — pentru că peste doi ani contextul poate cere alt răspuns.

• 01Schimbare mai rapidă și controlatăO cerință nouă are un loc evident unde se implementează și un mod evident de a fi verificată.
• 02Ownership mai clarSe știe cine răspunde de fiecare parte a sistemului și de fiecare tip de dată.
• 03Integrare mai ușoarăUn sistem nou care trebuie conectat găsește contracte existente, nu are nevoie de o excepție.
• 04Operare observabilăCând ceva nu merge, întrebarea „unde" primește răspuns în minute, nu în zile.
• 05Evoluție mai sigurăSchimbările pot fi livrate mai des, tocmai pentru că fiecare este mai mică și reversibilă.
• 06Date reutilizabileAceeași informație susține produsul, raportarea, integrarea și AI-ul, fără copii care se contrazic.
• 07Experiență mai bunăInterfața poate fi îmbunătățită fără să atingă logica, iar performanța nu se degradează pe măsură ce cresc datele.
• 08AI-readinessContextul, permisiunile și fluxurile există deja — AI-ul se adaugă unde are sens, nu se construiește pe lângă sistem.

33 Convergență

Opt decizii tehnice care produc un singur rezultat.