Droga Architekta IT – Kuchnia

Maciej Lelusz
2. września 2021
Reading time: 9 min
Droga Architekta IT – Kuchnia

Poprzedni artykuł dotyczył wizji na ścieżce architekta IT. Tego jak zebrać informacje i skrystalizować sobie obraz projektu. Godząc z jednej strony wymagania klienta z możliwościami technologii lub wybranego rozwiązania. Papier przyjmie wszystko, tylko i nietrudno się odkleić od rzeczywistości projektując rzeczy niestworzone. Wizja, tak jak wspominałem jest kluczem… który dopiero otwiera drzwi do pracowni.

https://evoila.com/blog/droga-architekta-it-wizja/

Każdy zawód ma swoją, tak zwaną kuchnię lub, jak kto woli, warsztat. Praca architekta IT kojarzy się z pełną dowolnością – telco z kafejki na rogu, rysowanie w samolocie czy w metrze. To trochę mit, marketingowa rama, na której opierane jest wyobrażenie tego zawodu. Zdarzają się oczywiście momenty, kiedy to prawda, jednak, aby zrobić naprawdę duży, trudny projekt potrzeba niezwykłego skupienia. Można to osiągnąć poprzez całkowite odcięcie się od impulsów z zewnątrz. Nie mówię tutaj, aby od razu wykopywać dziurę w ziemi, okleić ją ekskrementami i odpalić pęk kadzideł z drzewa sandałowego. Wystarczy znany kąt, najlepiej kawałek oddzielnego pokoju, gdzie nie rozprasza nas nic „nowego”.

Należy, mimo zrozumiałego wewnętrznego oporu, wyłączyć powiadomienia o nowych zdjęciach kotów lub o właśnie rozpoczętych bataliach politycznych na portalach social media. Wyciszyć komórkę, zamówić jedzenie.

Należy stworzyć sobie atmosferę, która pozwoli naszemu, drugiemu najbardziej pofalowanemu (po brzuchu podczas siedzenia) organowi – mózgowi – na swobodne płynięcie poprzez morze informacji zebranych podczas etapu tworzenia wizji.

  • Zatem: pomieszczenie w biurze, może w domu.

Czym jednak jest pracownia bez narzędzi.

Jedni mówią, że można tworzyć na byle czym, że prawdziwy talent nie jest ograniczonym instrumentem, na którym się tworzy. Może i jest w tym trochę prawdy, ale ja zakładam, że lepiej jest się nie frustrować, a co za tym idzie, nie rozpraszać się niczym, a w szczególności elementami martwymi… których złośliwość, w szczególności w momencie, gdy najbardziej ich potrzebujemy, jest niepojęta.

Dobór narzędzi to bardzo indywidualne sprawa.

Trochę przypomina to kwestię ubrań – jeden lubi szykowne, dobrze skrojone garnitury, inny najlepiej czuje się w dresach. Obie drogi są odpowiednie o ile uzyskuje się zakładany cel i nie tworzy przeszkód w jego osiągnięciu. Stąd wydaje mi się, że w zalewie aplikacji do realizacji różnych zdań, każdy znajdzie coś dla siebie. Rozpoczynając przygodę z architekturą, wiele narzędzi zostanie Wam narzucone przez projekt i nie ma co z tym walczyć. Tak ma być – klient jest przyzwyczajony do czegoś i prawdopodobnie będzie bardzo trudno go przekonać do czegoś innego. Należy pamiętać o tym, że do wykonania jest projekt, a nie przebudowa całego ekosystemu klienta. Oczywiście, należy pokazać, gdy uważamy, że coś jest lepsze, ale nie naciskać. Jak się przyjmie to świetnie, jak nie, to warto odpuścić i skupić się na meritum.

  • Zatem: czego na pewno będziemy potrzebować?
Whiteboard, czyli po staropolsku tablica.

Element niezwykle istotny, bo i może jest mnóstwo oprogramowania, które próbuje oddać funkcjonalności tablicy… jednak żadne zdaje się nie oddawać wrażeń w ten sam sposób.

Stanie przy tablicy z markerem samościerlanym w ręku przypomina trochę pracę rzeźbiarza, który czy to dłutem czy też rękami modeluje uprzednio wyobrażony przez niego kształt.

Ta fizyczność substratu, na którym się pracuje, w jakiś nieodgadniony sposób, pochłania. Pędzi się po tablicy mazakami, czasami w ferworze ściera się palcem, coś się dopisuje, coś wyciera, coś zmienia. To uczucie tworzenia i zmiany jest tak bezpośrednie, że w zasadzie przeniesienie tego w świat cyfrowy moim zdaniem nie jest możliwe, ale jednak diabelnie trudne. Naprawdę warto zainwestować w ten niepozorny element, w szczególności, że nie jest on jakieś wybitnie drogi a komfort pracy twórczej jest nie do podrobienia.

https://evoila.com/blog/poswiecenie/

Kolejną rzeczą w każdej pracowni architektonicznej jest dobry, duży monitor wysokiej rozdzielczości.

Nie jest on moim zdaniem tak niezbędny jak tablica, ale na pewno się przydaje. Tworzenie na nim diagramów, przegląd dokumentacji jest o niebo prostszy. Ceny tych urządzeń w ostatnich czasach znacząco spadły i nie jest to już jazda za kilkadziesiąt tysięcy a za kilkanaście. Po pierwszym projekcie zrobionym na ekranie 13” laptopa zrozumiecie w czym rzecz.

Biurko i krzesło.

Nie polecam zasiadać do projektu na krześle z podstawówki dziecka lub co gorsza swojej. Sprawa ma się podobnie jak ze wzrokiem – tyle tylko, że jak oczy mamy dwa, tak plecy tylko jedne. Całodzienne siedzenie po 8h dziennie jak kwoka na grzędzie może je doprowadzić do takiego stanu, że schylenie się do wiązania butów będzie wyczynem niczym perfekcyjna ocena na 10 Nadii Comaneci.

Oprogramowanie.

Poza fizycznym aspektem naszej pracowni dochodzi jeszcze wątek bardziej ulotny, ale nie mniej ważny – oprogramowanie. W końcu nie projektujemy domku jednorodzinnego, czy stodoły a rozwiązania IT.

Ołówek i długopis na pewno się przydadzą, ale kreślić finalnie powinniśmy w jakimś sofcie.

Zacznijmy od oprogramowania do schematów, bo one są kluczem. W zasadzie na rynku projektowania infrastruktury IT są dwa standardy:

  • Viso
  • różne emanacje diagrams.net (dawniej Draw.io, znane również pod komercyjną odsłoną zwaną Gliffy oraz Lucidchart)
  • Oczywiście istnieją bardziej wyuzdane softy do robienia diagramów, ale ich obecność jest raczej niszowa i gdy traficie na projekt, który ich używa to warto zastanowić się, dlaczego.

Zacznijmy od tego pierwszego, czyli Visio.

Naturalnie stało się standardem, ponieważ było jednym z pierwszy narzędzi dostępnych dla szerokiego grona odbiorców – od 2000 roku jest fragmentem pakietu Office. Istnieje do niego dużo dodatków, wielu producentów robi swoje ikony i generalnie oprogramowanie to jest niezwykle użyteczne i dopracowane… ale, bo oczywiście jest pewne ale. Otóż przy bardzo złożonych rzutach, które mają wiele warstw, setki elementów i połączeń między nimi to do edycji takiegoż schematu trzeba mieć klaster HPC wyposażony w eksabajt RAMu.

Wiele projektów wymaga dostarczania dokumentacji w Visio i trzeba się na to przygotować.

Jednak, gdy nie ma standardu w tej materii narzuconego przez inwestora to warto pójść w stronę diagrams.net.

To bardzo lekka, superintuicyjna i wieloplatformowa aplikacja, która ostatnimi czasami zdobywa salony. W przeciwieństwie do Visio jest darmowa i istnieje jej odpowiednik w formie webowej. Poza standardowym oprogramowaniem do tworzenia schematów warto się zastanowić nad softem do obsługi map myśli. Zasadniczo możliwe jest ich tworzenie w oprogramowaniu do schematów, jednak ich edycja jest niezwykle karkołomna – trzeba przestawiać całe bloki, przesuwać połączenia co zajmuje ogromnie dużo czasu i energii. Oprogramowania tego typu w wersji online jest ogromnie dużo – tutaj nie ma jednego standardu, ani faworyta, to musi być subiektywny wybór użytkownika.

Miejsce do dzielenia się notatkami.

Kolejnym elementem, który należy rozważyć to miejsce do przechowywania, dzielenia się notatkami. Jak tworzenie notatek jest całkiem logiczne i wyjaśnia się samo, tak aspekt dzielenia może być zastanawiający. Już pędzę z wyjaśnieniami, otóż…

przesyłanie sobie notatek mailem jest, delikatnie mówiąc, nieskalowalne.

Jak zespół jest duży a projekt złożony, tych maili w pewnym momencie nikt nie czyta i jest to energia, która idzie w gwizdek. Natomiast notatki, które często są wzgardzane, dają podstawę do tworzenia ADR, (Architectural Decision Record), który musi wynikać z dokumentacji producenta rozwiązań, wymagań pierwotnych, umowy lub właśnie ze ustaleń na spotkaniach.

Mając notatki skatalogowane w jednym miejscu dość łatwo się w nich poruszać. Dodatkowo możliwość komentarzy bywa pomocna, gdy ktoś chce nam zwrócić uwagę na jakąś nieścisłość lub tryb recenzji, gdy ktoś coś w naszych notatkach zmieni. Notatki te zgrupowane w wątki będą tworzyć zarys architektury oraz oś wsparcia podczas dyskusji w wykonawcą, bądź też samym inwestorem, którzy to mogą w ferworze projektu doznać amnezji i zapomnieć swoje decyzje.

Dyskusyjne jest nagrywanie spotkań, warto to zaproponować otwarcie i nie bać się tej metody notowania, natomiast dla zachowania pewnego miru społecznego warto, aby wszyscy się na to zgodzili.

Gdy odmówią, warto to również zapisać w notatce.

Tytułowanie notatek powinno zawierać:

  • datę w formacie bezwzględnego sortowania – czyli rok, miesiąc, dzień.
  • Taka struktura da nam tytuł w formie np. 20210322, dzięki temu podczas sortowania po nazwie zawsze będziemy mieli pliki lub wpisy po kolei.

Jakie oprogramowanie warto rozważyć?

Podobnie jak przy sofcie do tworzenia schematów, warto pójść za pewnym ładem projektu – jeżeli używana jest platforma MS to wybór naturalnie pada na OneNote, jak nie, to można rozważyć EvernoteSimplenote itp.

Gromadzenie dokumentacji projektowej.

Bardzo ważnym aspektem jest samo gromadzenie dokumentacji projektowej i współpraca na niej przez zespoły nasze bądź klienta oraz później potencjalnych wykonawców.

Dróg mamy kilka, żądana nie jest idealna. Najgorsza to przesyłanie sobie plików mailem. To jest horror.

Gdy zespół jest 3-osobowy to może jeszcze da się to jako tako prowadzić, ale gdy wchodzimy w więcej niż 22 to zarządzanie wersjami dokumentacji staje się koszmarem. Nawet ninja PM z 10 danem w biczowaniu zwanym zarządzaniem może nie poskromić chaosu, który zacznie się już po pierwszym wydaniu dokumentacji do komentarza.

Nagle zaczniemy być obserwatorami nieokiełznanego samorozpłodu wersji i podwersji naszego dokumentu, a wszystkie w panice będą przesyłane do nas, aby je ujednolicać i formować z tego jednorodną masę.

Praca ta przypomina przerzucanie wody z jednego wiadra do drugiego sitkiem. Dodatkowo dochodzi jeszcze kwestia tego, czy dokument jest w odpowiednim formacie, czy wszyscy mają poinstalowane czcionki, czy ich np. MS Word lub jakiś inny wynalazek w stylu Libre Word, nie dorzuca czegoś od siebie… no i jeszcze wirusy, malware itd.

Warto do współdzielenia informacji wykorzystać zatem platformę.

 


Wyborów jest klika, ale finalnie znów mamy faworytów:

    • SharePoint (w zapleczu korzystający z Word/Excel),
    • Google Docs,
    • Atlassian Confluence.

W zasadzie te trzy platformy pozwalają nam próbować osiągać jednolitość dokumentacji i dyskusji na niej.

Zacznijmy od bardzo popularnego SharePointa.

Spełnia on większość oczekiwań, jednak poprzez fakt, że do edycji dokumenty otwierane są w Word, działającym w trybie edycji z często setkami komentarzy, potrafi zając cały RAM i wysycić CPU. Nie ma takiej bestii PC, którego nie dałby rady zajechać. Przy dużych projektach jest to dużym utrudnieniem i dokumenty posiadające kilkaset stron trzeba przez to dzielić na tzw. Tomy. To znów utrudnia poruszanie się po nich jako całości. Niema jednak co przesadzać, do projektów średniej wielkości rozwiązanie oparte o SharePoint się sprawdza i można wygodnie współdzielić i edytować dość obszerną dokumentację. Zarządzanie uprawnieniami jest bardzo dopracowane, dzięki czemu nie musimy się martwić o to, że ktoś niepowołany będzie miał dostęp do dokumentacji, jak również i członkowie zespołu mogą być dzieleni na edytorów, czytelników i adminów.

Aplikacja Google to druga strona medalu:

świetnie się sprawdza w edycji wspólnej plików, działa w zasadzie natywnie przez stronę web, jednak czasami przy bardzo złożonych strukturach dokumentów, tabel brakuje mu funkcjonalności MS Word.

Pewnym kompromisem tych systemów jest Confluance, który przychodzi niejako w paczce z systemem do prowadzenia projektu zwanym Jirą.

Dlaczego to ważne? Ponieważ Jira bardzo często używana jest w organizacjach do prowadzenia projektów, jest oprogramowaniem znanym czy lubianym to już bardzo zależy od projektu… Tym niemniej można by go przyrównać do oprogramowania typu wiki. Prowadzi się go w formie stron z nagłówkami, bardzo łatwo tworzy się treści, odnośniki między nimi oraz wrzuca pliki. Współpraca członków zespołu prowadzona jest nie w formie recenzji a komentarzy. Wszystko odbywa się poprzez stronę web. Coraz więcej projektów od początku swojego istnienia wymaga właśnie takiej formy prowadzenia dokumentacji, co jest pewnego rodzaju ulgą, ponieważ nie wymaga tworzenia dokumentów w pełnym tego słowa znaczeniu. Czyli odpada skupianie się nad formatowaniem, jednorodnością a umożliwia skupienia się na merytoryce.

Warto dorzucić jeszcze do wspomnianej trójcy o możliwości prowadzenia dokumentacji w Git.

Dlaczego to jest tak istotne?

Repozytorium plików.

Wspominane w poprzednim akapicie systemy współredakcji dokumentacji mogą być również repozytorium plików. To bardzo istotne, aby wszystkie materiały źródłowe znajdowały się w jednym miejscu. Nie chodzi tutaj nawet o pliki wykonywalne, obrazy ISO, czy też obrazy maszyn wirtualnych, choć i one w pewnym etapie projektu powinny znaleźć wspólne miejsce, a o pliki typu karty produktów aktualne na okres projektowania, kompendia najlepszych praktyk itd. Celem takiego agregowania jest bowiem przygotowanie się do odpowiedzi na pytania „z czego wynika tak zaprojektowane rozwiązania” i po kilku miesiącach może być wyzwaniem odnalezienie dokumentacji do potencjalnie starszych wersji produktów, lub też starych „dobrych praktyk”. Poza tym jedno miejsce sprawia, że dokumentacja jest kompletna i transparentna dla każdego. Repozytorium, które jest tworzone na potrzeby projektu powinno również zawierać fragment zawierający finalne wersje dokumentacji zaakceptowanej przez wszystkie strony. Pliki te powinny być niezmienne i łatwe w odczycie i wydruku – np. pdf.

Wnioski.

Narzędzia może i nie są najważniejsze i faktycznie liczy się wiedza…, ale jednak łatwiej się pracuje korzystając z rozwiązań sprawdzonych, z którymi nie musimy walczyć. Pozwala to na skupienie się nad meritum projektu ze świadomością wsparcia w narzędziach, które są niezawodne i nie tworzą nowych problemów.

Dobry kucharz zawsze ma swój ulubiony nóż.

Artykuł został opublikowany na łamach IT Professional.

Więcej tekstów z IT Professional