Czy w twoim zespole istnieje osoba na stanowisku Software Architect? Być może architekturą zajmuje się developer z największym doświadczeniem? Czy większość decyzji podejmowana jest w losowym gronie developerów gdzie każdy zgłasza swój pomysł i wspólnie podejmuje się decyzje? A może masz do czynienia ze zjawiskiem Hype Driven Development, w którym koncept zmienia się co wypad na konferencję? A co, jeśli aplikacja, która miała być łatwa w utrzymaniu znowu zaczyna przypominać monolit? Przy odrobinie szczęścia przychodzi czas, kiedy ktoś odważny stwierdza, że czas zakopać tę „kupę” Legacy Code i napisać wszystko od nowa…
Prawdopodobnie tak wygląda praca w większości firm w których nie ma osoby związanej z architekturą, a produkt rozwijany jest prze lata.
Kim jest Architekt?
Architekt to osoba, która posiada największą wiedzę ze wszystkich developerów w teamie, ma wyrobione zdanie, które może poprzeć doświadczeniem, zdobytym podczas pracy przy innych projektach. Osoba ta ma wiedzę z zakresu bezpieczeństwa, wydajności, wzorców architektonicznych, wzorców projektowych, o domenie biznesowej.
Przy każdym wyborze technologii, implementacji nowego podejścia, ustalaniu zasad i reguł programowania w zespole, ostatnie zdanie należy właśnie do niego. Dobry architekt to osoba z autorytetem, wysoko rozwiniętymi umiejętnościami miękkimi, więc typowy nerd-programista nie spełni się na tym stanowisku, ponieważ nie ma wszystkich cech, jakie powinien posiadać architekt. Ma być osobą autorytarną, która posiada szacunek i zaufanie wśród ludzi z biznesu oraz, oczywiście, deweloperów.
Architekt, jako osoba o najwyższym wpływie na architekturę, powinna mieć możliwość osobistego decydowania o kierunku rozwoju kodu. Często może się nam wydać, że wspólne głosowanie może być lepszym rozwiązaniem, jednak architekt posiada zupełnie inny konspekt i punkt widzenia danego problemu. Może patrzeć na problem w perspektywie 2 lat, a nie np 5 miesięcy jak developerzy. Możliwe, że początkowe utrudnienie i zwolnienie w prędkości developowania aplikacji przyniesie sporo korzyści za rok-dwa, gdy cała platforma zostanie rozdzielona na np. mikroserwisy, czego developerzy mogą nie brać w ogóle pod uwagę.
To dzięki dobrym architektom powstają aplikacje, które podczas planowania i końcowego stadium rozwoju projektu dalej zachowują swoją strukturę, nie posiadają Legacy Code, a kod dalej jest tak samo dobrze utrzymywalny jak na początku projektu.
Mogłoby się wydawać, że to ogrom obowiązków i odpowiedzialności spoczywającej na jednej osobie, jednak to nie wszystkie jego obowiązki -architekt powinien też posiadać wiedzę z zakresu domeny biznesowej na minimum podstawowym poziomie, powinien poznać na czym polega logika biznesowa danej aplikacji. Tylko dzięki temu będzie potrafił idealnie dobrać narzędzia do danego problem, nie będzie starał się zaimplementować Domain Driven Design, CQRS czy Event Sourcingu w aplikacji, która powinna być CRUDem. W tym miejscu przydadzą się także umiejętności miękkie, które będzie mógł wykorzystać podczas rozmów z np. Ekspertem Domenowym, który posiada kluczową wiedzę podczas projektowania.
Kim nie jest Architekt?
Było już o tym kim jest architekt, teraz czas na to kim nie jest – zdecydowanie nie jest to osoba która będzie lawinowo klepała kod i generowała nowe klasy jak developer. Nie będzie także skupiać się na błahych problemach, a dzielić się, swoją wiedzą i pomagać biznesowi lepiej radzić sobie z problemami stawianymi przed systemem w realnym życiu.
Dlaczego musi być to dedykowana osoba od architektury?
Nie da się wydzielić dodatkowej odpowiedzialności na zwykłym developerze z dużym doświadczeniem, aby zachowując swoje obecne obowiązki przyjął także zakres prac architekta. Jak zauważyliśmy wyżej, zakres pracy architekta jest ogromny, przez co wprowadzenie ich dla zwykłego developera nic nie da, ponieważ nie będzie miał wystarczającej ilości czasu na swoje obowiązki. Dodatkowo często bywa tak, że Architekt mniej czasu poświęca na programowanie, co może być powodem wielu nieporozumień. Często słyszy się historie byłych architektów, którzy na początku byli bardzo zadowoleni z awansu, większej pensji i nowych wyzwań, jednak często po jakimś czasie dochodzili do wniosku, że to nie dla nich, bo za mało programują, ba często dłuższy kontakt z kodem posiadali tylko w domu, kiedy próbowali rozwijać swoje projekty.
Czy architekt może pracować tylko w firmach posiadających własny produkt, który będzie rozwijany przez wiele lat?
Zdecydowanie nie – dobry architekt będzie w stanie wykazać się także przy produktach, w których tworzy się MVP i sprawdza się prawidłowość pomysłu na aplikację. W takich przypadkach często nie będzie stosowana od samego początku rozbudowana architektura, jednak dzięki sporej wiedzy kluczowe miejsca będą zbudowane generycznie z możliwością poźniejszego rozszerzenia funkcjonalności. Dodatkowo przy zastosowaniu odpowiedniej architektury można uniknąć problemów z jakimi borykał się swego czasu Twitter z trudnościami w skalowalności, przy większej ilości użytkowników.
To dlaczego większość firm nie posiada architekta?
Przyczyn takiego stanu jest kilka – od fundamentalnych, takich, jak ograniczony budżet na projekty. Dobrze wiemy, że świat startupów posiada dość mocno ograniczone finanse i oszczędności szuka się na każdym kroku. Ludzie z biznesu nie znają się na pisaniu kodu, nie rozumieją jak można coś źle zrobić pomimo, że pół roku temu implementacja czegoś nowego zajęła tydzień, a obecnie dwa miesiące, pomimo awansu developerów, ale posiadają wiedzę i umiejętności, których nie mają programiści. Z tego powodu programiści współpracujący z różnymi firmami często powinni wychodzić z inicjatywą jak można usprawnić proces. Kolejny powód to krótkowzroczność w projektach, która często wynika ze wspomnianych wyżej powodów finansowych. Brak szczegółowych planów co do aplikacji i tego, gdzie projekt ma dążyć utrudnia pracę programistom. Inaczej projektuje się prototyp do sprawdzenia prawidłowości założenia, a inaczej implementuje się zbadane założenia w gotowy produkt.
Co zrobić, żeby żyło nam się lepiej?
Przekonanie biznesu do zatrudnienia architekta często nie jest łatwe. Jeśli w kodzie jest sporo problemów, z którymi zespół nie potrafi sobie poradzić, legacy code jest na wysokim poziomie, a jakość kodu pomimo, sprintów refaktoryzujących nie przynosi żadnej wymiernej korzyści, jest to dobry moment, żeby do zespołu dodać architekta, który zaprojektuje architekturę systemu szytą pod dany biznes. Często próby przepisywania projektu bez wcześniejszego przemyślenia i zaprojektowania, kończą się tym samym co obecny projekt. Dlatego też biznes nie zawsze wierzy we wszystkie zapewnienia developerów, ponieważ obiecywali super system z szybką możliwością rozwoju, a po dwóch latach znowu narzekają, że jest słabo napisany, finalnie uznając, że to jest stan normalny i każdy projekt jest w opinii developerów słabo napisany. Nie od dziś znamy poniższe stwierdzenie:
