Podcast #3 – Wymagania wobec architekta oprogramowania

Cześć z tej strony Michał Szafrański i zapraszam Cię do podcastu Akademii Architekta IT.

Dzisiaj porozmawiamy o wymaganiach wobec architekta oprogramowania. Utarło się, że architektem zostaje się po kilku latach pracy jako starszy programista. Jest to awans, który otrzymuje się automatycznie bez względu na to, czy nam się to podoba, czy nie i zależy tylko od ilości lat przepracowanych na stanowisku starszego programisty lub w danej firmie. Bardzo często nie wiąże się to z żadnymi zmianami w funkcjonowaniu naszej pracy. Programujemy dalej tak, jak programowaliśmy i jest to zmiana tylko naszego tytułu (czasami uposażenia), a nie sposobu naszej pracy.

Wiele firm pracuje obecnie w Scrumie, co również nie ułatwia usytuowania roli architekta gdzieś w strukturze projektu lub zespołu. Jak wiecie w Scrumie mamy trzy role: Scrum Mastera, właściciela produktu i oczywiście członka zespołu. Nigdzie na żadnym szczeblu nie ma wyszczególnienia, że dana osoba jest liderem, czy jest architektem, czy specjalizuje się w jakiejś innym zakresie obowiązków. Te trzy role są obowiązujące w Scrumie. Jak umieścić tego naszego architekta w tej strukturze? Czy on ma być poza zespołem, czy on ma być w zespole, ale zajmować się innymi zadaniami (poza sprintowymi)?

Teoretycznie Scrum mówi, że powinniśmy brać dowolne zadania. Nawet jeśli jesteśmy Front-endowcem, powinniśmy brać zadania bazodanowe tak, żeby zespół wspólnie rozwijał się i posiadał te same kompetencje. Także w Scrumie rola architekta jest trudna do usytuowania i do określenia. Stąd w wielu organizacjach tworzone są specjalne komórki architektów.

Jeśli w zespole jeden z jego członków jest architektem, nie daje mu to pełnej odpowiedzialności za cały system. Nie ma on możliwość wpływania na projekty w sensownym zakresie.

Czym jest architektura oprogramowania?

Żeby jakoś sensownie określić wymagania wobec architekta oprogramowania, powinniśmy na początek powiedzieć, czym w ogóle jest architektura oprogramowania.

Ponieważ istnieje wiele rodzajów architektów, typu architekci korporacyjny, architekci rozwiązań itp. skupimy się dzisiaj na takim typowym architekcie oprogramowania, który wyszedł z roli programisty i zajmuje się projektowaniem programów.

Więc czym jest ta architektura oprogramowania? Czy może to być np. schemat UML systemu, czyli wszystkie powiązania pomiędzy klasami, rozpisane diagramy klas, wyrysowane schematów przepływu danych i inne np. diagramy użycia, czy inne Use Casy?

Byłoby to bardzo duże uproszczenie, ponieważ obecnie większość architektów i większość osób zajmujących się architekturą rzadko kiedy już używa UML-a. Ten stopień skomplikowania dokumentacji poszedł troszeczkę wyżej i nie zajmujemy się już takim stricte UML-owym modelowaniem systemu. (Cześciej diagramy C4 itp.).

Pracujemy teraz metodykami zwinnymi, więc projektowanie odbywa się podczas programowania lub chwilę wcześniej. Możemy stosować metodyki TDD — Test Driven Development, która pozwalają tworzyć klasy bez projektowania ich w UML.

I tutaj docieramy do drugiego pytania. Czy schemat klas to jest nasza architektura oprogramowania? Uznanie, że schemat klas jest naszą architekturą oprogramowania byłoby bardzo strukturalnym podejściem. Nawet wyznaczenie przepływów danych, przepływów pracy tych klas pomiędzy sobą czy zależności. Dalej jest to bardzo sztywna struktura systemu tylko wskazująca budowę systemu, a nie jego działanie. Nawet jeśli weźmiemy opis strukturalny całego systemu, czyli schemat poziom wyżej od naszych klas, na poziomie budowy modułów, komponentów, typu mikrousługi, to dalej jest to opis tylko struktury systemu. A nie działania jego.

Często mówi się, że mamy architekturę oprogramowania trójwarstwową albo architekturę Clean Architecture. To są tylko style architektoniczne, które zastosowaliśmy w naszym systemie. Nie opisują one pełnej architektury oprogramowania.

Żeby tak naprawdę opisać architekturę oprogramowania naszego systemu, potrzebujemy połączyć wszystkie te rzeczy w jedną całość. Czyli musimy mieć określoną strukturę naszego systemu typu: jakie klasy, gdzie występują, jakie mikrousługi, jakie warstwy, gdzie leżą i jaka jest ich odpowiedzialność.

Musimy mieć też określone parametry. Jako parametry rozumiem tutaj określenie np. parametrów architektonicznych dostępności, parametru skalowalności, odporności na błędy, wydajności bezpieczeństwa. Takich parametrów jest kilkanaście i wszystkie je musimy dokładnie mieć określone tak, żeby ta architektura była umieszczona w pewnym kontekście.

Kolejną rzeczą, która jest nam potrzebna do określenia naszej architektury, jest zapisanie decyzji architektonicznych i egzekwowanie ich.
Decyzje architektoniczne mogą odnosić się na przykład do struktury naszego systemu. Na przykład — dlaczego warstwa frontendu nie może łączyć się z warstwą bazodanową? Lub — z warstwy bazodanowej mogą korzystać tylko usługi i tylko one mogą mieć dostęp do tej warstwy bazodanowej.

To są decyzje architektoniczne podejmowane właśnie przez architekta oprogramowania.

Kim powinien być architekt oprogramowania?

Skoro z grubsza określiliśmy, czym jest nasza architektura oprogramowania, czyli strukturą + parametrami systemu + decyzjami architektonicznymi, możemy sobie powiedzieć – kim powinien być nasz architekt. Jakimi cechami powinien wyróżniać się, żeby dobrze spełniać swoją funkcję.

Znawca biznesu

Od każdej osoby tworzącej system informatyczny oczekujemy, że będzie ona posiadała określony poziom wiedzy z zakresu biznesu. Szczególnie to wymaganie dotyka architektów, którzy muszą przełożyć wymagania biznesowe na działającą architekturę. Bez takiej domenowej wiedzy z zakresu danego biznesu nie będą oni rozumieli wyzwań, jakie są przed nimi stawiane i jakie problemy należy rozwiązać.

Ze swego doświadczenia wiem, że nawet najlepszy technicznie specjalista nie będzie dobrym architektem, jeśli nie umie rozmawiać z biznesem. A żeby rozmawiać z biznesem trzeba rozmawiać ich językiem, czyli językiem biznesowym. Jeśli będziemy rozmawiali wspólnym językiem branżowym, to zostanie wytworzona pewna więź pomiędzy biznesem a twórcami oprogramowania, która mocno sprzyja tworzeniu dużych systemów.

Doświadczony wyjadacz

Kolejną rzeczą, jaką wymaga się od architekta, jest bogate i zróżnicowane doświadczenie. Jako architekt powinieneś znać się na wielu różnych technologiach, platformach, bibliotekach i środowiskach. Niekoniecznie musisz być specjalistą we wszystkich. Natomiast twoja wiedza powinna być na tyle przekrojowa, że z łatwością określisz, jaka technologia w danym problemie będzie najbardziej przydatna.

Tak samo wcale nie musisz być specjalistą od programowania frontendu, na przykład Reacta czy Angulara, żeby jasno określić jak ten frontend powinien być zorganizowany od strony komponentów, jak powinien się komunikować z backendem lub z innymi komponentami.
Tak samo nie musisz być specjalistą od implementowania bibliotek. Natomiast powinieneś znać jej wszelkie zalety i wady jej zastosowania. Dużo cenniejszą wiedzą, jest poznanie kilku różnych bibliotek na poziomie przydatności do naszego projektu.

Oczywiście w tej różnorodności nie możemy popadać w skrajność. Od architekta nie oczekuje się, że będzie wiedział wszystko na temat czterech różnych chmur dostawców chmurowych (AWS, GCP, Azure, Ali). Natomiast jeśli pracujemy już z dostawców, typu AWS to warto, żeby zapoznać się ze wszystkimi możliwymi rozwiązaniami (usługami), jakie oferuje nam ta platforma.

Dusza towarzystwa

Kolejną bardzo ważną cechą, jaką powinien mieć architekt, jest zdolność rozmawiania z ludźmi. Nie jest to już wymaganie techniczne. Natomiast jeśli jesteśmy takim architektem, to powinniśmy umieć negocjować z członkami naszego zespołu.

Powinien przede wszystkim posiadać umiejętność pracy w zespole. To architekt nadaje kierunek rozwoju oprogramowania. To architekt o pewnych rzeczach decyduje, także zdolności przywódcze są tutaj wymagane.

Te umiejętności interpersonalne są istotne w skutecznym przekazywaniu decyzji architektonicznych i zasad architektury, jakie będziemy stosowali w systemie.

Nie powinny zdarzać się sytuacje, że architekt coś powie i od razu tego wymaga. Powinien on udzielić pomocy zespołowi. Wyjaśnić, na czym polegała jego decyzja. Co stoi za tą decyzją. Jakie są jej skutki i konsekwencje.

Umiejętności interpersonalne będą się przekładały również na relacje między zespołami, ponieważ praca architekta i jego decyzje wpływają zarówno na kształt pracy zespołu, na kształt tworzonego systemu, ale również na to, jak wytwarzane komponenty będą współdziałać pomiędzy sobą.

Jeśli mamy dwa zespoły, dwóch architektów to tutaj bardzo ważna jest współpraca pomiędzy nimi i takie podjęcie decyzji architektonicznych, żeby ten system działał.

Lew salonowy

Ze swojego doświadczenia wiem, że większość decyzji podejmowanych przez architekta będzie kwestionowana, przez któregoś ze współpracowników lub przez inny zespół. Decyzje architekta wpływają na pracę wielu osób z różnych zespołów.

Musimy je motywować. Tak wyjaśnić czym decyzje są spowodowane, żeby osoby, które je kwestionują miały pewność, że wiemy co robimy. Że wiemy, jaka jest celowość tej decyzji i umotywować ją wystarczająco szczegółowo w celu przekonania osób niezgadzających się z nami.

Co taki architekt w ogóle robi?

W skrócie powiedzieliśmy sobie, jakie cechy powinien mieć nasz architekt oprogramowania. Teraz powiedzmy sobie, co w ogóle taki architekt robi.
Pierwszą rzeczą, jaką często ludzie mają na myśli to architekt, który rysuje jakąś strukturę i jej efektem jego pracy są schematy UML-owe. Jest to duże uproszczenie. Jest to jedna z rzeczy, które architekt może tworzyć. Jest to raczej wynik tego, co robi architekt. Jest to pewna dokumentacja jego pracy.

Podejmuje decyzje architektoniczne.

Po pierwsze architekt podejmuje decyzje architektoniczne, czyli jeśli mamy wybór pomiędzy frameworkiem React a Angulara to decyzją architekta jest właśnie wybór pomiędzy tymi frameworkami.

Oczywiście wybór biblioteki jest jedną z wielu decyzji. Takich decyzji technologicznych możemy podejmować mnóstwo: na temat struktury naszego systemu, które serwisy łączą się z którymi, jaki jest podział zakresu danych obsługiwany przez dany serwis, podziału Bounded Context-ów itd.

Na podstawie ciągłej analizy architektury

Oczywiście podejmowanie decyzji powinno opierać się na pewnych parametrach. I tutaj wchodzimy w drugą rzecz, czyli decyzje architektoniczne podejmujemy na podstawie ciągłej analizy architektury i nasza analiza architektury powinna się opierać na parametrach, które wcześniej sobie założyliśmy.

Dla przykładu takim naszym parametrem może być skalowalność. W tym przypadku ważnym aspektem jest takie podzielenie dostępu do danych, żeby można było wdrożyć kilka instancji serwisów.

Jeśli weźmiemy, na przykład, parametr dostępności to będziemy wiedzieli, że architekt powinien podjąć decyzję, że w chmurze stawiamy nasze instancje w kilku różnych regionach.

Jeśli mówimy o parametrze wydajności, to liczy się rodzaj dostępu do bazy danych.

Wiele aspektów to są właśnie decyzje architektoniczne podjęte na podstawie parametrów architektury. Te parametry architektury powinniśmy ciągle badać i oczywiście mieć określone współczynniki, jakie chcemy, żeby ten parametr spełniał.

Oraz śledzenia najnowszych trendów

Kolejną rzeczą, jaką powinien robić nasz architekt, a jest to dla mnie najprzyjemniejszy aspekt w mojej pracy, to śledzenie najnowszych trendów i zmieniających się mód.

Czyli kilka lat temu mieliśmy architekturę SOA, która była szczytem naszej miodności systemu, teraz mamy mikrousługi. Za chwilę będziemy mieli sztuczną inteligencję przy wdrażaniu komponentów systemu dla DevOps-ów itp.

Takie najnowsze trendy zawsze powinny być śledzone przez architekta. Powinien on z wyprzedzeniem wiedzieć, jakie trendy będą panowały za kilka miesięcy lub za chwilę. Jeśli nasz system utknie na jakimś wyborze, może być naprawdę trudno później dostosować go do zmieniających się wymagań biznesowych lub technologicznych.

Egzekwuje swoje decyzje

Kolejną rzeczą, jaką wykonuje architekt po podjęciu decyzji architektonicznych, jest jej wyegzekwowanie. Należy w jakiś sposób wiedzieć, czy decyzja została zastosowana, czyli że nie są łamane reguły, które zostały określone przez architekta i wspólnie z zespołem wdrożone.

W tym celu warto oczywiście zastosować narzędzia, którym możemy zaimplementować sprawdzenie polityk. Narzędzia będą nam wykrywały na przykład, że z warstwy frontend-owej jakiś moduł odwołuje się bezpośrednio do bazy danych.

Takich narzędzi na rynku jest kilka. Można analizować strukturę systemu SonarQubem i po takiej analizie egzekwować swoje decyzje. Czyli jeśli Sonar wykryje błąd architektoniczny, powinien on być jak najszybciej naprawiony.

Za jakie obszary odpowiada architekt?

Ostatnim elementem określenia wymagań wobec architekta jest stwierdzenie, za jakie obszary odpowiada w ogóle architekt.

Dane

Jako pierwszy obszar odpowiedzialności mogę wymienić dane. Często, jeśli mamy wydzielony zespół bazodanowy to architekt odpowiada za takie sprawy, jak do tych danych będziemy się dostawali. I jakie dane w ogóle będziemy pobierali i używali.

Od strony technicznej może to być określenie czy będziemy używali baz SQL-owych, czy obiektowych. Z jakiej bazy danych i jakiego rodzaju będziemy korzystali. Jakiej firmy będzie to baza danych oraz jakie komponenty będą miały dostęp do tej warstwy bazodanowej lub nawet jak będzie ta warstwa wyglądała.

Druga rzecz to dane, ale z punktu widzenia biznesowego. Czyli do jakiego zakresu danych będziemy mieli dostęp, czy będziemy mieli dostęp do danych klienta, czy tylko danych o operacjach, czyli transakcjach.

Strukturę oprogramowania

Ważnym obszarem odpowiedzialności architekta jest struktura oprogramowania. Zarówno na poziomie struktury klas, jak i struktury całego systemu, typu ułożenie usług, komunikacja komponentów i przepływ danych pomiędzy nimi.

Proces tworzenia oprogramowania

Kolejnym ważnym aspektem jest proces tworzenia oprogramowania.
Aktualnie większość projektów tworzona jest w metodykach zwinnych. Tutaj rolą architekta jest takie dopasowanie architektury, żeby mogła się ciągle zmieniać. Możemy na przykład wykorzystać architekturę ewolucyjne, która ciągle będzie dopasowywana do wymagań biznesowych.

Praktyki tworzenia oprogramowania

Kolejnym ważnym obszarem odpowiedzialności są praktyki tworzenia oprogramowania. Możemy wykorzystać podejście TDD, możemy zastosować Extreme Programming, możemy zastosować wszelkie inne metodologie. W tym przypadku architekt powinien współdziałać z zespołem, żeby projekt był poprawny zarówno pod względem wymagań biznesowych, jak i architektury i podjętych decyzji architektonicznych.

DevOps

No i najnowszym obszarem, jaki został powierzono odpowiedzialności architekta, jest takie zaprojektowanie procesów DevOps, żeby nasz system w łatwy sposób spełniał wymagania zarówno biznesowe, jak i podjętych decyzji architektonicznych oraz był równie łatwo wdrażany na środowiska produkcyjne i szybko naprawiany na produkcji.

Na tym zakończymy nasz krótki opis wymagań wobec architekta oprogramowania. Zapraszam i do usłyszenia.