Ja coneixes els sis pilars (subcapítol 27.1) i l’eina per avaluar-te (subcapítol 27.2). Però el Well-Architected Framework només aporta valor si el apliques de veritat en el teu dia a dia, no si el deixes com un document que es revisa una vegada i s’oblida. En aquest subcapítol, que tanca el Capítol 27, veiem com integrar el framework a la pràctica perquè millori contínuament les teves arquitectures.

El major error amb el Well-Architected Framework és tractar-lo com una casella que marcar: fas una revisió una vegada (potser perquè algú ho va demanar), generes un informe, i l’arxives per sempre. Això no serveix de gaire, perquè:

• Les arquitectures canvien constantment (afegeixes funcions, creixes, modifiques coses).
• El que estava bé fa un any pot deixar d’estar-ho (més usuaris, noves amenaces...).
• Una millora detectada que no s’aplica no millora res.

El framework és valuós quan es converteix en una pràctica contínua, part de com treballes, no en un tràmit aïllat.

Analogia: aplicar el framework és com tenir cura de la teva salut. Fer-te un reconeixement mèdic una vegada a la vida i oblidar-te’n no et manté sa. El que funciona són revisions periòdiques + hàbits saludables continus: revisions regulars per detectar problemes a temps, i bons hàbits en el dia a dia. Amb l’arquitectura igual: revisions periòdiques (l’eina) més bones pràctiques incorporades a la teva manera de treballar.

Aplica els principis des del disseny, no quan el sistema ja està construït. És molt més barat i fàcil construir bé des del principi que arreglar després. Quan vagis a dissenyar alguna cosa, repasa els sis pilars com a guia de les preguntes que t’has de fer (com ho asseguro?, què passa si falla?, quant costarà?...).

Programa revisions regulars (amb la Well-Architected Tool, subcapítol 27.2): per exemple, cada cert temps o després de canvis importants. Així detectes com ha evolucionat la teva arquitectura i quins nous riscos han aparegut. Una revisió periòdica manté la qualitat al llarg del temps.

Una revisió pot mostrar moltes millores possibles. No intentis fer-les totes alhora (és aclaparador i irreal). Prioritza: ataca primer els riscos alts (els més greus), i ves millorant la resta progressivament. Recorda l’equilibri entre pilars (subcapítol 27.1): decideix què importa més pel teu cas.

El més potent és que pensar en els sis pilars es torni part de com treballa l’equip, igual que vam veure amb FinOps pels costos (subcapítol 25.5). Que en dissenyar qualsevol cosa, l’equip es pregunti de manera natural per la seguretat, la fiabilitat, el cost, etc. No és responsabilitat d’una sola persona ni d’una sola revisió: és una mentalitat compartida.

No persegueixis l’arquitectura «perfecta» (no existeix, recorda l’equilibri entre pilars). Persegueix la millora contínua: estar sempre una mica millor que abans. Cada revisió que redueix un risc alt és una victòria. És un viatge, no una destinació.

Ben aplicat, el framework crea un cicle que millora els teus sistemes amb el temps:

Cada volta deixa la teva arquitectura una mica millor: més segura, més fiable, més eficient.

Exemple del món real: un equip decideix integrar el Well-Architected Framework en la seva manera de treballar. Adopten tres hàbits: (1) cada nou projecte comença amb una repassada dels sis pilars en la fase de disseny; (2) fan una revisió amb l’eina cada trimestre i després de cada canvi gran; (3) en cada revisió, ataquen els riscos alts primer i registren el progrés. Al cap d’un any, els seus sistemes són notablement més robustos i segurs, i —el més important— l’equip pensa de manera natural en aquestes dimensions en dissenyar. El framework va deixar de ser un document per convertir-se en la seva manera de treballar. Aquesta és la diferència entre conèixer-lo i aplicar-lo.

• El major error és tractar el framework com un tràmit d’una sola vegada; el seu valor està en aplicar-lo de forma contínua. Com tenir cura de la salut: revisions periòdiques + hàbits continus, no un únic reconeixement.
• Claus per aplicar-lo de veritat:
  • Comença aviat (des del disseny), no al final: construir bé a la primera és més barat que reconstruir.
  • Fes-lo periòdic (revisions regulars amb l’eina), no únic: les arquitectures evolucionen.
  • Prioritza els riscos (alts primer), no intentis arreglar-ho tot alhora.
  • Converteix-lo en cultura d’equip (una mentalitat compartida, com FinOps), no responsabilitat d’un sol.
  • Busca millora contínua, no perfecció (no existeix arquitectura perfecta, sinó l’adequada a les teves prioritats).
• Aplicat així, crea un cicle virtuós (dissenyar → construir → revisar → millorar) que deixa els teus sistemes millor a cada volta.

Has completat el Capítol 27! Ja saps avaluar i millorar arquitectures amb el Well-Architected Framework. Al Capítol 28 veurem arquitectures concretes i avançades: les arquitectures serverless a escala, on aplicaràs molts d’aquests principis a dissenys reals.