arhitectura IT. Permiteți-mi să vă spun de ce

Ne place să desenăm !!

(Miguel Angel Coll) (2 iulie 2020)

Am investit ultimii 5 ani în cariera mea lucrând în jurul funcției de arhitectură IT. În toți acei ani, a trebuit să justific simpla existență a funcției Arhitectură chiar și pentru mine. Uneori, de asemenea, simțim că suntem intruși înconjurați de oamenii care într-adevăr fac treaba (dezvoltatori și sisteme de operare).

După 5 ani sunt încă convins că arhitectura contează, permiteți-mi să vă ofer câteva argumente pentru dovedește-l.

Cel mai bun raport calitate-preț

Dacă trebuie să aleg o singură misiune pentru arhitectura IT, o voi alege pe aceasta. Departamentele și platformele IT sunt de obicei doar în creștere. Unele dintre ele pentru că compania crește, altele pentru că compania se află în mijlocul unei transformări digitale. În orice caz, rezultatul este același, de la an la an aveți mai multe sisteme, mai multe echipe, mai multă complexitate.

Îmi place să simplific hiper-simplificarea unei platforme IT, după cum urmează:

Funcția principală Arhitectură este de a păstra relația cu Costul platformei IT și valoarea pe care o oferă într-o formă bună.

În urmă cu ceva timp am lucrat într-o companie de turism cu un model de afaceri bazat pe distribuția produselor online prin intermediul API-urilor. Aceste API-uri au fost puternic cuplate cu un imens sistem monolit bazat pe Oracle Exadata. Asta înseamnă că de fiecare dată când creștem pe trafic API (iar traficul crește mai mult decât rata de conversie) trebuie să ne scalăm baza de date pe verticală.

Arhitectura conduce la eficiența platformei IT

Propunerea de arhitectură la acel moment a fost de a decupla serviciile API creând un nou strat de servicii micro cloud pentru a gestiona tot traficul cu costuri mai mici, păstrând în același timp infrastructura bazei de date doar pentru rezervare și operațiuni (care, din păcate, nu cresc exponențial). Rezultatul, nu a mai fost nevoie de o infrastructură nouă pentru DB în anii următori și o relație mai bună între trafic și costurile IT.

Utilizați același limbaj

Nu vă faceți griji că sunt fără a vorbi despre limbaje de programare (java, python etc.). Ca arhitect, sunt mai mult decât deschis pentru diversitate cu un anumit control (nu haos). Aici mă refer la Conceptual Integrity, termen pe care l-am citit prima dată pe Mythical Man Month și alte eseuri despre ingineria software de la Frederick P . Brooks Jr.

În carte, Fred Brooks explică modul în care cresc echipele IT și impactul acestora asupra productivității. Pentru Fred, una dintre cele mai mari probleme de abordat atunci când încercați să scalați o echipă IT este comunicarea între echipe. Pentru a paralela sarcinile, aveți nevoie ca echipele să fie cât mai independente. Dar, de îndată ce toate echipele lucrează pe o platformă interconectată, avem nevoie de o oarecare comunicare între echipe. Este în acele scenarii când a avea un limbaj comun este cheia succesului.

Îmi amintesc încă de conversații nesfârșite cu foștii mei colegi de echipă discutând despre ce este un sistem, o componentă tehnologică, o interfață sau un element de bază. Dacă lucrați la un departament IT mare, probabil știți cât de frustrant este faptul că lucrurile sunt numite diferit de către echipe. Uneori este chiar mai rău atunci când folosesc același nume pentru lucruri diferite.

Un exemplu obișnuit al ultimului, este denumirea unei aplicații monolit cu un singur nume. Chiar și are sens (deoarece este un monolit), atunci când doriți să spargeți acel monolit, veți avea nevoie de mai multe detalii. Introducerea diferitelor nume pentru baza de date, frontend-ul, modelul de date etc. vă va ajuta în proces.

Chiar dacă vă aflați într-un departament IT mic sau unul mai mare, este întotdeauna un moment bun pentru a începe cu o convenție de denumire, un catalog de servicii / sistem / soluții etc. Nu știi niciodată cât de mare vei fi în viitor.

Despre integritatea conceptuală, cu mine, cu cât mai repede, cu atât mai bine.

Forțează conversațiile de proiectare

În mintea mea, fiecare soluție la o problemă începe întotdeauna cu un analiza situației și proiectarea soluției înainte de implementare. Realitatea pentru o echipă de dezvoltare este că în fiecare săptămână avem noi probleme de rezolvat pe masă. După câteva luni de rutine Business as Usual, echipele încep să ruleze pe pilot automat și găsesc soluții la probleme fără să se gândească prea mult la implicațiile pe termen mediu și lung.

Funcția de arhitectură integrată în echipele de dezvoltare ajută întotdeauna pe creșterea conversațiilor de design pentru a găsi cele mai bune soluții la problemele cu care ne confruntăm.

De asemenea, îmi place să contest procesul vechi de dezvoltare a modei în care designul este văzut ca ceva de făcut chiar la începutul unui proiect.În articolul Liftul arhitectului – Vizitarea etajelor superioare , Gregor Hohpe descrie înțelegerea mea despre rolul Arhitecturii perfect:

„… Deci, în loc să încredințez toate deciziile cruciale unei singure persoane, riscul proiectului poate fi redus cu minimizarea numărului de decizii ireversibile .”

Arhitectura trebuie să existe pe tot procesul de dezvoltare . Într-adevăr, dacă lucrați la Agile, veți lua decizii cu privire la fiecare iterație.

Discuții strategice

Ca tip IT, îmi va plăcea să fiu în consiliul de administrație al companiei având foarte și discuții tehnice detaliate. Realitatea pentru companiile mijlocii și mari este că membrii consiliului nu își pot permite să aprofundeze detaliile. Dar, ar trebui Consiliul de administrație să ia decizii cu privire la strategie fără a înțelege situația IT?

În lumea actuală, există doar câteva companii care pot spune că IT-ul nu se află în centrul strategiei lor. Atunci, cine este responsabil pentru traducerea strategiei în IT și invers? – știți deja răspunsul.

Una dintre cele mai mari contribuții ale noastre în echipa de arhitectură TUI Destination Experiences a fost de a desena un model de arhitectură țintă. TAM permite persoanelor care nu sunt IT să înțeleagă principalele noastre soluții și sisteme și cum sunt conectate la fluxurile de valoare ale companiei noastre. După distribuirea TAM-ului, majoritatea conversațiilor noastre strategice au început prin a arăta cum arată arhitectura noastră și cum ar trebui să ne adaptăm la o nouă situație.

Dar fii atent, un model de arhitectură țintă nu trebuie să fie static imaginea arhitecturii „așa cum este” și „a fi”. Încercarea de a face acest tip de exercițiu va sfârși cu ceva efemer care se potrivește doar unui anumit proiect. În opinia mea, este mai bine să vă concentrați pe desenarea principalelor componente ale arhitecturii dvs. și selectarea lucrurilor pe care doriți să le păstrați (deoarece sunt nucleul afacerii dvs.) și indicarea lucrurilor pe care va trebui să le schimbați sau să le evoluați.

Prima diapozitivă a prezentării TAM

Amintiți-vă întotdeauna ce a spus Dee Hock, fondatorul Visa:

Scopul și principiile simple, clare dau naștere unui comportament inteligent complex. Regulile și reglementările complexe dau naștere la un comportament stupid simplu.

La infinit și dincolo

Obsesia pentru a fi agil transformă uneori echipele IT într-un factor de decizie pe termen scurt. . După cum am discutat deja, trebuie să fim siguri că deciziile pe care le luăm astăzi sunt valabile pentru viitor. Uneori înseamnă să ai o viziune clară asupra strategiei pe termen lung. Uneori înseamnă să fii atent să nu fii blocat într-o soluție care nu se potrivește viitorului tău. De cele mai multe ori înseamnă asigurarea unui nivel implicit de calitate și posibilitatea de adaptare la orice a venit.

După cum am comentat deja, arhitectura trebuie să funcționeze și la nivel strategic. Asta înseamnă că probabil va avea informații noi despre posibilitățile viitoare care ar putea afecta platforma IT. Uneori, aceste schimbări strategice sunt chiar confidențiale. Posibilitatea de a influența asupra unor decizii care încearcă să evite mișcările de regret este uneori o sarcină dificilă, deoarece persoanele neinformate nu vor înțelege niciodată adevăratul motiv din spate.

La un moment dat, ne-am aflat în mijlocul discuție despre îmbunătățirea arhitecturii platformei B2C. Chiar are sens să îmbunătățim mult arhitectura. Dar unii dintre noi știam că suntem în conversații pentru a dobândi o companie care să înlocuiască platforma noastră B2C.

Crede-mă, nu este întotdeauna ușor să fii arhitect, dar trebuie să te gândești întotdeauna la ce este cel mai bun pentru companie.

Și, de asemenea, …

… De asemenea, ne place să desenăm și vom face biroul mult mai cool.

Echipa de dezvoltare având discuții folosind o diagramă de arhitectură

Sper că această postare modestă contribuie în viitor la înțelegerea unei lucrări atât de frumoase.

Migue Coll, șef domeniu tehnologie la Tui Destination Experiences.