Dacă folosim taxonomia Microsoft, ne aflăm în al treilea val al AI, definiția (tradusă) a acestui val de la Google fiind: "Sisteme autonome capabile să ia inițiativa, să stabilească obiective, să planifice acțiuni complet și să se adapteze pentru a obține rezultate fără supraveghere umană constantă." Pe scurt, Agentic AI.
Agentic AI sau nu este cuvântul la modă și, conform știrilor, va înlocui oamenii din toate domeniile. Suntem în IT, am auzit despre vibe coding și copiloți (agentici) ca developeri, dar cum rămâne cu arhitecții?
Arhitecții beneficiază, de asemenea, de asistența AI, începând cu instrumente "inteligente" care fac diagrame care pot merge de la a asista (agentic) la crearea unei arhitecturi. Cele mai cunoscute tooluri sunt: Mermaid (are o versiune de încercare) și LikeC4 (gratuit), diferite, care creează diagrame de arhitectură cu ajutorul AI și, în unele cazuri, chiar și mai mult. Ceea ce este comun acestor tooluri este că încearcă să descrie părți din arhitectură într-un limbaj. Și, la fel, rezultatele sunt într-un format lizibil extern. Un element care îmi place mult este această descriere a unor elemente ale arhitecturii. Are avantajul de a te forța să ai claritate cu privire la anumite concepte și să le și documentezi. Aceste tooluri folosesc și intern AI, de exemplu, LikeC4 funcționează și ca Visual Studio Code plugin, deci copilot este disponibil. În plus, are și un MCP server, și poți, de exemplu, să îi ceri copilot să schimbe arhitectura din AWS în Azure.
Așadar, pentru că avem arhitectura și diagramele în cod, agenții își pot face de cap. Poți avea și în amonte și în aval instrumente, care folosind agentic AI, de exemplu, din cerințele clientului să genereze fișierul input întru-unul unul din aceste tooluri. În continuare, din fișierele output să genereze un prompt pentru vibe coding sau chiar să codeze soluția.
Sfatul meu este să aruncați un ochi peste aceste tooluri. În cel mai rău caz, o să creați diagrame arhitecturale mult mai ușor.
OQD: Arhitecții nu sunt uitați, beneficiază și ei de AI agentic.
Dar să facem arhitectură la fel ca înainte, doar cu tooluri noi, este ca și cum am pregăti legumele la fel pentru supă și pentru salată. Sistemele pe care le proiectăm sunt (folosesc) AI. Prin urmare, cum ne-ar schimba acest fapt abordarea față de arhitectură a acestor sisteme? Colegii te ajută, nu? Un coleg a descoperit acest articol Reinventing EA for the AI Era: EA Frameworks are Dead. R.I.P. TOGAF. Hello Reflexive Enterprises. Start Architecting intelligence.
Argumentul articolului este că soluțiile tind acum să fie conștiente de sine (stil Terminator), ingerează telemetrie și reacționează la ea, într-un cuvânt devenind reflexive.
Făcând un rezumat, putem afirma că trecem de la o arhitectură statică (aspiratoare robot folosit ca exemplu (prost)) la una reflexivă (Terminator).
| Statică | Reflexivă |
|---|---|
| Cicluri anuale de planificare | Arhitectura este fluidă |
| Control centralizat | Starea arhitecturală este fluidă |
| Schimbarea este predictibilă | Sistemul se auto-asamblează |
| Arhitectura ca plan bătut în cuie | Guvernanța este parte din sistem, nu |
| ceva ce trebuie verificat. |
Este de subliniat că soluțiile se adaptează și astăzi la mediul lor, pe baza telemetriei. Un exemplu sugestiv este auto scalarea unor componente în platformele Cloud, fiind ceva absolut obișnuit. Astfel, premisa articolului nu este SF, ci este ceva perfect tehnic fezabil cu tehnologia actuală. Mergând mai departe, sistemele nu vor mai fi proiectate până la ultimul detaliu, vor fi "inteligente" și vor adăuga ceea ce le lipsește. Telemetria (în toate formele ei) va fi la fel de importantă ca și cerințele inițiale.
Sintetizând ideea, afirmăm că arhitectul va specifica intenția soluției, în loc să plănuiască soluția până la ultimul detaliu. Putem spune chiar că treaba arhitectului constă în a transforma și clarifica cerințele clientului pentru a obține atât Functional Requirements (FR), Nonfunctional Requirements (NFR), cât și Quality Attribute (QA) asociate. Iar sistemul va aduce componentele necesare și se va verifica continuu întrucât îndeplinește FR și NFR (QAs), chiar dacă nu se va modifica corespunzător. Nu știm cum o să arate un Request for Proposal sau o kata de arhitectură în această lume nouă. Se pare că nu își mai au sensul, dar timpul ne va arăta asta. Vedem că rolul Solution Architect evoluează, în sensul că sistemul preia unele din taskurile lui. La fel sistemul, reflexiv, va prelua și taskurile din zona Systems/Infrastructure, atât din partea de arhitectură cât și din partea de execuție. O întrebare pe care această nouă abordare o ridică este ce se întâmplă când sistemul, în mod vădit (deși teoretic se autoguvernează) nu face ce trebuie? Cine stabilește asta și care sunt măsurile de remediere? Posibilitățile care se deschid cu această nouă abordare sunt uluitoare. La fel sunt și posibilele probleme. A zis cineva Terminator?
Scopul acestui articol a fost să scoată în evidență unele aspecte mai delicate, care ne conduc înspre ideea că trebuie să ne schimbăm abordarea arhitecturală odată cu vremurile.
