Tag Archives: architektura

Does great power… vol.3 – Story of my life

Posted in Uncategorized by

O architekturze było już trochę, a potem jeszcze trochę, ale więcej teorii górnolotnych niż życiowych przykładów. Czas więc i na to. Przedstawiam dziś, przefiltrowaną przez architekturę właśnie, historię mojego życia.

Przygodę ze światem IT zaczęłam jakaś chwilę temu i przez to miałam okazję znaleźć się w różnych firmach, zespołach i rolach. Pracowałam zarówno w małej firmie, która dopiero od kilku lat istniała na rynku, jak i w międzynarodowej korporacji. Jak wiadomo, wiąże się to z doświadczeniem różnych środowisk, sposobów na organizację pracy, a co za tym idzie – podejść do architektury.

Mała firma – młodszy programista

Zacząć pracować postanowiłam jeszcze w trakcie studiów. Dziś nie jest to nic nadzwyczajnego, ale taki sposób na życie dopiero się wtedy rodził. Zatrudniłam się w małej firmie i byłam tam może 30. osobą. Na tym etapie rozwoju, tworzyło ją kilka zespołów, z których każdy miał swojego kierownika-guru. Ja byłam Johnem Snow, nie wiedziałam więc nic. Bardzo chciałam uczestniczyć w budowie czegoś, co zobaczy rzeczywisty, płacący klient, ale przede wszystkim moim celem było nauczyć się jak najwięcej.

Decyzje architektoniczne podejmował oczywiście kierownik, co mi małemu żuczkowi  bardzo odpowiadało. Byłam pełna zachwytu dla wiedzy starszych stażem kolegów i do głowy mi nie przyszło, że mogę choćby zaproponować jakieś rozwiązanie. Kończyło się więc na tym, że ktoś coś wymyślał, a ja to wykonywałam. Pełniłam więc rolę nieco bardziej zaawansowanej maszyny do pisania… w Visual Studio.

Off topic: Nie wiem jak dawałam sobie radę z pracą, domem, studiami (tak, tak, był jeszcze drugi kierunek). Chyba bezpiecznie jest powiedzieć, że sobie jej nie dawałam. O ile nabieranie doświadczenia to super motywator, by zacząć jak najwcześniej, to jednak dzisiaj stwierdzam, że nie do końca skóra warta była wyprawki.

Średnia firma – starszy programista

Firma się rozrosła, moje kwalifikacje wzrosły i tak zaczęła się rodzić współpraca między członkami zespołu, wspólne szukanie rozwiązań, proponowanie zmian. Wciąż mieliśmy kierownika, który w wskazywał stronę w którą finalnie szliśmy, ale pojawiły się mniej lub bardziej indywidualne projekty. Było więc miejsce na pewną autonomię.

Zespoły były wzbogacane ludźmi o różnym doświadczeniu, powodowało to trochę tarć, ale najczęściej stanowiło pozytywne zjawisko. Poza jednym czynnikiem – odpowiedzialnością. Niewielu programistów miało podejście, w którym celem był projekt. Każdy raczej pilnował jedynie, czy na jego podwórku wszystko gra.

Architekturą zajmował się nasz kierownik, jako osoba o największym doświadczeniu. Jednak dochodziło mu wiele obowiązków administracyjno-zarządczych. Do mnie i kolegów dość szybko doszła świadomość tego, że architekt to nie stanowisko, lecz rola. Rola, z którą z jednej strony wiąże się duża odpowiedzialność, a z drugiej gruntowna wiedza. Zapragnęłam wtedy zostać architektem (jak już będę duża i mądra) i to właśnie wpisałam w swoim planie 3-letnim.

Średnia firma – architekt

I… udało się. Urosłam, zmądrzałam i marzenia się ziściły. W efekcie razem z kolegą, poprowadziliśmy kilka projektów w roli architektów. Było po prostu cudownie, żyć nie umierać. Codzienny standup, pilnowanie czy wszyscy rozumieją DDD (nie rozumieli), czy szablon projektu się nie rozjeżdża (rozjeżdżał się), czy claimy działają tak jak powinny (nie działały).

Jak coś było nie po naszej myśli robiliśmy minę doświadczonych mędrców i dobrodusznie karciliśmy młody narybek programistów. I jeszcze raz … rysowaliśmy diagramy, przekazywaliśmy linki do przydatnych stron. Wszystko po to by projekt był robiony tak jak my chcemy… eeee tzn. tak jak powinien być robiony.

Dla mnie skończyło się na kompletnym oderwaniu od rzeczywistości. Wydawało mi się, że bardzo dobrze rozumiem projekt, ale straciłam kontakt z kodem i po pewnym czasie techniczne detale były dla mnie zwykłym bełkotem. Wtedy zrozumiałam, że stałam się modelowym architektem z ivory tower.

Korporacja – senior software …. coś tam

Nadszedł czas pokory, nabrałam dystansu do całej sprawy. Przeszłam też do innej firmy, gdzie miałam zamiar budować system i jego architekturę (tym razem) razem z innymi. A przede wszystkim chciałam znów programować, bo zrozumiałam, że bez tego modele są jedynie obrazkami.

Tyle, że… na miejscu już był architekt. I to taki pełną gębą – nie programujący i na dodatek daleko, w kontakcie głównie telefonicznym. Ogólnie bardzo fajny facet, ale niewiele już dla projektu robiący, gdyż to ja docelowo miałam przejąć system. Czułam jakbym zrobiła krok w tył, co samo w sobie nie było jakieś mega straszne. Ot jestem znów doświadczonym programistą, któremu mówi się co ma robić. Jak się postarałam, to miałam nawet własne poletko do zabawy, trochę odpowiedzialności… nie za dużo Uśmiech

Tak się więc trochę kisiłam. Kroplą goryczy przelewającą czarę okazała się dość niskopoziomowa decyzja architektoniczna – wybór ORMa i brak możliwości zakwestionowania tej decyzji. Well… wiem, że tak w korporacjach jest, nie powinnam się była dziwić. Dobrze, że mogłam to zmienić.

Średnia firma – kierownik

I tak… znów zmieniłam pracę. Tym razem zostałam kierownikiem działu. Brzmi dumnie, ale dział był niewielki – 10-osobowy. Teraz, postanowiłam, o architekturze decydować będą ludzie, nie nadworny decydent. Sama zajmę się uprawianiem servant leadership, a w wolnych chwilach, pomogę w programowaniu.

Tylko, że… mój zespół nie za bardzo chciał o czymkolwiek postanawiać. Może chodziło o to, że byli to ludzie niedoświadczeni i taka odpowiedzialność to było dla nich za dużo. A może przyzwyczajeni byli do modelu słuchania i nie spodziewali się, że może istnieć inny. Suma summarum, stwierdzili, że finalne decyzje należą do mnie, bo w końcu jestem szefem i za to mi płacą. Chcąc nie chcąc zostałam Wielkim Architektem.

Startup – developer

Trochę miałam już tego dość, a przede wszystkim szukałam miejsca, gdzie pracuje się inaczej. Nie zrozumcie mnie źle, wiem każda firma ma swoją kulturę organizacyjną. Zdaję sobie sprawę z roli odgórnych decyzji. Wiem też, że nie każdy gotowy jest na przyjęcie odpowiedzialności z całym dobrodziejstwem inwentarza. Mi jednak to co miałam nie do końca wystarczało.

Teraz pracuję w startupie, gdzie widzę diametralną różnicę. Przede wszystkim – nie ma czegoś takiego jak odgórne decyzje dotyczące architektury, a jeśli już o tym mowa, to nie istnieją odgórne decyzje dotyczące kwestii technicznych. Każdą z nich poprzedza dyskusja i to nie tylko w gronie osób to w końcu implementujących, ale również całego zespołu, a nawet osób spoza.

Model jest prosty – jesteś częścią teamu, więc funkcjonujesz na takich samych prawach jak inni. A to wiąże się również z pewnymi obowiązkami. Udział i wkład każdego z nas staje się wymaganiem, a nie jedynie możliwością.

Nie mamy więc architektów, a raczej każdy z nas nim jest. I każdy powinien, bo nie zrezygnowanie z tej roli oznacza często zrzucenie z siebie odpowiedzialności. W zespole każdy z nas architekturę zna, rozumie, buduje wg niej i jest za nią odpowiedzialny.

 

KONIEC!

Does great power… vol.2

Posted in Uncategorized by

Kontynuując i uogólniając nieco motyw architektury, a wchodząc głębiej w temat władzy, chciałam podzielić się przemyśleniami dotyczącymi szeroko pojmowanego zagadnienia podejmowania decyzji. Wątpliwości, również te dotyczące architektury, rozstrzygane są zazwyczaj przez osobę uznawaną za najbardziej kompetentną, eksperta w danej dziedzinie, lub wspólnie na drodze dyskusji w zespole. Architekt będzie więc taką właśnie postacią, wydającą postanowienia na konkretnym polu – architektury Uśmiech

W zależności od tego w jakim trybie się to dzieje, rozróżniane są pewne style podejmowania decyzji obowiązujące w danej firmie, zespole, czy branży. W dalszej części przedstawię jedną z takich klasyfikacji, a następnie spróbuję przyporządkować je do konkretnych rodzajów firm – od korporacji, po startup.

Style podejmowania decyzji

Jeśli pogooglujemy tytuł tego akapitu, ukaże się nam cała lista sposobów dojścia do kompromisów. Istnieje oczywiście wiele podziałów, czy systemów klasyfikacji, ja natomiast chciałam zwrócić uwagę na następujące cztery style:

  • Autorytatywny
  • Autorytatywny z konsultacją
  • Demokratyczny
  • Wspólne podejmowanie decyzji

Wbrew pozorom nie jest to lista od opcji najgorszej po najlepszą, gdyż wszystkie mają rację bytu w konkretnych sytuacjach. Zanim jednak zaczniemy oceniać, dodam parę wyjaśniających słów o każdej.

Autorytatywny

Autorytatywny styl to taki, w którym jedna osoba, która (przynajmniej w teorii) wie wszystko najlepiej, podejmuje ostateczne decyzje. Może to być ktoś najbardziej doświadczony, naturalnie wyłoniony lider, lub po prostu szef zespołu, firmy, czy projektu.

Niekoniecznie jest nim jakiś trzęsący wszystkim Krzysztof Jarzyna ze Szczecina, ale zwyczajnie ktoś wyznaczony do nadawania sprawom kierunku, od kogo oczekuje się wiedzy, odpowiedzialności, i kto dostaje za efekty swoich wyborów odpowiednią gratyfikację finansową lub ochrzanową. Sytuacja taka jest częsta, gdy na zespól składają się niedoświadczone młokosy, które albo zostały postawione w roli słuchaczy spijających mądrości z ust guru, albo nawet same oczekują, że ktoś nimi pokieruje i powie jak sprawy mają być robione właściwie.

Autorytatywny z konsultacją

Sposób podobny do poprzedniego  – nadal mamy tu jedną osobę, ale za to na tyle dojrzałą, by uznawała również zdanie innych. Konsultacje konsultacjami, ale wciąż jest pewnego rodzaju szef, który automatycznie staje się autorem i bierze odpowiedzialność za to co wyprodukował zespół.

Wszyscy wiemy, że sytuacja taka przyjmuje różne formy – od tego, że zasięganie rad jest udawane, po jedynie podpis pod wysiłkami teamu. Opcja najlepsza to oczywiście coś pośrodku. Choć wątpliwości budzi sprawa, gdy za zasługi nagrodę dostaje decydent, to jednak wiele zespołów taki system akceptuje ze względu na kary w razie braku sukcesów.

Wydaje mi się, że jest to najczęściej funkcjonujący model w firmach. W końcu to właśnie kierownikowi czy ekspertowi płaci się za podejmowanie decyzji i to on powinien ponosić ich konsekwencje. Styl ten to parafraza zdania, które często słyszę gdy rozmawiam o kierowaniu zespołem: “Jasne, że trzeba dyskutować, ale w końcu ktoś MUSI podjąć decyzję!”. Członkowie zespołu często zresztą godzą się na taki układ, lub jeśli nie – startują w szranki o odpowiedni stołek. Po co? Otóż po to, by samemu stanąć w roli autorytetu. Styl ten występuje więc, gdy zespól jest dojrzalszy, składa się z osób o pewnym już doświadczeniu i wiedzy, ale z funkcjonującym szefem-decydentem.

Demokracja

Demokracja jak to demokracja – polega na tym, że wygrywa decyzja większości, i niestety, gdyż to ma do siebie ten system, powoduje niejednokrotnie niezadowolenie tej części, która ma inne zdanie. Osobiście nie spotkałam się z czystą implementacją takiego typu dyskusji – zazwyczaj oczywiście brane jest pod uwagę to co mówi głos ludu, ale decyzja podejmowana jest znów przez konkretną, specjalnie do tego wyznaczoną osobę. Nie widziałam i nie brałam udziału w wymianie zdań, która miała w swoich zasadach zapis: “teraz robimy głosowanie, potem zliczamy karteczki, a gdy się rozejdziemy, to robimy tak jak zagłosowała większość, tzn. przynajmniej 50% + jeden głos”.

W mojej skromnej opinii ta opcja jest najgorsza ze wszystkich czterech. Zazwyczaj jeśli decyzję podejmuje jakiś, nawet nielubiany, szef, to ludzie to łatwiej ją przyjmują niż wynik głosowania. Mówiąc ludzie mam tu na myśli członków opozycji. Pewnie dzieje się tak z tego względu na fakt, iż glosowanie wprowadza na pewnym poziomie tajność. Decyzja traci jedną twarz, pojawia się za to interfejs grupy. Trudniej jest kogoś winić i z kimś się spierać.

Wspólne podejmowanie decyzji

Brzmi jak utopia, co? No cóż… pewnie dla niektórych nią jest. Ja miałam niewątpliwą przyjemność uczestniczyć w takich właśnie polemikach. Model w skrócie polega na tym, że zespół dyskutuje, przekonuje, dyskutuje, przekonuje, a na końcu wspólnie się na coś zgadza.

Wygląda pięknie, ale jest dość trudne we wdrożeniu, i to z kilku względów. Po pierwsze, gdy wchodzimy na tematy “wiary”, których w świecie IT jest całe mnóstwo, może być ciężko zatrzymać rozhulane w kłótni towarzystwo. No i kto niby ma to zrobić? Uśmiech. Po drugie, jeśli mamy bandę indywidualistów, o których również u nas nietrudno, to każdy będzie miał tendencję do ciągnięcia w swoją stronę. Po trzecie jeśli członkowie grupy nie do końca czują, że to na co się zdecydują, ma być dobre nie dla nich z osobna lecz dla projektu, jego celu lub zespołu jako całości, rozmowa może dotyczyć prywatnych interesów.

Jednak gra jest warta świeczki – produkt w postaci decyzji zespołu, gdzie każdy z osobna rozumie ją w pełni i wie dlaczego jest taka a nie inna, to filar, na którym można zbudować dosłownie wszystko. Zabrzmi jak banał, ale nie ma lepszego sposobu na zbudowanie motywacji w człowieku niż zaangażowanie go w realizację, zaczynając oczywiście od jego wpływu na decyzje. Do tego jednak potrzebny jest wysoki poziom świadomości i rozwoju członków zespołu. Każdy powinien zdawać sobie sprawę z tego, że jego zdanie nie tylko jest ważne, ale wręcz niezbędne. W takiej ekipie potakiwacze i bierni słuchacze funkcjonować mogą, ale marnują daną im okazję na dołożenie swojego klocuszka w procesie.

Decyzje w firmach

Można pomyśleć, że jedynym słusznym modelem jest wspólne podejmowanie decyzji, autorytaryzm nie ma w ogóle racji bytu, a demokracja jest ewentualnie dopuszczalna. Otóż… (tu użyję mojego najmniej ulubionego sformułowania) TO ZALEŻY Uśmiech Na przykład zestawiając różne firmy pod względem wielkości czy struktury, można zaobserwować zależności dotyczące styli podejmowania decyzji.

Korporacja

Jeśli miałabym opowiedzieć się za jednym stylem, to stwierdziłabym, że w korporacjach dominują decyzje autorytatywne. Choć firmy te same często twierdzą, że w proces wplatana jest konsultacja, czy to z członkami zespołu, czy z ekspertami dziedzinowymi, to jednak śmiem twierdzić, że udaje się to jedynie czasami. A dokładnie wtedy, gdy sprawa nie dotyczy kwestii na tyle ważnych, by góra musiała się nimi trudzić. W takim wypadku pozwala się je rozstrzygać na niższych poziomach.

Mała rodzinna firma

Wydawałoby się, że nie ma nic bardziej różnego od korporacji, niż mała rodzinna firma. A jednak … jeśli jest w niej jeden Wielki Informatyk (jak Wielki Elektronik z Pana Kleksa) pod postacią CTO, nadwornego architekta, czy nawet CEO, to decyzje podejmuje właśnie on. Jeśli firmę tworzą specjaliści o porównywalnych umiejętnościach i doświadczeniu to jest szansa na większy głos tych ludzi.

Średnia firma

Jeśli mała firma się rozwinie, to staje się czasami średnią. Wraz ze wzrostem liczby osób, pojawia się jakaś struktura, czasami nawet kilkupoziomowa. Decyzje podejmowane są przez szefa konkretnej jednostki. Firmowe – przez prezesa, czy zarząd, przez co są zazwyczaj autorytatywne, natomiast działowe/zespołowe – przez kierownika/dyrektora. To, czy te ostatnie włączają konsultacje, w dużej mierze zależy od tych konkretnych managerów. Pojawia się teraz moment na wrzucenie do zarządzania opcji demokracji lub nawet wspólnego podejmowania decyzji.

Startup

Startup w pewnym sensie przypomina małą firmę, lecz rozdzieliłam je z premedytacją. Chciałam podkreślić, że tutaj nacisk położony jest na innowację i rozwój, a co za tym idzie istnieje większe przyzwolenie na swobodę. Dzięki temu powstaje sporo miejsca na demokrację, czy nawet na autonomiczne wypracowanie rozwiązań w zespole. Choć początkowo przypomina to chaos, i można mieć wrażenie, że żadne decyzje nie są podejmowane, to w skutecznych startupach jest to jedynie faza wypracowująca zespoły wysokiej skuteczności.

Powyższe prawdy to oczywiście uogólnienia (których z reguły nie cierpię), sformułowane jedynie na podstawie mojego doświadczenia (i doświadczeń innych ludzi, których znam). Z pewnością są korporacje, gdzie zdarza się fajna polityka lub szef, który bierze zdanie zespołu pod uwagę, a nawet pozwala na ich własne decyzje. Pewnie są mniejsze firmy, które gdy dochodzi do rozstrzygania sporów, zachowują się bardziej formalnie niż niejedna korporacja.

Temat będę kontynuować… W kolejnym odcinku opowiem historię życia w ujęciu architektoniczno-decyzyjnym.

Does great power come with great responsibility? vol. 1

Posted in Uncategorized by

… parafrazując słowa Bena Parkera, wujka Spidermana (wiem, że dla niektórych to żenada tego nie wiedzieć, lecz mimo to wyjaśniam)…

Temat wyszedł z moich refleksji o architekturze oprogramowania, więc postanowiłam zrobić z niego prezentację, którą przedstawiłam po raz pierwszy w Białymstoku na grupie .Net. Wiele wątków, które tu umieszczę pochodzi od słuchaczy, post będzie więc kumulacją naszych wspólnych przemyśleń.

O co więc chodzi z tą władzą i odpowiedzialnością? Zacznę od tego, że każdy z nasz developerów chce lub kiedyś chciał zostać architektem (ew. managerem, ale nie o tym odłamie programistów chcę teraz pisać). Jeśli nigdy nie chciałeś i nie chcesz, to podejrzewam, że jesteś na początku swej drogi i wizja ciebie jako architekta jawi ci się jako cos jeszcze zbyt nieosiągalnego.

Otóż jest taki moment w życiu programisty, w którym ktoś obdarza nas i nasze kompetencje zaufaniem. Powierza nam odpowiedzialność w postaci decyzji architektonicznej. Możemy mieć wpływ na kształt projektu, być może tylko na wybór frameworka, a jednak w efekcie uderza nad woda sodowa do głowy. Teraz, myślimy, pokażemy wszystkim jak to się robi dobrze…

Architektura?

Ale zanim o rządach, to może słów kilka o tym, czym właściwie jest architektura. Jak się pogógla, to znajdziemy tysiąc definicji i perspektyw na zjawisko. Dla jednych to fizyczne komponenty systemu – serwery, szyny, chmury, dla innych podział systemu na warstwy, dla jeszcze innych pewne niefunkcjonalne wymagania, jak bezpieczeństwo czy niezawodność.

Z jedną rzeczą wszystkie te strony zazwyczaj się zgadzają – architektura, niezależnie od obecności pilnującej jej osoby – zawsze jest. Na domiar złego, to że nie jest nadzorowana, może doprowadzić do kłopotów. Makaronowy kod to najmniejsza z konsekwencji. Architektura dotyczy takich zagadnień jak niezawodność, bezpieczeństwo czy skalowalność. Polega na nadaniu kierunku implementacji systemu i komunikowaniu tego kierunku wszystkim osobom zaangażowanym w realizację. Architektura to fundamenty, wysokopoziomowe, trudne do zmiany w późniejszych etapach decyzje. Albo … jak podsunął mi jeden ze słuchaczy z Białegostoku: decyzje, które pozwolą reszcie zespołu na łatwiejsze rozwiązywanie problemów w przyszłości.

Po co?

Po co w ogóle zajmować się architekturą? Ano po to, by popatrzeć się na system pod kilkoma kątami. A w każdym z nich chodzi o jakość. Tylko cóż to jest ta jakość? Pominę tym razem internety i powiem nieco asekurancko – to zależy. Zależy m. in. od tego, kto tej jakości wymaga. Jeśli pod uwagę weźmiemy projekt systemu, ważne okażą się takie cechy jak integralność, reużywalność i utrzymywalność. Rozważając działanie trzeba pomyśleć o dostępności, wydajności, niezawodności, skalowalności czy bezpieczeństwie. Wdrożeniowców z pewnością zaciekawi łatwość serwisowania, czy testowalność. Dla użytkowników jakość to przede wszystkim użyteczność systemu, szeroko rozumiane UX.

O czym należy pamiętać budując architekturę? Przede wszystkim o tym, że nie jest ona tworzona raz, tak jak i całe oprogramowanie. Musi być zmieniana i musi być tak budowana by zmiany w łatwy sposób umożliwiać. Po drugie należy się skupić zarówno na modelach (które są uproszczeniem rzeczywistości) jak i kodzie (by w tych chmurach nie pozostać). Po trzecie należy wszystkie te decyzje komunikować, bo model, nawet najlepszy, jeśli nie zostanie przekazany, to nie zostanie użyty. Po czwarte i ostatnie, projekt powinien koncentrować się na kluczowych decyzjach, nie da się zamodelować wszystkiego, bo wtedy model przestaje być modelem, a staje się implementacją.

Jak się ocenia architekturę?

Jest kilka metod tzw. formalnych, które pozwalają na ocenę tego, czy nasz architekt dobrze wykonał swoją robotę. Takie metody jak ATAM, SAAM czy ARID polegają z grubsza na analizie scenariuszy. Pierwszą rzeczą jaką należy zrobić jest stworzenie tych scenariuszy i nadanie im wag/punktów/priorytetów. Ten etap sam w sobie jest wartościowy dla projektu, gdyż efektem są wymagania systemu.

W SAAM oceniane jest to, czy scenariusz jest możliwy do zaimplementowania w danej architekturze systemu bez wysiłku. Jeśli tak nie jest, to pytanie brzmi ile komponentów należy zmienić by to osiągnąć i jak trudne to będzie. ATAM bazuje na atrybutach powiązanych z danym scenariuszem. Rozważa się takie aspekty jak wydajność, czy bezpieczeństwo i określa się tzw. sensibility points, czyli punkty istotne z punktu widzenia tych aspektów. ARID z grubsza polega na zabawie jak za pomocą danej architektury zrealizować dany scenariusz i czy jest on w ogóle wykonalny.

Z mojego doświadczenia wynika jednak, iż architektura oceniana jest głównie “na oko” i na dodatek subiektywnie. Istnieje zbiór dobrych praktyk, które gdy się je stosuje, pozwalają nam, z w miarę wysokim prawdopodobieństwem, założyć, że architektura powstałej aplikacji jest dobra. Niekoniecznie trzeba podążać sformalizowanym procesem, żeby to zauważyć. Najważniejsze zwykle jest zdanie interesariuszy projektu, którym jest każdy kto ma jakikolwiek związek z budowaną aplikacją – klient, PM, developer, architekt, tester, gość od platformy systemowej czy deploymentu, oficer bezpieczeństwa. Każdy z nich ma swoją perspektywę i swoje priorytety. Architektura jest dobra jeśli żadnego z nich nie uwiera.

Rola architekta

Małymi kroczkami doszliśmy do naszego architekta. Osoby, która analizuje, projektuje i decyduje. Od której oczekuje się, że pokaże kierunek implementacji i przypilnuje, by był on utrzymywany. Aby jego działania były skuteczne, architekt powinien być elastyczny i komunikatywny. Do jego obowiązków należy weryfikowanie i ocenianie implementacji pod kątem realizacji architektury, a także rozwiązywanie pojawiających się w związku z nią problemów. Dodatkowo dochodzi tu kwestia planowania przyszłych kroków implementacji i zarządzania ryzykiem.

Aby wszystkie te działania miały miejsce, a przede wszystkim by zostały zaakceptowane przez zespół, na architekta wybiera się zazwyczaj osobę z dużym doświadczeniem i wiedzą. No i stąd ta kwestia władzy – jeśli mianujemy kogoś architektem, od razu stawiamy go na piedestale. Dając mu w ręce tyle odpowiedzialności, naturalnym odruchem jest myślenie, że wiąże się z tym decyzyjność.

Z premedytacją użyłam słowa rola, a nie stanowisko. Myśl/i rozwinę w przyszłych postach, w różnych ujęciach takich jak style podejmowania decyzji, dojrzałość zespołu, czy moje własne doświadczenia związane z architektami.

Białystok .Net i Basia

Posted in Uncategorized by

Kolejny tydzień, więc czas na opis kolejnego zeszłorocznego wystąpienia. Również wschód, ale bardziej na północy. No i tym razem bardziej technicznie, bo w tematyce około .Netowej.

4 grudnia, notabene, w dniu moich imienin, wystąpiłam w Białymstoku na spotkaniu tamtejszej Grupy .Net. Ponieważ z Krakowa daleka jest droga do stolicy Podlasia, podróż zajęła mi jakieś 2 dni. Nie narzekam jednak, bo ostatnio okazało się, że bardzo lubię podróżować, zwłaszcza pociągami, gdzie mam czas spokojnie pomyśleć i popracować, tylko internetu czasem brak (tak, wiem wiem, muszę zmienić operatora Uśmiech). Obecny post także w tym środku transportu powstaje.

Oprócz mnie prezentację miał mieć także Leszek Kwaśniewski, lider warszawskiej grupy SQL Server, do niedawna trener i specjalista od baz danych. Spotkaliśmy się wtedy w pociągu w Warszawie, gdzie dość gładko wprowadził mnie w tajniki SQL Server 2014, a jednocześnie części treści swojego wystąpienia. I dobrze, bo jestem tuman jeśli chodzi o bazy danych i być może właśnie dzięki tym korkom zrozumiałam, o czym później mówił.

Dojechaliśmy na miejsce, z dworca odebrał nas Marcin Iwanowski, szef Białostockiej grupy .Net. Gdy już znaleźliśmy się w sali, gdzie miało odbyć się spotkanie, byłam pełna obaw, czy te kilka osób, które tam zastaliśmy, to całe audytorium. Na szczęście okazało się, że jestem jak zwykle panikarą. Punktualnie o godzinie zero, sala była pełna ludzi, a kolejni napływali.

Nie do końca rozumiałam dobór tematyki około sqlowej, jeśli chodzi o grupę developerów, ale powstrzymałam się od uwag. Stwierdziłam, że przecież to może być jedynie moje zdanie. No i oczywiście potem okazało się, że na widowni oprócz programistów byli także administratorzy. Leszek zrobił, nazwane przez niego twardym, wprowadzenie, abym ja mogła wejść później, znów jego nomenklatura, bardziej na miękko. Opowiadał o ficzerach nowego (lub o ile dobrze pamiętam jeszcze wtedy przyszłościowego) Sql Server 2014. Było coś o indeksach kolumnowych, cenach i…? Hmm… Najważniejsze, że wtedy rozumiałam Uśmiech

Potem przyszła kolej na mnie. Temat by mniej techniczny, gdyż opowiadałam o architekturze. O moim jej rozumieniu kiedyś i obecnie. O swoich doświadczeniach i marzeniach by architektem zostać. Ponieważ przez 10 lat pracowałam w kilku firmach i wieeeeelu zespołach, miałam okazję spojrzeć na te kwestie z różnych punktów widzenia. Po pierwsze, chciałam je więc przedstawić, ale po drugie i najważniejsze, dowiedzieć się, co na ten temat myślą inni.

Grupa, choć na początku obawiałam się, że nierozruszana, okazała się bardzo responsywna. Albo temat, albo moje kontrowersyjne tezy, wywołały bardzo ciekawą dyskusję, która ciągnęła się nawet po zakończeniu prezentacji, już przy piwie i kanapkach. Dostałam nawet feedback, że dawno tak nikt ich nie zaktywizował. No i najlepsze – pamiętali o moich imieninach <3. Dostałam nawet prezent Uśmiech.

Afterparty  było dość grzeczne i skutecznie trzymało się tematów branżowych. Nie żebym była zaskoczona, skoro odbywało się w pokoju obok Uśmiech. Omawialiśmy oprócz architektury, o kwestiach związanych z zawodem programisty, edukacją w IT oraz kolejnymi wystąpieniami. Nadszedł jednak czas, kiedy ja i moi gospodarze zdecydowaliśmy się wyjść, głównie po to, by zdążyć posilić się czymś smaczniejszym niż kanapki i mocniejszym niż piwo.

Joanna i Procent zabrali mnie do jakiejś knajpy (było ciemno i daleko od domu, więc nawet po groźbą rozstrzelania, nie trafiłabym tam po raz drugi), w której zjedliśmy pyszne podpłomyki, wypiliśmy śliwkowe piwo przerywane wściekłymi psami i porozmawialiśmy na wiele interesujących tematów. Wieczór był długi i ciągnął się jeszcze w zaciszu domowym, a rano uwieńczony został dodatkowo leniwym śniadaniem “na mieście” Uśmiech, po którym szczęśliwie wróciłam do domu. Procentom dziękuję za super gościnę!