UML a rola architekta w korpo

Co robią architekci w dużych korpo?
Pracowałem w mniejszych firmach i tam jego rola była zbliżona do team leadera. Robił taski, code review, tłumaczył biznesowe wymagania na techniczne, był pierwszą osobą do kontaktu technicznego w zespole, rozdzielał zadania itp.

Ciekawi mnie jak to wygląda w dużych korpo?
Czy tam każdy fragment systemu jest opisany przeróżnymi diagramami komponentów, klas, sekwencji przepływu. Czy raczej diagramy to rzadkość i dominuje czytanie kodu + 'wiedza plemienna' jeśli chodzi o dokumentacje

konradino898 napisał(a):

Czy tam każdy fragment systemu jest opisany przeróżnymi diagramami komponentów, klas, sekwencji przepływu?

I potem każdy najmniejszy refaktor by wymagał cennego czasu architekta? :P No way, jeśli chodzi o diagramy itp to zazwyczaj jest to na poziomie systemu/komponentów (czyli nie pakietów ani klas).

Co do słowa architect to jest on dosyć ogólny, tutaj są opisane różnice pomiędzy trzema typami architektów:
https://www.leanix.net/en/wiki/ea/enterprise-architect-vs-solution-architect-vs-technical-architect-whats-the-difference

Rozmawiają z innymi architektami - tak w skrócie.
U mnie z "diagramów" wymagany jest ogólny diagram systemu - komponenty, mówi o tym jakie są komponenty, na czym są uruchomione, jak się komunikują (bez szczegółów), jak zabezpieczona jest komunikacja.
Jeżeli uznam, że jakaś nowa funkcja będzie lepiej zrozumiana przez zespoły, które ją będą implementować, to rysuję diagram i dorzucam do opisu ficzera. Czasami jeżeli widzę, ze zespoły gubią się w tym co wymyśliłem :D to dorabiam dokumentację po fakcie.
Jaka jest moja odpowiedzialność:

• Pilnowanie zgodności z korpo-wymaganiami stworzonymi przez innych architektów
• Przekładanie wymagań biznesowych na wymagania techniczne. Robię to na ogólnym poziomie, bez zagłębiania się w szczegóły, które może ogarnąć pojedynczy zespół
• Reprezentuję projekt na wszelkiej maści audytach technicznych
• Ustalam NFR
• Proponuję zespołom pracującym w chmurze zastosowanie tych, albo innych rozwiązań.
• Czasami dołączam się do code review, tak, żeby się upewnić, że w ogniu walki nie położono lachy na jakość.
• Szacuję pracochłonność dużych zadań, żeby dało się je jakoś z sensem poukładać w backlogu.
• Czasami wchodzę w dyskusje typu "czy my mamy sprawdzać poprawność danych, czy oni mają je wysyłać poprawnie", ale ponieważ na ogół odpowiadam "jedno i drugie", to mnie już nie pytają :)

Robię jeszcze sporo innych drobiazgów, które potrafią wypełnić mi czas, ale to mój sposób pracy w moim projekcie, wypracowany z innymi zespołami. Działam na poziomie ~solution

Wymyślają in-housowe frameworki, biblioteki, i narzędzia, aby spalić pracę programistów na wynajdowanie koła na nowo.

Co robią architekci w dużych korpo?

NIC. Jak pracowałem w korpo, to nic nie robili. Dosłownie NIC. Nic nie kodowali, nic nie projektowali, tylko chodzili na jakieś spotkania dla samych siebie nie wiem nawet o czym i lajkowali strony na wiki, ale może w innych korpo jest inaczej.

Czy tam każdy fragment systemu jest opisany przeróżnymi diagramami komponentów, klas, sekwencji przepływu. Czy raczej diagramy to rzadkość i dominuje czytanie kodu + 'wiedza plemienna' jeśli chodzi o dokumentacje

W korpo, w którym pracowałem dokumentacja była mocno sformalizowana pod klienta, a nie pod developerów projektu w specjalnym systemie do dokumentacji obsługiwanym przez osobnych ludzi od dokumentacji, a reszta to była głównie wiedza plemienna i jakieś skrawki wiedzy na wiki. Natomiast w małym startupie, w którym teraz pracuję, sam wszędzie diagramy porobiłem, gdzie miało to sens oraz uzupełniłem dokumentację i chyba jest to pierwszy raz, kiedy projekt, w którym uczestniczę jest robiony "książkowo". W korpo, to jest więcej gadania i polityki, niż roboty.

Cytując klasyka to architekt to taki tytuł który się daje programiście jak nie można dać mu już więcej pieniędzy. Tu gdzie teraz pracuję to jest chyba zaimplementowane bo jeśli dobrze zrozumiałem korpomowę to są tu team leaderzy zwykli i w randze architekta :p
Jak pracowałem w UPC to tam byli architekci end2end i oni ogarniali jak miały się mikroserwisy (lub grupy mikroserwisów) ze sobą komunikować. Dla zwykłych devów było to poza zasięgiem bo różne grupy devów były w różnych krajach i np po roku pracy tam danej nie wiedziałem ile mamy wszystkich mikroserwisów :D