La vremea respectivă, Harvard Business Review a respins lucrarea sa originală pe baza faptului că nu-și demonstrase ipoteza. Cu toate acestea, această observație a devenit cunoscută sub numele de Legea lui Conway, iar experiențele colective atât ale colegilor mei, cât și ale mele, au întărit de nenumărate ori adevărul acestei afirmații. Dar nu trebuie să ne credeți pe cuvânt!
În „Exploring the Duality between Product and Organizational Architectures” (Explorarea dualității dintre arhitecturile de produs și arhitecturile organizaționale), un studiu realizat de The Harvard Business School a efectuat o analiză a diferitelor baze de coduri pentru a vedea dacă pot dovedi ipoteza inițială a lui Conway aplicată la sistemele software. În cadrul acestuia, au fost luate mai multe exemple de software create pentru a rezolva același scop (de exemplu, programe de procesare a textelor, de gestiune financiară și de baze de date) și au fost comparate bazele de cod create de echipe open source slab cuplate și cele create de echipe puternic cuplate. Studiul lor a constatat că echipele de produs, adesea amplasate în același loc și concentrate, au creat software care tindea mai mult spre baze de coduri monolitice, strâns cuplate. În timp ce proiectele open source au avut ca rezultat baze de coduri mai modulare, descompuse.
De câțiva ani încoace, organizațiile au înțeles această legătură dintre structura organizațională și software-ul pe care îl creează și au adoptat noi structuri pentru a obține rezultatul dorit. Netflix și Amazon, de exemplu, se structurează în jurul mai multor echipe mici, fiecare având responsabilitatea pentru o mică parte a sistemului global. Aceste echipe independente pot deține întregul ciclu de viață al serviciilor pe care le creează, ceea ce le oferă un grad mai mare de autonomie decât este posibil pentru echipele mai mari, cu baze de cod mai monolitice. Aceste servicii, cu preocupările lor independente, se pot modifica și evolua separat unele de altele, ceea ce duce la capacitatea de a livra mai rapid modificările în producție. Dacă aceste organizații ar fi adoptat echipe de dimensiuni mai mari, sistemele monolitice mai mari care ar fi apărut nu le-ar fi oferit aceeași capacitate de a experimenta, de a se adapta și, în cele din urmă, de a-și menține clienții mulțumiți.
Poate că observați tensiuni în propriile organizații în care structura și software-ul nu sunt aliniate. Este posibil să fi văzut, de exemplu, provocările implicate atunci când echipe distribuite încearcă să lucreze la aceeași bază de cod monolit. Aici, căile de comunicare la care se referă Conway sunt în contrast cu codul în sine, unde baza de cod unică necesită o comunicare cu granulație fină, dar o echipă distribuită este capabilă doar de o comunicare cu granulație grosieră. Acolo unde apar astfel de tensiuni, căutarea oportunităților de a diviza sistemele monolitice în jurul granițelor organizaționale va aduce adesea avantaje semnificative.
În Radarele tehnologice anterioare am evidențiat popularitatea tot mai mare a microserviciilor, care sunt adoptate din ce în ce mai mult de organizațiile care doresc să îmbunătățească autonomia echipelor lor și să crească viteza de schimbare. Articolul lui Martin Fowler și James Lewis aprofundează subiectul, subliniind faptul că aceste arhitecturi permit organizațiilor o flexibilitate mult mai mare în ceea ce privește alinierea arhitecturii sistemelor lor la structura echipelor lor, pentru a se asigura că legea lui Conway funcționează pentru dumneavoastră. În următoarea ediție a Radarului tehnologic, vom discuta despre reflectarea influenței crescânde a Microserviciilor, de la tehnologia de infrastructură precum Packer sau Docker la instrumentul de descoperire a serviciilor Consul, sau microcontainere precum popularul DropWizard sau destul de noul SpringBoot. Vom discuta, de asemenea, despre reversul – organizațiile care își schimbă structura echipelor pentru a se adapta la sistemele lor IT.
Ne așteptăm pe deplin să vedem mai multe tehnici și tehnologii de sprijin care să apară pentru a permite arhitecturile Microservicii, iar noi le vom urmări în următoarele luni. Între timp, dacă doriți să aflați mai multe, înscrieți-vă pentru cel mai recent Tech Radar, consultați articolul lui Martin și James despre microservicii sau cartea mea de la O’Reilly, Building Microservices.
.