Droga Architekta IT – Wizja

Wszystko, ale to absolutnie wszystko da się zaprojektować. Od ogólnej wizji do najmniejszego detalu w najbardziej skomplikowanym systemie. Więcej! Nie tylko można, ale i bezwzględnie trzeba. Niestety często zapomina się o tym, że wszystko powinno mieć swój powód istnienia, a całe projektowane przez nas zagadnienie jest zestawem naczyń połączonych, w którym każdy element musi działać jak w szwajcarskim zegarku.

Na potrzeby tego artykułu weźmy na warsztat projekt infrastruktury informatycznej. W dzisiejszych czasach infrastruktura IT, nieważne, gdzie by się znajdowała – czy w chmurze, czy w tradycyjnych lokalnych DC – zdaje się być tematem wzgardzonym, nieco zmurszałym i generalnie passe. Mówi się o warstwach wyższych, potrzebach biznesowych, scrumach, ryzykach itp., które wyciągane przed nawias stanowią nowe paliwo podczas wielogodzinnych telekonferencji, rozpraw w studiach wykonalności etc. Oczywiście są to kwestie bardzo ważne, bo niejako infrastruktura IT jest odbiciem zdefiniowanych potrzeb. Sama w sobie jednak jest ogromnym, skomplikowanym meandrem zależności i czasami wręcz nieskończoną plątaniną wspomnianych wcześniej naczyń połączonych. Warto o tym pamiętać, gdy zaczyna się ją projektować.

Tworzenie infrastruktury IT to temat rzeka, a każdy z projektantów ma na to swój własny dopracowywany przez lata przepis. Powstało na ten temat wiele książek i dziesiątki publikacji. Wszystkie one mówią jednak o właściwej dla danego autora metodologii, pisane są przez architektów dla architektów. A co, jeśli chcemy sobie w ogóle proces ten wyobrazić, może zacząć pracę jako architekt? Jak się połapać w tych setkach metod i odkryć swoją drogę? Zacznijmy od początku…

Wizja.

Może zabrzmi to dziwnie, ale najważniejszy i zarazem najtrudniejszy krok to stworzenie wizji projektu. Choćby projekt był skandalicznie skomplikowany, musimy go „zobaczyć”. Brzmi to może nieco jak opowieść naszprycowanego szamana, ale tak jest. Jak? Sprawa jest dość prosta. Weźmy na tapetę generalny remont mieszkania albo budowę domu. Należy zacząć od zebrania informacji o potrzebach i jakieś chociaż zgrubne założenia. Zatem – jaka lokalizacja, materiały, budżet itp.

Bardzo ważną kwestią jest to, żeby zadawane pytania były dość ogólne, na szczegóły przyjdzie czas później.

Mogłoby się zdawać, że im więcej pytań zadamy, tym lepiej… I tak, i nie. Ich ilość należy dopasować do swojego poziomu inteligencji kognitywnej. Jest to pewnego rodzaju pojemność naszego mózgu i jego moc obliczeniowa w danym momencie. Chodzi o to, że gdy zada się zbyt wiele pytań, mózg może nie objąć wszystkich odpowiedzi na raz, a to wywoła frustrację, która sprawi, że nie będziemy w stanie zobaczyć obrazu tego, co się tworzy. Zatem pytań ma być tyle, by wciąż czuć się z nimi komfortowo, by nie doprowadzić do przepełnienia bufora. Z biegiem czasu pojawią się inne pytania, bo na poprzednie, odpowiedzi będą już znane. Jednak każdy projekt jest inny i czasami warto nie „jechać na pamięć”, mimo wszystko zadać pytania, które wydają się oczywiste. Zweryfikuje to stopień konkretności klienta i zaowocuje niższą liczbą iteracji podczas projektowania i mniejszą frustracją.

Zatem zacząć należy od wyobrażenia sobie drobnego szkicu czy to w tekście, czy w diagramie, czy może w punktach. Ważne, aby zacząć budować ramę przyszłego rozwiązania, jej szkielet.

Do czasu rozpoczęcia prac nic nie jest wyryte w kamieniu. Co więcej z biegiem czasu i postępujących prac prawdopodobnie bardzo wiele się zmieni. Tak ma być. To znaczy, że praca jest dobrze wykonywana i zmierza w dobrym kierunku. Tworzenie architektury to zawsze w pewnym stopniu odkrywanie nowego, często nieznanego lądu. Konkwistadorzy po wylądowaniu w Ameryce Północnej też nie od razu poszli, gdzie trzeba. Zajęło im to chwilę, w końcu jednak zdobyli ten Nowy Świat.

Wizja musi być wielopłaszczyznowa.

Głównym obowiązkiem architekta jest zrozumieć i wytłumaczyć. Można go sobie wyobrazić jako pająka siedzącego w środku pajęczyny, dzierżącego wszystkie nici. Jako drapieżnik nie przetrwa, jeżeli nie będzie doskonale rozumiał, dlaczego dana nitka drży, dokąd prowadzi oraz jak jest zbudowana. Im bardziej skomplikowany projekt, tym więcej nici będzie się zbiegać w centrum sieci. Te metaforyczne nici mogą reprezentować różne technologie, różnych ludzi i ich potrzeby. Dodatkowo, żeby było łatwiej te struny są połączone między sobą. Na początku może się to wydać onieśmielające, ale w efekcie pozwala dostroić wizję.

Nie można skupiać się tylko na technologii albo tylko na założeniach biznesowych. Dobry architekt łączy te dwa światy, buduje most porozumienia między interesariuszami a technologią.

Klienci nie muszą i raczej nie będą się znać na serwerach, systemach operacyjnych itp. I chociaż jest to rola projektanta, nie zwalania ona z obowiązku wytłumaczenia kontrahentom, dlaczego zdecydował się na zastosowanie tego lub innego rozwiązania. Inwestorzy mogą się nie znać, ale to ich pieniądze, a praca architekta jest jego podpisem.

Zawsze należy pytać. Dlaczego?

Zdarza się tak, że gdy dołącza się do projektu, jakiś zarys wizji już istnieje. Nie trzeba go kwestionować, a raczej pytać, dlaczego powstał w takim kształcie, jakie były założenia, dlaczego ktoś opracował to tak, a nie inaczej. Zakładając, że nic nie wiemy, nie wskazujemy bynajmniej na nasz brak kompetencji, a raczej na swoistą mądrość wyrażoną słuchaniem, które inicjuje empatię. Empatia? Jest niezbędna.

Dobry architekt to ktoś, kto słucha, rozumie i umie wytłumaczyć językiem zrozumiałym dla odbiorcy. Nie obnosi się ze swoją często obszerną wiedzą, nie próbuje upokarzać nikogo za to, że nie wie. Zadaniem projektanta jest wejść w skórę każdej ze stron i poczuć ten projekt z ich perspektywy.

Gdy zrozumie się ich punkt widzenia, dostarczony projekt będzie styczny z ideałem. Niestety empatia to broń obosieczna – istnieje ryzyko, że gdy za bardzo wejdzie się w buty tej drugiej strony, projekt nigdy nie zostanie skończony. A to on ma być priorytetem.

Dobry projekt, to skończony projekt.

Wydaje się, że dobrymi architektami mogą być osoby z pewnego rodzaju kontrolowanym rozdwojeniem jaźni. Z jednej strony umożliwia to pełne skupienie się na celu, z drugiej pozwala na „wejście w skórę” danej osoby, by popatrzeć przez jej oczy. Wydaje się to nieco przerażające, ale dłuższy staż na stanowisku architekta, pozwala dostrzec w sobie takie cechy. Choć jest to z pewnością po prostu skrzywienie zawodowe, bez inklinacji psychicznych.

Wizja zawsze posiada błędy.

Tak ma być, to zupełnie naturalne. Można to porównać do odkrywania mapy w grze strategicznej. Widać tylko te miejsca, w których się było, a to zajmuje czas. Im dłużej trwa gra, tym więcej widać, tym lepiej można zaplanować. Trzeba jednak pamiętać o istnieniu takiego zjawiska jak mgła wojny. Opisuje to sytuację, gdy jednostka znajduje się w danym miejscu, widać wszystko, co dzieje się na danym obszarze mapy w czasie rzeczywistym. Gdy odejdzie z danego punktu, pozostaje jedynie zarys mapy z jej ostatnim stanem. Tak samo jest z wiedzą o projekcie. Gdy architekt bezpośrednio się nim zajmuje, wie o nim wszystko, gdy jednak przenosi się na inny obszar, jego wiedza się dezaktualizuje i może się okazać, że to co wie, nie jest już aktualne. Architekt musi wracać do różnych zakresów projektu, pielgrzymując między interesariuszami. To element roli tłumacza, emisariusza i moderatora.

Podczas tworzenia wizji klient musi mieć przestrzeń. Należy być wspomnianym moderatorem – z jednej strony pozwolić mu snuć jego wyobrażenia, ale możliwie jak najczęściej podsuwać pomysły, które pozwolą stworzyć wspólną wizję. Nie ma lepszych pomysłów niż te, na które wpadnie klient. Przejmowanie się autorstwem to największy błąd początkującego architekta – obrażanie się na klienta za to, że wpadł na jego pomysł. Najważniejszy jest projekt, więc należy uznać to za wygraną. Dobry pomysł naturalnie przybliża do osiągnięcia sukcesu. Gdy pomysł wydaje się nietrafiony, nie należy od razu go negować. Bardzo często kuriozalne, zdawać by się mogło w pierwszej chwili, pomysły nie znajdują zrozumienia, a mogą okazać się genialne.

W pierwszej chwili wiele pomysłów wydaje się kuriozalnymi, a w efekcie okazują się genialne.

Architekci często bywają ekspertami w jakiejś dziedzinie – czy to w wirtualizacji, sieci, storage, czy w którymś z systemów operacyjnych. Okazuje się, że bycie specjalistą nie pomaga, a w  przypadku architekta może okazać się przeszkodą. Jeżeli jest w czymś „dobry”, to niechętnie opuszcza swoją strefę komfortu, a projekty mają zauważalny punkt grawitacji, ze zwrotem skierowanym w określoną specjalizację. To wada, dlatego że często zdarza się, że przez skupienie, np. na sieci, po macoszemu potraktowane są inne aspekty projektu.

Architekt musi być generalistą.

Nawet gdy specjalizacja jest wybitna, doszczegółowienie danego zakresu musi zająć się ktoś inny, o lepszych bądź gorszych umiejętnościach. Bycie jednocześnie projektantem i wykonawcą ma szansę zadziałać przy małym projekcie – przy dużym nie starczy na to czasu, zasobów i dramatycznie zmniejszy jakość samego projektu. Zdaje się to proste, niestety nie jest takie w rzeczywistości. Trudno sobie wyobrazić, że ktoś w danym projekcie, z zupełnie inną logiką w domenie, w której architekt jest specjalistą przedstawia inną drogę niż autor wizji. Co zrobić? Przygryźć wargi i pozwolić na to. To nie jest proste, ale niezwykle odświeża perspektywę. Po kilku takich razach można dostrzec nowe metody, nowe perspektywy na rozwiązanie jednego problemu. Jest to z jednej strony fenomenalne uczucie a z drugiej niezwykle poszerzające wiedzę.

Generalista widzi szeroko i płytko, a specjalista wąsko i głęboko. Architekt, żeby ujrzeć wizję, musi być tym generalistą.

Wizja bardzo często kojarzona jest z produktem, który nazywa się HLD (ang. High Level Design). Na pewno fragmentem tego dokumentu jest wizja, ale ma on szerszy kontekst. HLD zasadniczo następuje po opracowaniu wizji i jest jej rozwinięciem o dość już konkretne elementy. Zatem wizja to bardziej koncepcja techniczna. Projekty, których poziom skomplikowania jest znaczący, zazwyczaj wymagają stworzenia takiego dokumentu. Powodów jest wiele, ale główny wiąże się z wyrysowaniem wizji, zanim wejdzie w etap szczegółów. Bardzo kuszące bowiem wydaje się zrobienie wszystkiego na raz, jednak przy dużych projektach zgoła niemożliwe jest, aby zrobić to w jednym kroku. Nie pozwala na to ani percepcja wykonawców, ani klienta.

Zdarza się, że w toku dalszych prac i odkrytych szczegółów trzeba zmodyfikować koncepcję, jednak są to zazwyczaj drobne zmiany, a nie wyrzucenie całego konceptu do kosza i tworzenie go na nowo. Zasadniczo wizję należy sformułować w sposób możliwie jak najkrótszy i zwięzły – ma to być esencja celu. Takie wydestylowanie myśli początkowo może być dość trudne, ale musi to być możliwie jak najprostsza, zrozumiała dla wszystkich prezentacja.

Executive Summary.

Pisząc koncepcję, trzeba o niej myśleć niejako jak o tzw. „executive summary” (ES) czyli podsumowaniu dla zarządzających projektem. Co do zasady takie podsumowanie musi być jak najkrótsze i zawierać w sobie informację o tym, po co to robimy. Zależnie od projektu może się tu znaleźć również opis tego, z czego mniej więcej projekt się składa, jaki jest jego stan obecny i jakie są założenia na przyszłość oraz jak wpłynie na biznes. Koncepcja zawiera podsumowanie jako takie, dodatkowo delikatnie je rozwija o podstawowe założenia, które docelowo zmienią się w Architectural Decision Record – odrobinę technologii i kwestie organizacyjne, np. ogólny harmonogram, jak również (o ile możliwe jest ich zdefiniowanie na tym etapie) ocena ryzyka.

Przelewanie wizji w słowo pisane okraszone diagramami musi już na tym etapie wykazywać jakąś logikę.

Poza wstępem obejmującym ES, taki dokument będzie zawierał ogólny ADR, zdefiniowanie celu projektu, ewentualne przedstawienie tego, jak sytuacja wygląda teraz (przed projektem) oraz oczekiwane rezultaty (kryteria sukcesu) i ogólny opis architektury. Opis ten można oczywiście wykonać spontanicznie, ale to nie pomoże w kolejnych krokach. Myśląc nad wizją projektu, a późnej ją spisując, należy starać się zamykać elementy architektury w bloki tematyczne nazywane „building block”.

Na etapie wizji są to duże klocki – sieć, bezpieczeństwo, backup itp. Późnej, myśląc o tych dużych elementach układanki, można przedstawiać to w diagramie, a następnie tak stworzony diagram opisać. Często podczas tworzenia opisu diagram się zmienia – to dobry znak, który mówi o tym, że koncepcja ma potencjał. Gdy nie wiadomo, jak coś narysować lub opisać, trzeba powrócić do interesariusza, którego dotyczy ten fragment, i doprecyzować.

Tworzenie wizji projektu to swoisty proces twórczy, którem trzeba dać się ponieść i zabrać klienta ze sobą.

Diagram i jego klocki.

Stworzoną koncepcję przedstawia się zainteresowanemu gronu. To jeszcze nie jest miejsce na specjalistów – będą widzieli zbyt wiele nieprecyzyjnych określeń i problemów wynikających z ogólności wizji. Na tym etapie dobrym posunięciem jest porozumienie z interesariuszami biznesowymi – wytłumaczenie każdego z dużych klocków przedstawionych na diagramie, opisanie relacji między nimi oraz przypisanie adresowanych założeń i celów. To moment na dyskusję o dużych zmianach oraz na zrozumienie potrzeb. Jeżeli po konsultacjach wciąż pozostają nierozstrzygnięte kwestie, trzeba je powtarzać do skutku, aż koncepcja w pełni będzie odzwierciedlać założenia interesariuszy. To na tym etapie zapadają największe decyzje, które kształtują projekt zarówno z perspektywy wykonawcy, jak i klienta.

Klienci bardzo często nie znają się na tym i nie wiedzą, jak to, co teraz jest projektem, finalnie będzie działać. Odpowiedzialnością i obowiązkiem architekta jest im to wytłumaczyć.

To początek drogi projektu i najgorsze, co można na tym etapie zrobić, to zamieść coś pod dywan, przemilczeć… Podczas krystalizowania wizji nie ma miejsca na półprawdy, liczy się pełna transparentność i szczerość. Jeżeli projektant nie wie czegoś do końca, powinien udać się do specjalistów i wrócić ze szczerą odpowiedzią. Błąd na tym etapie będzie wymagał sporo tłumaczenia w późniejszym czasie.

Za wszelką cenę należy domagać się komentarzy, a gdy już zostaną sformułowane, nie można ich ignorować.

Brak komentarzy odnośnie koncepcji może oznaczać trzy rzeczy.

• Po pierwsze może po prostu nikt jej nie rozumie. Powodem może być błąd logiczny w myśleniu, język, nieodpowiedni poziom wizji do audytorium itd. Jest to poważny i częsty problem. Niezrozumienie się na tym etapie rozwali projekt. Trzeba dalej szukać języka porozumienia z klientem, to pole do popisu dla wykazania się wspomnianą już empatią.
• Drugą przyczyną może być to, że wizja jest całkowicie błędna i nikt nie chce rzucić pierwszy kamieniem.
• Trzecia kwestia dotyczy chronicznego braku czasu –wszyscy zainteresowani są ekstremalnie zajęci i nie znaleźli chwili na przegląd koncepcji. Jest to również dość popularny problem, który może być nawet bardziej niebezpieczny dla powodzenia projektu niż niezrozumienie. Brak czasu na tym etapie, będzie tylko eskalował podczas trwania projektu i może się okazać, że po prostu nie będzie miał go kto zrealizować, skoordynować itd. W takiej sytuacji należy jak najszybciej uwypuklić tę kwestię, aby ktoś „wyżej” znalazł ludziom zaangażowanym w projekt czas.

Wizja zawsze musi być wielopłaszczyznowa, będzie się zmieniać i będzie obarczona błędem.

Należy pamiętać, że projektowanie polega na zmniejszaniu potencjalnego ryzyka błędu. Jest to tragiczna droga do ideału, którego prawdopodobnie nigdy się nie osiągnie. Natomiast trzeba za wszelką cenę próbować. Droga ta również wymaga dużo refleksji nad popełnionymi błędami i kreatywności w przedstawianiu sposobu ich naprawy… A wizja to dopiero pierwszy krok. O następnych opowiem w kolejnej odsłonie Drogi Architekta IT.

Artykuł został opublikowany na łamach IT Professional.

Więcej tekstów z IT Professional