Tym razem post po polsku, co niekoniecznie często zdarza się na tym blogu. Skąd ten wyjątek? Będę pisał o swojej pracy, o tym czym zajmuję się na co dzień - podobnych opisów w języku angielskim (stworzonych przez moich kolegów i koleżanki na podobnych stanowiskach) jest pewnie dużo, a mnie zależało na tym, aby podkreślić, że działamy (my, tj. AWS) również w Polsce, i że to o czym będę pisał poniżej można robić nie tylko w Seattle czy Londynie, ale również Warszawie, Krakowie czy Jeleniej Górze.

Hmm, OK, ale właściwie skąd pomysł na opisywanie swojej pracy? Czy to jakiś ekshibicjonistyczny krzyk o atencję? :) Nie, nie planuję kariery technocelbryty, heheh. Powody są dwa, bardzo prozaiczne:

1. po pierwsze - często nawet ludzie z firm współpracujących z AWS nie wiedzą kim jest Solutions Architekt; spodziewają się płatnego konsultanta z brutalnie wysoką stawką godzinową, więc niepotrzebnie stresują się, wyczekując w każdej chwili ataku fakturą ;)
2. po drugie - co tu dużo kryć: cloud publiczny (i AWS w szczególności) jest na etapie bardzo dynamicznego wzrostu, również w Europie Środowo-Wschodniej; oznacza to dużo pracy dla Solutions Architectów, więc szukamy nowych osób, które chciałyby do nas dołaczyć - kluczowe jest więc jasne sprecyzowanie - kim właściwie jest Solution Architect?

Krócej się nie da

AWS Solution Architect to rozszerzenie Twojego zespołu w AWS.

Przyznam, brzmi to trochę "sprzedażowo", ale warto się przyjrzeć temu one-linerowi.

Po pierwsze: jest skierowany ewidentnie do klienta ("Twojego zespołu"), tj. firmy korzystającej (lub planującej korzystać) z AWS. To ważna optyka. Solutions Architect (SA) ma reprezentować interesy klienta - to nie jest rola sprzedażowa, jej celem nie jest "sprzedać" firmie czegokolwiek (nie mam sprzedażowych goali/KPIs), tylko wsparcie klienta w tym, aby osiągnął (jego produkt/platforma/system) sukces.

Po drugie: co to właściwie oznacza - "rozszerzenie zespołu"? SA nie jest konsultantem/ką. Klienci nie płacą za nasz czas/efekty naszej pracy - to dobra wiadomość ("darmo! gratis! free!"), ale oczywiście oznacza to pewien trade-off: to my (AWS SA) decydujemy o tym gdzie i jak bardzo możemy się zaangażować. Ta decyzja nie wynika z osobistych sympatii ani z tego jak dużo pieniędzy dana firma zostawia miesięcznie w Amazonie - musimy ocenić jak bardzo jesteśmy w stanie w danym przypadku ZROBIĆ RÓŻNICĘ, np.:

• dostarczyć wiedzę, której aktualnie klient nie ma (a która bardzo mu pomoże)
• wesprzeć kluczową fazę projektu (od której zależy jego całościowy sukces)
• pomóc zaadresować kluczowy problem/ograniczenie (natury architektonicznej, np. takie które hamuje rozwój platformy)

Po trzecie: trochę można wyczytać z samej nazwy stanowiska - "Solutions Architect".  Tu nie wystarczy być ekspertem od danej grupy serwisów - kluczowa jest praktyczna umiejętność budowania całościowych rozwiązań (dla problemów/okazji biznesowych, które też trzeba dobrze zrozumieć). To jest praca dla tzw. "versatilists", którzy potrafią się poruszać "wszerz" (mają szeroką wiedzę ogólną w wielu wymiarach - np. integracji, bezpieczeństwa, niezawodności, nowoczesnych procesów deweloperskich, itd.) ale i "w głąb" (są w stanie zejść na poziom głębokich szczegółów w kilku wybranych obszarach swojej ekspertyzy).

Strefa(/y) rażenia

OK, poanalizowaliśmy, pofilozofowaliśmy, ale co taki/a SA robi (a czego nie)?

Dla uproszczenia, możemy wydzielić 3 strefy (wymiary?) aktywności SA:

1. praca bezpośrednio z klientami
2. praca z community
3. projekty wewnętrzne (m.in. praca z teamami rozwijającymi konkretne usługi AWS)

Co konkretnie mieści się w ramach każdej z tych kategorii?

1. Praca z klientami

Tu zasada jest jedna - NIE piszemy kodu "produkcyjnego" dla klienta. Przyczyn jest kilka, ale podstawowa jest taka, że to się po prostu "nie skaluje". SA ma być "enablerem", mnożnikiem, katalizatorem - godzina pracy SA powinna przełożyć się na znacznie więcej wartości niż 1h pracy z kodem, nawet najlepszego specjalisty.

Przykłady? Proszę bardzo:

1. Klient ma temat biznesowy (problem do rozwiązania, pomysł na feature) - siadamy razem i brainstormujemy a SA podpowiada np. czy AWS posiada mechanizmy czy usługi, które umożliwią, ułatwią, albo przyspieszą realizację tego pomysłu. Efektem jest plan/prototyp/proof-of-concept a czasem po prostu szkic architektury albo rozpiska opcji.
2. Klient trafił na bolesne ograniczenie natury architektonicznej (np. dot. skalowalności, odporności na awarie, utrzymania) - siadamy razem i wypracowujemy możliwe ścieżki rozwiązania, korzystając m.in. z wiedzy SA na temat usług AWS i ich właściwości. Wynik to plan działania, zpriorytetyzowane pytania do szczegółowego odpowiedzenia, opis architecture spike do zakodowania.
3. Klient wie co chce zbudować, ma też pewien pomysł jakich komponentów użyć, ale brakuje mu wiedzy/doświadczenia w pracy z nimi - SA dostarcza wiedzę i materiały, organizuje odp. warsztaty, pomaga zbudować sensowny plan przedsięwzięcia, umawia sesję train-the-trainers, etc.

Czyli w skrócie: dużo interakcji, brainstormów, pracy przy whiteboardzie i wgłębiania się w kontekst biznesowy bardzo różnych firm-klientów. Oprócz tego cała masa prototypowania, praktycznego demo-wania (prezentacji rozwiązań w akcji) i umiejętnego nawigowania poprzez ocean specjalistycznej, AWS-owej wiedzy.

2. Praca z community

"Community", czyli właściwie kto? Inżynierowie, specjaliści, ludzie zainteresowani nie tylko chmurą, ale budowaniem oprogramowania "in general".

Ktoś mógłby rzec:

"Zaraz, ale nie każdy członek community to klient AWS!"

No cóż, może dziś jeszcze nie. Ale jutro? Kto wie ... Jak ktoś mądry powiedział - dzisiejszy software developer to potencjalny CTO założonego jutro startupu. Zatem rolą SA jest dostarczać wiedzę/inspirację dla community, aby jego członkowie mogli ją ocenić i sami odpowiedzieć sobie na pytanie: czy oraz do czego ta wiedza może im się przydać.

Co więc SA robią dla community? Długo by wyliczać:

• występy na konferencjach i meetupach (AWSowych i innych)
• podcasty, wywiady, inne nagrania
• artykuły, blog posty, whitepapers
• sample, jumpstarty, architektury referencyjne
• szeroko rozumiany professional networking - jeśli znasz kogoś osobiście, to nawet jeśli zamieniliście razem raptem kilka słów, łatwiej później wrócić z pytaniem do takiej osoby, prawda?

3. Projekty wewnętrzne

Tu różnorodność jest chyba największa, a z drugiej strony najtrudniej będzie mi ją opisać.

Po pierwsze, wspieramy wiele innych zespołów w AWS - np. Sprzedaż (Account Managerowie), Marketing (eventy AWS), DevRel (wspólne inicjatywy z Dev Advocates).

Po drugie, jesteśmy łącznikiem pomiędzy klientami a zespołami usługowymi (czyli tymi, które rozwijają i utrzymują konkretne usługi, np. EC2, RDS, czy Lambda): przekazujemy feedback (opinie od klientów), formułujemy feature requests (na podst. obserwowanego zapotrzebowania), testujemy wczesne wersje produktów (o których świat zewnętrzny jeszcze nie wie ...), itp.

Po trzecie, dużo dzieje się w naszym wewnętrznym SA community. Mamy swoje fora wymiany informacji i sposoby na dzielenie się wiedzą. Działamy w mocno wyspecjalizowanych "gildiach" (gdzie trzeba wykazać się wiedzą na wejściu, a potem kontrybuować na rzecz takiej "gildii", np. wspierając innych SA przy skomplikowanych case'ach, wymagających bardzo szczegółowej wiedzy specjalistycznej na dany temat).

Hmm, sporo tego ...

Tak, trudno się nie zgodzić. Ale to NIE jest tak, że każdy robi wszystko :)

SA działają mocno autonomiczni/e (przy czym oczywiście muszą być w ramach tej autonomii mocno transparentni/e) - idea jest taka, aby każdy miał możliwość wykazać się tam (w tych obszarach), gdzie jest w stanie zrobić największą (i potrzebną!) różnicę. Czy to ze względu na umiejętności, predyspozycje, czy po prostu motywację (to kierunek dla niego/jej najbardziej atrakcyjny).

Dlatego jest u nas miejsce dla osób o bardzo różnych profilach:

• takich, którzy ze swoim zaraźliwym entuzjazmem świetnie czują się w wystąpieniach publicznych :)
• builderów, dla których żadne wyzwanie nie straszne i uwielbiają być na pierwszej linii frontu, razem z deweloperami
• twórców contentu, którzy tworzą świetne artykuły, tutoriale i niebanalne warsztaty w ramach obszarów swojej ekspertyzy

Czy to zatem oznacza, że każdy robi tu co chce? Jak się wobec tego odnaleźć w takim chaosie?

Nie, nie, nie :) Czego jak czego, ale chaosu to w Amazonie nie ma :D Solution Architects są dobrze zorganizowani/e i jasno przyporządkowani/e. Nie nazwałbym tego podziałem na zespoły, to raczej wielowymiarowy "mesh", ale taki, w którym można bez problemu się odnaleźć. W uproszczeniu:

1. Każdy/a SA działa w jakimś regionie geograficznym, którym się (współ)opiekuje
2. Każdy/a SA albo działa w jakimś segmencie (typie firm, np.: korporacje, startupy), albo sektorze (np.: gametech, fintech), albo ma jakąś super-wąską specjalizację (którą zajmuje się full-time - np. Machine Learning, Security)
3. Każdy/a SA ma przypisany pewien poziom - wbrew pozorom nie przekłada się to po prostu na seniority w rozumieniu "staż", ale raczej na poziom/rodzaj impaktu, który dany SA jest w stanie wywołać (np. ktoś kto ma success track jako CTO w dużych startupach, ma sporą szansę być postrzegany jako wiarygodny partner do rozmowy przez CTO tego typu firmy)
4. SA należą również do wspomnianych "gildii" (btw. ten mechanizm się u nas inaczej nazywa, ale stwierdziłem, że trochę uproszczę bez utraty czytelności ;>), opiekują się konkretnymi "celami", określają swoje indywidualne (często unikalne) commitmenty - to również kształtuje w dużej mierze ich codzienną pracę

O czym warto powiedzieć wprost

aby uniknąć nieprzyjemnych zaskoczeń ...

Trochę się rozpisałem, ale jest kilka tematów, o których (IMHO) należy powiedzieć wprost i to bardzo jasno:

• SA to NIE jest rola menedżerska. Liderska? Tak. Ale nie menedżerska. Dlaczego natomiast liderska? W tej roli bardzo często cele osiągamy nie bezpośrednio (pamiętacie? żadnych commitów do kodu, który ma wylądować na produkcji), ale rękami innych. Często z innej firmy (ludzie od klienta) oraz nie będących naszymi podwładnymi - to wymaga: dużej wiarygodności zawodowej, charyzmy, umiejętności bardzo precyzyjnego formułowania myśli oraz "sprzedawania" ich (tj. przekonywania do nich innych osób).
• Wszyscy jesteśmy hands-on (inaczej się nie da ...), ale nie zmienia to faktu, że nie jesteśmy klasycznymi "builderami". Koniec końców to jednak kod klienta, platforma klienta, oraz "skin in the game" też klienta. Oczywiście staramy się być jak najbliżej tematu (również aby zebrać swoje "lessons learned") i konsekwencje naszych błędów mogą być bardzo nieprzyjemne, ale to nie do końca to samo. Tę niedoskonałość rekompensujemy m.in.: dużą dynamiką tematów (więcej różnorakich doświadczeń), czasem spędzonym na nauce/eksperymentach ("sharpening the saw") i dużą ilością projektów wewnętrznych (za które bierzemy długofalową odpowiedzialność).
• To rola techniczna, ale nie inżynierska a architektoniczna. Zarówno świetna komunikatywność (po angielsku!) jak i umiejętność wejścia (ze zrozumieniem!) w tematy biznesowo-produktowe jest absolutnie niezbędna.
• Wbrew pozorom, jakieś specjalne obeznanie z AWS nie jest (na wstępie) wymagane. Tak, trzeba mieć praktyczne doświadczenie w projektowaniu systemów Internetowych (nietrywialnych, że tak to ujmę). Tak, trzeba mieć rozeznanie w technologiach chmurowych i architekturach rozproszonych. Ale samego AWSa można nauczyć się już później (po dołączeniu).
• To osobny temat sam w sobie, ale ... kandydat(ka) na AWS musi się dobrze odnaleźć w kulturze Amazonu, która jest - jak my tu mówimy - peculiar. Nie to że najlepsza czy najskuteczniejsza - to już niech sobie każdy sam oceni. Ona jest po prostu super-specyficzna i o ile np. ja się tu świetnie czuję, to znam osoby, które nie wytrzymałyby tu 15 minut ... Hmm, to w sumie chyba dobry temat na osobnego posta ;D

Dlaczego warto?

OK, powoli zmierzamy do brzegu.

Gdybym miał wymienić najlepsze cechy tej pracy, takie dla których faktycznie warto się rolą SA zainteresować, to lista przedstawiałaby się następująco:

1. To jest firma prawdziwie globalna, nie oddziałowa - pracując z Polski masz dokładnie takie same metody dotarcia czy też ograniczenia w dostępie do np. zespołów pracujących nad Twoją ulubioną technologią (o ile ta jest obecna w AWS ;D); no, może jedynie różnica w strefach czasowych działa na Twoją niekorzyść, hehe. Chcesz zobaczyć jak wygląda/działa prawdziwy BigTech - wzorcowy model firmy, która przeskalowała się efektywnie nie stając skostniałą korporacją i nie tracąc swojej kultury? To dobre miejsce.
2. Jak się od kogoś uczyć, to gdzie jak nie tu? Dołączasz do organizacji a potem się okazuje np., że na tym samym stanowisku, ale w ekipie obok jest autor książki technicznej, która zrobiła na Tobie największe wrażenie w zeszłym miesiącu; albo core team member Twojego ulubionego języka programowania; albo ... (itd.)
3. Możliwość tune'owania swojego stanowiska pod swój profil (swoje mocne strony ale i swoje ambicje) - to jest niesamowity boon; oczywiście potem trzeba się obronić, tj. pokazać skuteczność w praktyce, ale to chyba fair deal, prawda?
4. Możliwość obcowania (interaktywnego, włączając zwracanie feedbacku i wpływ na roadmapę produktową) z chmurowym bleeding edge - nie tylko z najnowszymi i najbardziej ekscytującymi serwisami, ale też z tym co jest dopiero opracowywane i szersza publika będzie miała szansę się z tym zapoznać dopiero za jakiś czas. Sebastian lubi to.
5. Bezpośrednią współpracę z mega-ekscytującymi klientami - np. w moim przypadku są to europejskie startupy: trudno o środowisko bardziej kreatywne, dynamiczne czy też ambitniejsze. Praca z nimi jest - jak mawiał Forrest Gump - "jak pudełko czekoladek", nigdy nie wiadomo co dzisiaj wyciągniesz ;D Ale wiadomo, że będzie ciekawie.

Długo bym tak mógł, ale pora kończyć ten wywód.

Nie wiem kiedy to czytasz, ale istnieje niezerowa szansa, że aktualnie kogoś szukamy (w momencie kiedy to piszę, jest otwarty slot na SA dla Startupów w CEE, gorąco polecam!). Więc jeśli ten opis Ci się spodobał, coś Cię w nim zainteresowało, to zachęcam do kontaktu (może być bezpośrednio ze mną - wierzę że dasz radę mnie zlokalizować, niech to będzie Twoje pierwsze wyzwanie ;>). Z chęcią odpowiem na pytania, ba - jeśli będą się powtarzać, to może złożę z tego jakieś F.A.Q. albo nawet osobnego posta.

P.S.

To NIE jest materiał oficjalny AWS, tylko moja osobista perspektywa na rolę SA.
Opinie i opisy są moje i nie muszą odpowiadać oficjalnej terminologii (/stanowisku) Amazonu.
Za artykuł nikt mi nie zapłacił, ani nikt nie zlecił mi jego napisania. Zrobiłem to w czasie wolnym, bo taki naszedł mnie kaprys ;)