Jw
1
1
- Ten techniczny architekt jest też DevOpsem (SRE) czy DevOps to wasza kultura pracy w której macie tego architekta?
- Czy do kompletu macie też nietechnicznego architekta?
2.1. Jeśli tak to co robi techniczny architekt i czym to się różni od nietechnicznego architekta?
2.2. Jeśli nie i każdy techniczny architekt to proprostu architekt to co robi wasz architekt jak nie programuje?
0
Chodzi o osobę która nosi tytuł Architekta, jest nią jedyną w zespole (wgl wtf, dwóch architektów nad jednym projektem? co za absurd), i podejmuje decyzje nt rozwoju technologicznego, ale nie umie programować.
1
TomRiddle napisał(a):
Chodzi o osobę która nosi tytuł Architekta, jest nią jedyną w zespole (wgl wtf, dwóch architektów nad jednym projektem? co za absurd),
W korpo nie takie rzeczy się dzieją :P
podejmuje decyzje nt rozwoju technologicznego, ale nie umie programować.
ale tak w ogóle, w ogóle? Czy po prostu programował 10 lat tamu i teraz już nie programuje bo np. rysuje UMLe?
0
KamilAdam napisał(a):
podejmuje decyzje nt rozwoju technologicznego, ale nie umie programować.
ale tak w ogóle, w ogóle? Czy po prostu programował 10 lat tamu i teraz już nie programuje bo np. rysuje UMLe?
W ogóle, w ogóle. Myślę że if i print to jest max możliwości.
1
To może wyjdźmy od drugiej strony: a na czym się zna?
0
WeiXiao napisał(a):
To może wyjdźmy od drugiej strony: a na czym się zna?
Na oprogramowaniu (ale nie wytwarzaniu), AWSach, Terraformach, bazach danych (trochę), etc.
0
WeiXiao napisał(a):
To może wyjdźmy od drugiej strony: a na czym się zna?
I co on tam robi? W Jaki sposob decyduje? Mowi ktora bibliotekę wybrać? Który język? Którą bazę? Którą chmurę?
Już nie wiem co jest jeszcze więcej do decydowania technicznego :(
1
Nie brzmi to źle, niby. Jeżeli potrafi się dogadać z programatorami (liczy z ich zdaniem) i potrafi to przełożyć na infrę to why not?
ale ja się nie znam :P
2
Nazwa roli to drugorzędna sprawa, jaką ma odpowiedzialność, zakres obowiązków w ramach pełnionej roli projektowej? Co produkuje?
2
Mam u siebie takiego. Technicznie mięciutki jak gąbka. Jedynie jest wygadany i umie w te korpo gadki, czego mu odmówić nie można. Niemniej pod kątem tasków, bardzo często rozdziela taski tak, żeby te trudniejsze zrobił ktoś inny a żeby potem mu wytłumaczyć / nauczyć. Chłop ma w tytule technical leader / architect a jedyne w czym jest lepszy/wyróżnia się to skille miękkie.
Czy ma racje bytu? Pod kątem scrumowych g*wno spotkań i innych korpo "mitinguf" jest niezastąpiony. Wie jak rozmawiać i robi to dobrze, przez co kontakt z klientem/external teamem itp jest na fajnym poziomie. Bez takiego gadacza było by zdecydowanie mniej komfortowo. Osobiście staram się stronić jak najbardziej mogę od takich spotkań, bo zwyczajnie mnie męczą.
Wszystko kwestia perspektywy. Zapewne czasami boli fakt, że taki osobnik zarabia 2 a może czy 3x więcej mimo zdecydowanie mniejszych um technicznych, ale nadrabia to soft skillsem. Osobiście widzę go bardziej w roli jakiegoś SM'a czy innego PM'a a nie architecta. Ale co korpo to obyczaj ;)
P.S stack ma identyczny czyli awsy, terraformy itp. Przypadek? :D
5
TomRiddle napisał(a):
Chodzi o osobę która nosi tytuł Architekta, jest nią jedyną w zespole (wgl wtf, dwóch architektów nad jednym projektem? co za absurd), i podejmuje decyzje nt rozwoju technologicznego, ale nie umie programować.
Nawet jeden architekt w zespole jest już tak wielkim absurdem, że dodawanie kolejnych poziomu absurdalności nie zmienia.
Tak ogólnie, to w dzisiejszych czasach raczej zakładałbym od architekta znajomości rzeczy chmurowych, aby wiedział z jakich klocków można poskładać oprogramowanie rozwiązujące problemy biznesu.
I ostatnią rzeczą, której chcę od architekta to programowanie.
3
Czy architekt który projektuje dom a nie potrafi wymurować ściany, nawet położyć równo cegły ma rację bytu?
0
ralf napisał(a):
Czy architekt który projektuje dom a nie potrafi wymurować ściany, nawet położyć równo cegły ma rację bytu?
Nieodpowiedni przykład.
Architekt projektujący dom musi znać takie rzeczy jak np ściany nośne, materiały, ich gęstość wytrzymałośc i pozostałe parametry. więc może i cegieł kłaść nie umie, ale musi wiedzieć co to cegła.
4
Jeżeli to pozycja bardziej managerska (a tak bym to widział - umocowany pod CTO), to powinien umieć, ale nie powinien kodować :) Jego celem jest wtedy budować w firmie dobry DevOps (jakkolwiek to mierzyć), co zrobi lepiej jeśli skupi się na strategii, rekrutacji, strukturach i procesach niż na kodowaniu. Manager „robi” innymi, czyż nie? :)
Co innego taki architekt bliżej zespołu, o mniejszym zakresie odpowiedzialności - może wtedy jakiegoś taska szarpnie, ale prędzej bym widział prace nad jakimś design dociem i review niż klepaniem funkcji w Pythonie.
Czasami śmieszy mnie jak programiści wytykają palcami CTO, że ten od 5 lat nie napisał linijki kodu ^^
0
Czy architekt który projektuje dom a nie potrafi wymurować ściany, nawet położyć równo cegły ma rację bytu?
@ralf: widzę dwa zasadnicze problemy:
- w budownictwie wszystko ma być zrobione po bożemu, bo przepisy i zdrowie ludzkie. W IT czynnik chaosu to sprawa kluczowa: zrobić na tyle dobrze, żeby klient się nie czepiał i wszystko szło sprawnie. Jakby IT było jak inne dziedziny inżynierii to wszyscy pracowalibyśmy jak w NASA
- w budownictwie nie ma czegoś takiego, że książki albo konferencje potrafią mówić najgorszy bullshit tylko po to, żeby się sprzedać. Np.
pokryj wszystko unit testami, twój kod będzie nie do ruszeniaalboużyj wszystkich możliwych usług naszej chmury, będzie szybko i tanio
Według mnie architekt musi umieć kodować, bo o oderwanie z rzeczywistością jest bardzo prosto. Jeśli architekt czyta materiały skierowane typowo pod architektów to nie robi on przysługi zespołowi, tylko firmie, która się reklamuje. Chyba każdy, kto pracował w korpo zna ten przypadek, że firma zakupiła coś całkowicie z d**y i każdy rozgarnięty junior na kilometr potrafi wyniuchać, że coś poszło nie tak
0
Jak ktos nie ogarnia technicznie to nie architekt tylko astronauta (bo tak wysoko odlecial), a wiadomo wysoko jest malo tlenu, umysl nie dziala jak nalezy itp.
Tutaj niestety jak ktos nie posklada POC z klockow ktore chce uzyc, to nie bedzie sobie zdawal sprawy z problemow jakie mozna spotkac po drodze.
0
To co opisujesz brzmi jak szeroko pojęty architect cloud/infrastruktury. Koleś który weźmie system napisany przez deweloperów i dobierze do niego najbardziej optymalne rozwiązanie do hostowania tego itp. Jeśli do tego ogranicza się jego rola, i nie próbuje narzucać Wam jakie wzorce macie stosować, czy macie rozbić system na mikroserwisy czy też nie itp. to w czym problem?
0
Mało jest ludzi ogarniających jednocześnie infrastrukturę jak i programowanie na wysokim poziomie. Wszystko zależy od poziomu na jakim działa, bo może wychodzić z założenia, że "robimy to w mikroserwisach (bo potrzebujemy skalowania), stawiamy na k8s (bo jest gotowa usługa w chmurze), wszystko umieszczamy w jakichś tam VNET 'ach, HA obsługujemy tak, DR inaczej, monitoring realizujemy w taki sposób, alerting w inny. Poukładanie teych wszystkich chmurowych klocków w sensowną układankę to jest jednak sporo wiedzy i pracy. Sam wychodzę z kompletnie odwrotnej pozycji - o programowania coś tam wiem, o chmurze raczej mało i często odczuwam brak tej wiedzy, więc jestem w stanie wyobrazić sobie, że ktoś o odmienny niż mój rozkładzie wiedzy jest w stanie być niezłym architektem. Podstawa, to nie wciskanie się na siłę w sprawy o których nie ma się pojęcia. Gorzej, jeżeli faktycznie miał absolutne zero styku z programowaniem, bo jednak od architekta oczekuje się często podejmowania decyzji, których nikt nie chce podjąć (chwała dla nie biorących udziału), rozsądzania jakichś wewnątrz i zewnątrz zespołowych sporów. Tak samo istotną rolą (chyba najważniejszą) jest umiejętność przełożenia tego co chce biznes na język techniczny, zaproponowanie jakiegoś rozwiązania, a z drugiej storony szybkie wychwycenie, że biznes chce mieć cienką, niebieską linię biegnącą przez punkty nie układające się w linii i "to się jednak nie da" - tutaj bez doświadczenia w programowaniu będzie ciężko. Tak samo ciężko wiedzę teoretyczną o tym czym jest i jak bardzo przeszkadza dług technologiczny przełozyć na praktyke i pewnie skończy się na "hulaj dusza piekła nie ma, ciśniemy ficzery", albo na naiwnym pompowaniu jakichś wybranych wskaźników typu code coverage.
2
DevOps to nie techniczny architekt. Poza tym DevOps który nie programuje to Ops, bo przecież brak "Dev".