Darrere de tota arquitectura hi ha persones que prenen decisions, les comuniquen i vetllen perquè es compleixin. L'arquitecte de programari és aquest professional pont entre el negoci i la tècnica, entre la visió global i el codi concret. Tanmateix, és un dels rols pitjor entesos de la indústria: de vegades es confon amb el d'un programador sènior, altres amb el d'un gestor que dibuixa diagrames i desapareix. En aquesta lliçó aclarim què fa realment un arquitecte, quins tipus existeixen, quines habilitats necessita —tant tècniques com toves— i com es diferencia del líder tècnic, una distinció que genera molta confusió en els equips.

1. Què és i què fa un arquitecte de programari
2. Responsabilitats principals
3. Tipus d'arquitecte
4. Habilitats tècniques
5. Habilitats toves
6. Arquitecte davant de líder tècnic

Un arquitecte de programari és la persona responsable de les decisions tècniques significatives d'un sistema: les que afecten la seva estructura, els seus atributs de qualitat i la seva capacitat d'evolució. No és algú que es limita a dibuixar diagrames en una pissarra i delegar tota la resta; els millors arquitectes segueixen a prop del codi i dels equips.

Una distinció útil és la de Martin Fowler entre dos arquetips:

La indústria ha evolucionat cap al segon model: l'arquitecte com a facilitador i mentor, no com a dictador tècnic aïllat.

Les responsabilitats varien segons l'organització, però aquestes són les més comunes:

• Definir l'estructura del sistema: estils, patrons i límits entre components.
• Gestionar els atributs de qualitat: assegurar que rendiment, seguretat, escalabilitat, etc., es compleixen.
• Prendre i documentar decisions: i, sobretot, registrar el perquè (amb ADR, que veurem més endavant).
• Avaluar tecnologies: fer proves de concepte, comparar alternatives, gestionar riscos.
• Comunicar l'arquitectura: a desenvolupadors, a gestors i a stakeholders de negoci, adaptant el llenguatge a cada audiència.
• Fer de mentor de l'equip: elevar el nivell tècnic col·lectiu en lloc de concentrar el coneixement.
• Vigilar la coherència: revisar que la implementació respecta les decisions (governança lleugera, no policia del codi).

Un bon lema: l'arquitecte no és qui té totes les respostes, sinó qui fa les preguntes correctes i ajuda l'equip a respondre-les.

El títol "arquitecte" cobreix rols molt diferents segons l'abast i el focus. Convé conèixer-los per saber amb qui es parla en cada conversa.

Aquest diagrama Mermaid (graph TD, de dalt a baix) mostra com l'arquitecte empresarial opera en el nivell més ampli i la resta de rols operen en àmbits més acotats. Les fletxes indiquen relació d'abast/coordinació, no jerarquia de comandament estricta: en moltes organitzacions aquests rols col·laboren com a iguals amb focus diferents.

Un arquitecte ha de mantenir una base tècnica sòlida i àmplia. No necessita ser el millor programador de l'equip, però sí entendre en profunditat allò que decideix.

• Amplitud per sobre de la profunditat: coneix moltes tecnologies a un nivell suficient per avaluar-les, encara que no les domini totes al detall. És el perfil "en forma de T" (T-shaped): molta amplitud i almenys una àrea d'especialització profunda.
• Patrons i estils arquitectònics: capes, hexagonal, microserveis, esdeveniments, etc.
• Atributs de qualitat i com aconseguir-los: memòria cau, balanceig, replicació, particionat.
• Coneixement de dades: modelatge relacional i no relacional, consistència, transaccions.
• Fonaments de xarxes, seguretat i desplegament.
• Capacitat de prototipar: fer una prova de concepte per validar una decisió abans de comprometre-s'hi.

Aquest fragment Java il·lustra una decisió tècnica típica de l'arquitecte: definir la interfície PassarelaDePagament (un port en l'arquitectura hexagonal) perquè la resta del sistema no depengui d'un proveïdor concret. La classe PassarelaStripe és una implementació que es pot substituir per una altra (per exemple, PassarelaRedsys) sense tocar la lògica de negoci. L'arquitecte no necessàriament escriu tot el codi, però sí que valida que l'abstracció és correcta i que l'equip l'entén, possiblement construint ell mateix aquest prototip mínim.

Aquí és on molts arquitectes tècnicament brillants fracassen. Les habilitats toves no són "allò tou" del rol: en són el nucli.

• Comunicació: explicar allò complex de manera senzilla, adaptant el missatge a desenvolupadors, gestors o clients.
• Negociació i gestió de trade-offs: gairebé cap decisió és perfecta; cal negociar entre interessos i limitacions.
• Escolta activa: les millors idees solen venir de l'equip que està al codi cada dia.
• Lideratge per influència: l'arquitecte rarament té autoritat jeràrquica directa; convenç, no ordena.
• Pensament estratègic: connectar decisions tècniques amb objectius de negoci.
• Tolerància a l'ambigüitat: decidir amb informació incompleta i sota incertesa.

Una regla pràctica: un arquitecte passa més temps en converses i diagrames explicatius que escrivint diagrames UML perfectes. L'arquitectura que ningú entén ni adopta no serveix de res.

Aquesta és una de les confusions més habituals. Ambdós rols poden coincidir en una mateixa persona, però conceptualment són diferents.

En equips petits, una sola persona exerceix ambdós rols. En organitzacions grans, se solen separar: l'arquitecte defineix el "què" i el "perquè" estructural; el líder tècnic s'assegura del "com" i el "quan" en el seu equip. L'important és que col·laborin estretament, perquè una arquitectura sense algú que vetlli per la seva execució diària es dilueix, i un líder tècnic sense visió arquitectònica acumula deute sense adonar-se'n.

• L'"arquitecte de torre d'ivori". Dissenyar des de l'aïllament, sense tocar el codi ni escoltar l'equip, produeix arquitectures boniques sobre el paper i inviables a la pràctica. Mantén un peu al codi.
• Confondre autoritat amb influència. L'arquitecte convenç amb arguments i dades, no imposa per jerarquia. Imposar genera resistència i arquitectures que l'equip sabotejarà passivament.
• Descuidar les habilitats toves. L'excel·lència tècnica sense comunicació és un arquitecte a mitges.
• No documentar el perquè. Les decisions sense context es qüestionen un cop i un altre. Documenta el raonament.
• Consell: especialitza't però mantén amplitud. Cultiva el perfil en T. Aprofundeix en una àrea, però entén prou de la resta per decidir amb criteri.

Exercici 1. En una startup de 8 persones amb un únic equip de desenvolupament, separaries els rols d'arquitecte i líder tècnic? Justifica la teva resposta.

Exercici 2. Associa cada tasca amb el tipus d'arquitecte més adequat: (a) dissenyar la integració entre el sistema de RH i el de nòmines d'un client; (b) definir les polítiques de retenció i qualitat de dades de l'empresa; (c) escollir el patró intern d'un microservei; (d) traçar el roadmap de migració al núvol de tota la companyia a 3 anys.

Exercici 3. Un arquitecte proposa migrar a microserveis i l'equip s'hi resisteix. Sense usar autoritat jeràrquica, enumera tres accions concretes basades en habilitats toves per aconseguir-ne l'adopció.

Solució 1. Probablement no convé separar-los formalment: amb 8 persones i un sol equip, mantenir dos rols diferents afegeix burocràcia. El raonable és que una persona exerceixi ambdós (o que les responsabilitats arquitectòniques es comparteixin dins l'equip), reservant temps explícit per pensar en l'estructura i no només en el lliurament immediat.

Solució 2. (a) Arquitecte de solucions. (b) Arquitecte de dades. (c) Arquitecte de programari. (d) Arquitecte empresarial.

Solució 3. Exemples vàlids: (1) Escoltar activament les objeccions de l'equip per entendre el perquè de la resistència (por a la complexitat operativa?, manca d'experiència?). (2) Construir junts una prova de concepte petita perquè l'equip vegi avantatges i inconvenients amb dades reals, no amb teoria. (3) Comunicar el problema de negoci que es vol resoldre (per exemple, escalar només el mòdul més carregat) en lloc d'imposar la solució, deixant que l'equip participi en el disseny i s'apropiï de la decisió.

Hem vist que l'arquitecte de programari és responsable de les decisions tècniques significatives, que existeixen diversos tipus segons l'abast (programari, solucions, empresarial, dades, infraestructura), i que el seu èxit depèn tant de la solidesa tècnica com de les habilitats toves, especialment la comunicació i el lideratge per influència. També hem diferenciat el seu rol del de líder tècnic. Ara bé, gran part de la feina de l'arquitecte consisteix a garantir certes propietats del sistema més enllà de la funcionalitat: en la lliçó següent estudiarem els atributs de qualitat i els requisits no funcionals, la matèria primera sobre la qual l'arquitecte pren les seves decisions.