Rozwój kariery architekta

Od 2 lat pracuje na stanowisku architekta IT w małej firmie. Jestem tam jedyną osobą, która nie jest programistą albo kierownikiem. Wcześniej pracowałem jako analityk systemowy i programista i jako że trafiając do aktualnej firmy byłem (i nadal jestem) jedyną osobą jaka ma doświadczenie w innych firmach i projektach oraz umie robić analizy to zostałem architektem. Na początku nie powiem podobało mi się i stanowisko ładnie łechtało mojego ego. Natomiast ładnym wpisem w CV nie mam za bardzo możliwości rozwoju kariery bo w firmie nie ma się od kogo uczyć czy z kim konsultować.
Czego powinienem się uczuć jako w sumie aspirujący junior (jak to brzmi) architekt i jakie źródła możecie do tego polecić?

Moje obowiązki to robienie analiz systemowych, projekty architektury na poziomie doboru aplikacji do realizacji procesu i powiązania między nimi, projekty API i baz danych.

https://www . youtube . com / @PatoArchitekci (głupi parser generuje z tego film) wbrew pozorom dużo praktycznej wiedzy.

ehhhhh napisał(a):

https://www . youtube . com / @PatoArchitekci (głupi parser generuje z tego film) wbrew pozorom dużo praktycznej wiedzy.

Znam ich podcast, całkiem ciekawe rzeczy poruszają w praktycznym wykorzystaniu.

A jaki stack?
Ogólnie to pewnie trzeba śledzić nowości, nie koniecznie po to, żeby implementować od razu, ale wiedzieć jaki jest kierunek. Na pewno chmury to na rynku podstawa teraz też dla architektów.

Cloud

PaulGilbert napisał(a):

A jaki stack?
Ogólnie to pewnie trzeba śledzić nowości, nie koniecznie po to, żeby implementować od razu, ale wiedzieć jaki jest kierunek. Na pewno chmury to na rynku podstawa teraz też dla architektów.

No właśnie widzę że w większości ogłoszeń przewija się chmura a niestety aktualnie nie korzystam z chmury a jakieś szkolenie miałem dawno więc jest nic nie warte :(
Stack devowy: PHP, Symfony, Laravel, Node.JS, Pyhton, Postgres, MySQL,
Stack analityczno-architektoniczny: BPMN, UML, ERD, C4, API, REST, SOAP, SOA

To załóż sobie konto na AWS czy Azure i korzystaj. Generalnie płacisz za to, z czego korzystasz, więc jak nie zapomnisz czegoś wyłączyć, to wielkich rachunków nie powinieneś ponieść. Do tego jakieś szkolenia + certyfikat może jakiś z clouda. Do tego czytaj o architekturze mikroserwisów, K8S, Istio. Do tego monitoring (ElasticStack, Grafana). Architekt powinien też orientować się w CICD w tych czasach - czyli trochę DevOps, czy innymi słowy, jak ograniczać koszty klienta dzięki automatyzacji procesów budowania i wdrażania aplikacji.

Generalnie jak chcesz się dalej rozwijać, to tematów jest od groma do ogarnięcia.

Oprócz bycia na bieżąco z technologią jak koledzy wyżej napisali, trzeba mieć też w niej doświadczenie. Teoria zawsze będzie tylko teorią. To że coś fajnie wygląda na blogu czy prezentacji to nie wszystko. O tym czy ktoś jest dobrym architektem nie świadczy to ile wzorców zna na pamięć, tylko to czego się przez lata nauczył na realnych projektach i co może wnieść z tą wiedzą do firmy.

Mi zawsze w takiej sytuacji pomagała zmiana firmy. Więc jeżeli nie masz możliwości zastosowania tej teorii (chmura, devops, mirkoserwisy, k8s) w praktyce w obecnej firmie, to nadrabiaj zaległości w teorii i jak najszybciej szukaj nowej, która umożliwi ci wykorzystanie tej wiedzy w praktyce na realnych projektach.

Jarka zawsze warto posluchac: (btw na YT jest jeszcze kilka fajnych prezentacji ktore zrobil o architekturze)

Nie wiem, czym konkretnie chcesz się zajmować, wiec napisze trochę szeroko. Samo pojęcie „architekt IT” jest mega pojemne - od analityka po principal engineera.

Poleciłbym pozycje takie jak Fundamentals of Software Architecture czy Software Architecture: The Hard Parts, żeby poczytać trochę o systemach rozproszonych. Fajne jest też Team Topologies i podobno dobrze napisane jest Learning Domain-Driven Design.

Nie znam żadnych pozycji odnośnie architektury wdrożeniowej, ale trzeba się orientować - dockery, kubernetesy, chmury, serverless, meshe.

Z prezentacji, to szukaj na YT prezentacji od Łukasza Szydło - zawsze dobry kontent i ciekawe spojrzenie. Do tego super są nagrania z AWS re:invent. I pewnie wiele innych, zależy czego się szuka.

Języki programowania i frameworki to rzecz wtórna.

Czego powinienem się uczuć jako w sumie aspirujący junior (jak to brzmi) architekt i jakie źródła możecie do tego polecić?

W jednej firmie okrzykną Cię architektem, w drugiej juniorem.

Dlatego powinieneś uczyć się tego samego co reszta, tu nie ma drogi na skróty.

wszystko sprowadza się do harmonii kilku elementów:

• teoria/wiedza
• doświadczenie/pragmatyzm
• krytyczne spojrzenie
• zrozumienie potrzeb biznesowych

Ktoś nasiąknięty samymi teoriami (bez praktycznego podejścia) zrobi overengineering, bo tak jest w książce. Będzie wrzucać wzorce, gdzie popadnie i komplikować proste rzeczy. Oprogramowanie wyglądające mądrze, żeby wyglądało.

Ale praktyk bez wiedzy i znajomości powszechnych standardów to też niedobrze, bo taka osoba zrobi ci coś totalnie dziwnego, gdzie będziesz się łapać za głowę, co tam jest odpieprzone.

Ktoś bez krytycznego spojrzenia, bez zrozumienia potrzeb biznesowych i bez pragmatyzmu - zacznie uprawiać hype driven development (albo resume driven development). I będzie proponować rozwiązania, żeby móc się rozwijać w pracy i bawić się nowymi technologiami, a nie po to, żeby zaspokoić jakąś realną potrzebę biznesową
"słuchaj stary, w pracy ustawiłem sobie tak, że mogę się uczyć z 10 różnych technologii, a za pół roku zmieniam pracę i idę na seniora, bo będę miał wiedzę"

Niestety mam wrażenie, że to co się nazywa zwykle architekturą to właśnie albo totalny overengineering i cargo cult, albo wesoła twórczość seniora, który odleciał, albo efekt uboczny tego, że zespół developerski chciał się pobawić i porozwijać.

LukeJL napisał(a):

wszystko sprowadza się do harmonii kilku elementów:

• teoria/wiedza
• doświadczenie/pragmatyzm
• krytyczne spojrzenie
• zrozumienie potrzeb biznesowych

Ktoś nasiąknięty samymi teoriami (bez praktycznego podejścia) zrobi overengineering, bo tak jest w książce. Będzie wrzucać wzorce, gdzie popadnie i komplikować proste rzeczy. Oprogramowanie wyglądające mądrze, żeby wyglądało.

Ale praktyk bez wiedzy i znajomości powszechnych standardów to też niedobrze, bo taka osoba zrobi ci coś totalnie dziwnego, gdzie będziesz się łapać za głowę, co tam jest odpieprzone.

Ktoś bez krytycznego spojrzenia, bez zrozumienia potrzeb biznesowych i bez pragmatyzmu - zacznie uprawiać hype driven development (albo resume driven development). I będzie proponować rozwiązania, żeby móc się rozwijać w pracy i bawić się nowymi technologiami, a nie po to, żeby zaspokoić jakąś realną potrzebę biznesową
"słuchaj stary, w pracy ustawiłem sobie tak, że mogę się uczyć z 10 różnych technologii, a za pół roku zmieniam pracę i idę na seniora, bo będę miał wiedzę"

Niestety mam wrażenie, że to co się nazywa zwykle architekturą to właśnie albo totalny overengineering i cargo cult, albo wesoła twórczość seniora, który odleciał, albo efekt uboczny tego, że zespół developerski chciał się pobawić i porozwijać.

Zgadzam się z tobą że podstawowa cecha pracy w IT to jest zrozumienie tego że robimy coś dla biznesu i spełnienie wymagań to rzecz jaką musimy zrobić. Technologia to z punktu widzenia firmy drugorzędna sprawa. Niestety dużo ludzi woli w pracy bawić się i żeby mu za to płacili a nie robić robotę.
Co do tego że architektura to czyjaś wesoła twórczość to jednak ktoś musi mieć ogląd na całość rozwiązań, powiązań między nimi itd.

podstawowa cecha pracy w IT to jest zrozumienie tego że robimy coś dla biznesu

IT nie jest pod tym względem specjalne i jedyne. To po prostu podejście z nastawieniem na komercję. Nie jest to mądre ani szlachetne, ale inne podejście służy konkurencji.

IT dla większości firm jest kosztem, tak samo graficy, księgowe. Podstawą dla IT jest świadomość rozwiązań, ich możliwości i kosztów, aby z jednej strony głupio nie wydawać kasy, a z drugiej sensownie dopasować rozwiązania do potrzeb i ryzyk jakie odnoszą się do firmy. Inaczej wszystko sprowadziłoby się do tego, aby zatrudniać tanią siłę roboczą i pisać w tym co jest najpowszechniejsze.

Niestety dużo ludzi woli w pracy bawić się i żeby mu za to płacili a nie robić robotę.

Nie chodzi o zabawę, lecz rozwój. Typowy etatowy pracownik ma mniej szans na rozwój jeśli ograniczy się tylko do jednej technologii. Nawet jeśli osoba zacznie uczyć się w domu to będzie narastać w niej pragnienie wykorzystania tego co już poznała, aby nie okazało się, że nauka skończyła się wyłacznie na teoretyzowaniu. Taka osoba będzie skłaniać się do tego, aby wypróbować to choćby w mniejszym stopniu, aby jednak nabić trochę w tym doświadczenia. Kasa i w szczególności doświadczenie to główne rzeczy jakie pracownik wyciąga po zakończeniu etatu. Zauważ, że pracodawca nie daje pracownikowi udziałów, nawet praw autorskich.

LukeJL napisał(a):

Niestety mam wrażenie, że to co się nazywa zwykle architekturą to właśnie albo totalny overengineering i cargo cult, albo wesoła twórczość seniora, który odleciał, albo efekt uboczny tego, że zespół developerski chciał się pobawić i porozwijać.

W słabych firmach tak właśnie jest, pytanie z kim się chcemy porównywać, do czego dążyć.