Jeśli miałeś kiedyś okazję zbudować nowy produkt (działające oprogramowanie) od podstaw (oczywiście, żeby nie było zbyt łatwo, przy licznych ograniczeniach czasowych i finansowych) i potem może jeszcze próbowałeś to komuś sprzedać, to wiesz już zapewne, jak prawdziwe jest motto:

„Agile to sztuka maksymalizacji pracy niewykonanej”

Tak, Agile to sztuka. I może właśnie dlatego lubimy Agile? Bo jesteśmy ludźmi, bo lubimy tworzyć, bo lubimy nadawać znaczenie i mieć wpływ na to, co powstaje w naszym zespole.

Ten, kto nadaje szkic całemu rysunkowi w zespole programistycznym to architekt. I bycie architektem to sztuka, niewątpliwie wielka sztuka.

Architektura kojarzy się z pojęciem technicznym, z naciskiem na to, że kluczowe decyzje, które muszą być podjęte, są decyzjami technicznymi. Architekturę systemu informatycznego można by zdefiniować jako sumę nietrywialnych modułów, procesów, danych systemowych, ich struktury i wzajemnych relacji, technologii, od których zależą. Dzisiaj nie chcę jednak pisać o API, wzorcach projektowych, MVC, interfejsach i wyższości jednej technologii nad drugą. Chciałabym natomiast pokazać, że architektura to coś więcej, to też aspekty biznesowe i ludzkie; pokazać, jak dużo różnych czynników musi wziąć pod uwagę (i jak dużo decyzji podjąć) architekt, żeby projektowany przez niego produkt był fajny dla użytkownika, dawał fun jego twórcom, no i oczywiście – na końcu okazał się opłacalny biznesowo.

Jeśli nie czujesz się jeszcze architektem, to może po przeczytaniu tego artykułu odkryjesz przed sobą wyzwanie i choć trochę Cię on natchnie, żeby się w tym kierunku rozwijać. Jeśli zjadłeś zęby na projektowaniu architektury, to może i niczego się nie dowiesz, ale mam nadzieję, że chociaż poczujesz się doceniony za swoją ciężką, twórczą pracę.

Subiektywizm spojrzenia na architekturę

Jeśli poprosisz kolegę/koleżankę, żeby opisali architekturę systemu Windows, to jedna osoba zacznie mówić o obsłudze sterowników, druga o jądrze i podsystemach, a trzecia powie o interfejsie użytkownika i okienkach. Który opis będzie najlepszy? Najbardziej trafny? Nie wiem. Może każdy?

Przy takim eksperymencie można zauważyć, że często gdy ludzie opisują architekturę systemu, to wybierają te elementy, które subiektywnie są dla nich najważniejsze. Podobnie jest z architektem przystępującym do pracy. W momencie, gdy zabiera się on za projektowanie, zaczyna w naturalny sposób od tych kwestii, które są ważne dla niego. W efekcie często w początkowych dyskusjach architektonicznych omijane są niektóre tematy, które mają niezwykle istotny wpływ zarówno na techniczne, jak i biznesowe aspekty dalszego wytwarzania oprogramowania. Patrząc od strony sprzedaży, będzie to na przykład branding, sposób wdrożenia, fakturowanie czy licencjonowanie. Patrząc od stron zespołów wykonawczych, z kolei wymieniłabym pracę zespołową, indywidualne odczuwanie czy aspiracje i marzenia programistów.

Miary sukcesu dobrej architektury

Zanim jednak przejdziemy dalej, pomyślmy chwilę o celu. Chcemy oczywiście zaprojektować dobrą architekturę. Jak więc ocenić, czy architektura jest dobra? Poniżej kilka potencjalnych pomysłów na to, jak podejść do tematu.

Architektura:

  • ma zapewnić długi czas życia systemu (zwykle nie chcemy tworzyć systemu na rok czy dwa, raczej na 10-12 lat, a może i dłużej),
  • ma zapewnić stabilność systemu (zamiast coś ciągle zmieniać, robić kolejny refaktoring po roku istnienia komponentu, chcemy pracować nad elementami dostarczającymi dużą wartość biznesową),
  • ma zapewnić możliwości dokonywania zmian (chcemy być w stanie dodać szybko funkcjonalność, która ma dużą wartość dla klienta, bądź szybko dokonać modyfikacji funkcjonalności, np. jeśli dotyczące jej wytyczne prawne się zmieniły),
  • ma zapewnić zyskowność (ładny nie znaczy od razu zyskowny, zyskowny nie znaczy koniecznie ładny),
  • ma służyć zespołowi, który ją stworzył (zespołowi ma się przyjemnie nad produktem pracować),
  • ma mieć jasno zdefiniowane ograniczenia (ustalamy, które elementy piszemy sami, a w ramach których powinniśmy napisać własny interfejs czy użyć gotowego open-source’owego rozwiązania,
  • być z jednej strony jasna i przejrzysta, a z drugiej strony na tyle oryginalna, że trudna do zduplikowania (jeśli nie, to może nie będzie konkurencyjna).

Na początku systemu informatycznego był…

…człowiek, jego idea i jego potrzeba: „Ja jako <Użytkownik> chciałbym <taki pewien bardzo fajny system>, żeby móc <spełniać swoje potrzeby>  i/ bądź <obowiązki sprawozdawcze względem Generalnego Inspektora Informacji Finansowej>)”. A że każdy kij ma dwa końce, to mówimy też często jako programiści „użytkownik końcowy”.

Na cały proces wytwarzania oprogramowania, więc i na projektowanie architektury, powinno się patrzeć z punktu widzenia użytkownika końcowego. Godzina spędzona z użytkownikiem końcowym jest warta więcej niż dni spędzone na dokumentowaniu wymagań i podejmowaniu decyzji architektonicznych.

“Działające oprogramowanie ponad obszerną dokumentację” – kojarzysz zapewne z Manifestu Agile?

– Ale ja nie lubię gadać z ludźmi, lubię tworzyć, lubię pisać programy, lubię komputery – jestem introwertykiem, czego ty ode mnie wymagasz?! – powie może niejeden programista.

Albo:

– Ja się nie znam na sprzedaży. A jak pójdę do klienta i powiem coś, co będzie nie po myśli mojego szefa, to co?

Problem w tym, że stworzenie dobrej architektury jest praktycznie niemożliwe bez wielu interakcji z różnymi ludźmi, bez pytania ich o subiektywny punkt spojrzenia na architekturę i to, co dla nich w systemie ważne. Jeśli jesteś początkującym programistą i nie masz jeszcze doświadczenia w bezpośredniej pracy z klientem, to możliwe, że przeraża Cię wizja rozmowy twarzą w twarz z obcą panią z banku czy innym przedstawicielem potencjalnego klienta.

Podsuwam kilka rad, żeby się poczuć w tej kwestii bezpieczniej:

  • Na wszelki wypadek nie składaj żadnych obietnic (od tego z pewnością będą na spotkaniu inni).
  • Lepiej nie mów negatywnie o żadnych produktach (ani firmy, którą reprezentujesz, ani o produktach konkurentów).
  • Nie mów „to powinno być łatwe”, bo klient może odnieść fałszywe przekonanie, że łatwe – czyli dla programisty nieskomplikowane – znaczy bardzo tanie, bo mało pracochłonne i zdziwi się potem, dostając wycenę.
  • Nie mów też „to będzie bardzo trudne”, żeby klient nie odniósł wrażenia, że sobie z czymś nie poradzimy bądź będzie to bardzo drogie. Rozmowy z klientem mają na celu często wypracowanie optymalnego dla obu stron rozwiązania i „przestraszenie” klienta może zbyt szybko takie rozmowy przerwać.
  • Słuchaj, a nie oceniaj. Klienci nie są głupi, mogą być ignorantami w niektórych dziedzinach, ale nie są leniwi i mogą mieć własne priorytety.

Oprogramowanie ma wspierać użytkownika, musimy zrozumieć jego potrzeby i priorytety. Jak nie wierzysz, to przypomnij sobie, ile razy, korzystając z jakiegoś systemu, powiedziałeś sobie w głowie: „No tak, XXX jak zwykle wie lepiej…”. I jak się wtedy czułeś?

To skoro najtrudniejsze mamy za sobą, to przejdźmy może do łatwiejszych kwestii.

Przenośność

Programiści często uważają, że pisanie przenośnego oprogramowania jest cool, że pokazują w ten sposób swoje szerokie kompetencje. Przedstawiciele sprzedaży mówią z kolei, że przez zapewnienie przenośności, pisanie uniwersalnego oprogramowania zyskamy nowy segment rynku lub pokażemy, że jesteśmy w stanie sprostać bardzo wymagającym klientom i ich specyficznym wymaganiom.

Koszty zapewnienia przenośności są zwykle bardzo duże:

  • szkolenia programistów,
  • zakup, instalacja i wsparcie platformy, sprzętu,
  • czas testowania,
  • złożone generowanie wydania itd.

W rzeczywistości umiejętności czy technologia rzadko przekonują klientów. Liczy się skuteczna segmentacja rynku. Projektujesz architekturę systemu, postaraj się dostarczyć osobom decydującym o tym, w który segment rynku wchodzić bądź nie, takich informacji jak na przykład: koszty utrzymania obsługi kilku wersji przeglądarek czy koszty wsparcia dla różnych wersji Oracle’a. Może czasem taniej i lepiej dla obu stron jest przekonać klientów, żeby już jednak nie używali IE11, niż wprowadzać kosztowne modyfikacje oprogramowania.

Branding

A skoro już jesteśmy przy sprzedaży, to nie można nie wspomnieć o elementach związanych z marką. Elementy brandingowe: nazwa, kolory, logo i dźwięki, znak ™ (trademark) są też częścią architektury, która powinna być zarządzana i łatwo podmieniana, która występuje w formie graficznej w systemie, ale też i w dokumentacji.

Zgadnij, jak długo można dyskutować z przedstawicielem sprzedaży o nazwie produktu? Zapewniam Cię, że długo.

Ma być krótkie ETL czy ustandaryzowane aS-Datacalc?

ION czyta się ‚ajon’, jak ‚ajfon’ (iPhone) lub ‚ajoes’ (iOS), czy może jednak ‚jon’ (jak podstawowa cząsteczka materii, z której się składa większą całość)?

I czy to ma sens? Oj, zdziwiłbyś się może, ale ma. Choć, no dobra – może tylko dla niektórych – ale z nimi też się trzeba liczyć.

Oprócz nazwy trzeba jeszcze pomyśleć o projekcie graficznym logo, jego rozmiarze i o tym, gdzie dokładnie tego typu elementy mają być umiejscowione w interfejsie. A ile ludzi, tyle punktów widzenia i opinii. I człowiek może się starać jak tylko może, żeby każdemu dogodzić, a potem i tak się znajdzie ktoś, komu się coś nie spodoba.

I w tym momencie chciałabym jeszcze raz szczerze serdecznie przeprosić kolegę, któremu publicznie (przy innych kolegach i koleżankach z FINGO) powiedziałam, że kolor jaki wybrał na pop-up jest brzydki. Ja naprawdę doceniam Twoją ciężką i trudną pracę.

Instalacja

Gdy już zaimplementujemy i sprzedamy produkt, to klient będzie go musiał sobie zainstalować. Na etapie projektowania może się to wydawać odległą przyszłością, niemniej jednak pominięcie pewnych aspektów podczas robienia szkicu architektonicznego może drogo kosztować.

Wyobraźmy sobie, że klient dostaje oprogramowanie, które składa się z kilku komponentów, dla każdego z nich musi zbudować i skonfigurować odpowiednie środowisko, zabiera się za robotę i stwierdza:

– To za skomplikowane, zaraz coś zepsuję, lepiej sam nic nie będę robić. O! Mam wykupioną usługę wsparcia, zaraz zadzwonię na support. 🙂

I mamy biedny support…

Żeby uniknąć takich sytuacji, można się zastanowić i zaprojektować jako element systemu, np:

  • kreator instalacji (ang. wizzard),
  • przejrzystą instrukcję instalacji,
  • skrypty automatyzujące instalację (dobrze zadbać o pasek postępu, możliwości przerwania instalacji).

A sprzedawca nam i tak jeszcze doda, że musi mieć możliwość obsługi licencji.

A co z aktualizacją oprogramowania? To chyba jak z instalacją, tylko trochę gorzej, bo klient może chcieć wrócić do poprzedniej wersji, bo klienci nie robią aktualizacji na bieżąco, bo trzeba pamiętać o change logu i migracji danych.

Z pomocą przychodzą nam na przykład odpowiednio zaprojektowane pliki konfiguracyjne przechowujące parametry czy elementy diagnostyczne poprawności instalacji.

Bezpieczeństwo

A jak już mówimy o instalacji i konfiguracji, to zaczynamy wchodzić w temat bezpieczeństwa danych i decyzje, np. które elementy konfiguracyjne mogą być przechowywane w jawnym pliku konfiguracyjnym, a które muszą być zaszyfrowane (bo hasła administratora to chyba nie chcielibyśmy wszystkim ujawniać).

Bezpieczeństwo to też często konfigurowanie praw dostępu zaraz po instalacji, to też niezawodność i podsystem robienia kopii zapasowych, zabezpieczenia przed włamaniem czy bezpieczeństwo transakcji i…  Nie, o tym słowie na „r” nie będę się rozpisywać.

Technologia

Wreszcie dochodzimy do technologii. Wiem, miałam o tym nie pisać, ale napiszę chociaż kilka słów, bo każdy architekt systemu prędzej czy później będzie musiał podjąć decyzję typu: w czym to mamy zakodować, którą bazę danych wybrać?

Jeszcze z czasów studiów na Politechnice Wrocławskiej pamiętam dyskusje nad wyższością języka C nad językiem Pascal. Świat się aż tak bardzo nie zmienia i teraz między programistami, często z różnych firm, słyszę czasem dyskusje na temat tego, co jest lepsze: React czy Angular, Derby czy Oracle, Maven czy Gradle itp. Każda strona ma swoje argumenty, każda sensowne. I jak ten biedny architekt ma podjąć teraz decyzję? Im więcej takich dyskusji słyszę, tym bardziej dochodzę do przekonania, że to naprawdę nie ma takiego znaczenia jak fakt, że zespół chce tę czy tamtą technologię. Ludzie muszą czuć, że technologia im pasuje, że im się fajnie system będzie tworzyć, że lubią dane środowisko programistyczne. Jeśli większość ludzi w zespole chce nową, może mniej znaną i sprawdzoną technologię niż starsze, tańsze, którymi podobne funkcjonalności też można zaimplementować, to może to być bardzo dobry wybór. Programista czy tester, żeby dobrze pracować, musi mieć przy tym odrobinę fun’u, radości, musi czuć, że się rozwija, i że praca sprawia mu przyjemność. Jest to jeden z głównych czynników sukcesu projektu. Technologia narzucona odgórnie, po wnikliwych analizach osoby nieznającej dobrze zespołu, może być bardzo ryzykownym elementem całego projektu.

Mogłabym jeszcze rozwinąć temat o aspekty takie jak: rozlokowanie systemu, wydajność, interfejsy zewnętrzne czy ergonomię, ale myślę, że uff… dużo tego.

– No dobrze – zapytasz – to co w końcu jest tutaj najważniejsze? A można by tak jednym zdaniem, bo się pogubiłem?

Jakby się tak zastanowić, to jakiegokolwiek aspektu z powyższej listy nie weźmiesz pod uwagę, to na końcu, na początku czy w tle jest zawsze jeden element człowiek. To nie program, technologia, wydajność czy pieniądze są najważniejsze – tylko człowiek.

Bycie architektem jest sztuką. Dla człowieka i od człowieka.

Jako Produkt Owner dziękuję wszystkim moim koleżankom i kolegom z FINGO, którzy pomagają mi w mojej codziennej pracy jako wysokiej klasy architekci-ludzie.

 

P.S. Jak kogoś zainteresował temat, to może o tym szerzej poczytać w książce Luke’a Hohmanna „Beyond Software Architecture”, którą znajdziecie w naszej biblioteczce FINGO pod numerem 12.