Co PM powinien wziąć pod uwagę: architektura projektu, integracja i bezpieczeństwo

Wyobraź sobie sytuację. Dotarł nowy projekt. W przedsprzedaży zespół techniczny zaproponował plan pracy i przekazał go Project Managerowi. PM zamiast przygotowywać ofertę dla klienta, stara się zrozumieć kilka kwestii. Skąd wzięło się tyle godzin na tworzenie aplikacji? Dlaczego do wdrożenia konkretnego produktu potrzebny jest nam kolejny programista? Jak wytłumaczyć klientowi, że pełna identyfikacja klienta nie jest chwilową modą?

Odpowiedzi na te pytania leżą w zrozumieniu przez Project Manager (PM) technicznego komponentu rozwoju projektu: od architektury i integracji z systemami zewnętrznymi po bezpieczeństwo produktu.

Architektura projektu i jej wpływ na proces

Jak będzie wyglądał dom? Jak będzie funkcjonował? Od tego zależy jego architektura. W przypadku IT sytuacja jest podobna. Czy klient chce opracować aplikację lub stworzyć sklep internetowy? W każdym razie należy wziąć pod uwagę architekturę (software architecture) przyszłego projektu. To ona decyduje: jak wszystko wdrożyć i jak to będzie ostatecznie działać. Zatem zrozumienie software architecture i ekspertyza techniczna są must have nie tylko dla programistów, ale także dla PMów.

Pytanie brzmi, jak rozumieć software architecture. Radzimy zacząć od zrozumienia, jak architektura wpływa na tworzenie (pisanie) produktu w IT.

Architektura dyktuje, w jaki sposób piszemy aplikację

Gładka, czasem wyboista, rzadziej idealna. Wszystko to można powiedzieć o tworzeniu dowolnej aplikacji, ale we wszystkich przypadkach jedno pozostaje niezmienne – produkt jest budowany według określonego modelu projektowego. Istnieją dwa podstawowe modele: MVC i MVP

MVC (Model-View-Controller  – “Model -Widok – Kontroler”). W tym przypadku aplikacja jest podzielona na osobne moduły lub komponenty. Każdy komponent ma swój własny kod i odpowiada za swoją część ogólnej funkcjonalności:

• Model. Przechowuje dane i metody pracy z nimi. Moduł ten otrzymuje od Controller żądanie aktualizacji danych, a następnie przekazuje niezbędne informacje do View w celu wyprowadzenia ich do użytkownika. W rzeczywistości taka jest logika biznesowa programu.
• View. Otrzymuje niezbędne informacje od modelu i wyświetla (przedstawia) je użytkownikowi. Jeśli utworzysz powiązanie z prawami dostępu do dokumentów, wówczas widok\prezentacja będzie mogła jedynie „odczytywać” dane z Model.
• Controller. Odpowiedzialny za interakcję użytkownika z aplikacją. Otrzymuje żądanie od użytkownika, które następnie przekierowuje do Model w celu przetworzenia w celu dalszego wyświetlenia pożądanego wyniku poprzez View.

MVC charakteryzuje się przejrzystą hierarchią oraz faktem, że blok Model sam w sobie mówi View jakie dane ma pokazać. Działanie modelu można scharakteryzować za pomocą następującego łańcucha: User → Controller → Model → View → User. 

MVP (Model-View-Presenter – “Model-Widok-Prezenter”)). Podobnie jak MVC, ten model projektowy jest również podzielony na osobne komponenty:

• Model. Oto dane przesyłane użytkownikowi w celu wyświetlenia na żądanie Presenter. Różnica między tym blokiem a tym samym blokiem w MVC polega na tym, że można go zmienić w MVP.
• View. Współpracuje z Presenter w dwóch kierunkach: wysyła żądanie od użytkownika i wyświetla użytkownikowi niezbędne informacje otrzymane od Model.
• Presenter. Współdziała z obydwoma częściami funkcjonalnymi modelu. Za pośrednictwem tego bloku do Model wysyłane jest żądanie zmiany danych lub tego, jakie informacje powinny zostać wyświetlone użytkownikowi. Z komponentem View praca opiera się na wyświetlaniu aktualizacji UI i odbieraniu działań użytkownika.

Jeśli porównać MVP z MVC, główną różnicą jest warstwa Presenter pomiędzy View i Model, która pozwala skonfigurować bardziej elastyczną interakcję pomiędzy modułami. Pracę tego modelu można opisać w następującym łańcuchu: User → View ⇆ Presenter Model ⇆ Presenter ⇆ Presenter ⇆ View → User. 

Obydwa modele projektowania pokazują, że architektura aplikacji pod względem pisania polega na podziale kodu na logiczne komponenty, z których każdy odpowiada za swoją część pracy projektowej. W idealnym przypadku wszystkie moduły są od siebie niezależne. Dzięki temu możliwa będzie zmiana/zastąpienie dowolnego z nich bez ingerencji w inne, co znacznie obniży koszt ewentualnej refaktoryzacji (przeróbki kodu).

Odpowiednio dobrana architektura pozwala łatwo złożyć procesy biznesowe w logiczne łańcuchy, niczym konstruktor LEGO z klocków. W przypadku błędów w działaniu produktu łatwiej jest je uchwycić w czytelnej i zrozumiałej strukturze niż w „twórczym chaosie”. Wszystko razem umożliwia szybkie napisanie aplikacji przy minimalnych modyfikacjach podczas pracy.

Znajomość tych punktów oraz wpływu architektury na działanie aplikacji pomaga PMowi:

• Już na etapie oceny projektu słuszne jest przeznaczenie czasu na tworzenie software architecture i refactoring. Dlaczego ważne jest rozważenie możliwego zadania refaktoryzacji kodu? Zawsze istnieje możliwość zmian w logice biznesowej, uzupełnień do projektu itp.
• W przypadku błędów w działaniu aplikacji, być na tych samych falach z twórcami, aby szybciej włączyć się w proces rozwiązywania problemu.
• Łatwiej i szybciej wytłumaczysz klientowi, dlaczego stworzenie produktu lub wprowadzenie zmian, wymaga określonej ilości czasu i pieniędzy.

Teraz zrozumiemy wspólnie, jak software architecture wpływa na działanie aplikacji.

Architektura dyktuje sposób działania naszej aplikacji

Produkt może mieć dobry i poprawny kod, jednak w przypadku popełnienia błędów w software architecture działanie takiego rozwiązania staje pod znakiem zapytania. Dlatego na początkowym etapie tworzenia aplikacji obowiązkowy jest wybór odpowiedniego rodzaju architektury – monolitycznej lub mikroserwisowej:

• Monolit (Monolith). W tej strukturze projekt znajduje się w jednej bazie kodu, czyli wszystkie bloki funkcjonalne są od siebie zależne.

• Mikroserwisy (Microservices). W tym rozwiązaniu baza kodu składa się z odrębnych mikroprojektów, z których każdy odpowiada za swoją część ogólnej funkcjonalności. Moduły współdziałają ze sobą według programowalnego algorytmu, tworząc razem jeden system.

Różnica w strukturze każdego typu architektury dyktuje dalsze działanie aplikacji, możliwość modernizacji i rozbudowy funkcji systemu. Do małych zadań, gdzie obowiązuje prosta logika biznesowa i przejrzysta hierarchia, odpowiednia jest opcja Monolith. W przypadku dużych projektów o różnorodnych funkcjach, gdzie każde działanie może zależeć od wielu czynników, optymalne jest wykorzystanie Microservices.

Nie ma reguły, że monolit jest zły, a mikroserwisy dobre. Każdy projekt wymaga znalezienia własnego, odpowiedniego rozwiązania. Ważne jest również, aby PM zrozumiał, że software architecture jest dla niego jednym z wyznaczników kwalifikacji. Im lepsza jest ta szkoła, tym bardziej ceniony jest taki specjalista. Podobnie wygląda sytuacja z integracją projektu z systemami zewnętrznymi. Jeśli project manager to zrozumie, z pewnością będzie w stanie „pociągnąć” zarządzanie poważnym projektem.

Integracja z systemami zewnętrznymi

System zewnętrzny to specjalistyczne oprogramowanie pochodzące z serwisu zewnętrznego.

Wyobraźmy sobie sytuację, w której aplikacja potrzebuje modułu płatności. Zdaniem ekspertów jego opracowanie zajmie miesiąc, a jeśli podłączysz gotowe rozwiązanie, da się to zrobić w ciągu jednego dnia. Pytanie: „Po co tracić czas i pieniądze na wymyślanie roweru na nowo, skoro na rynku dostępne są podobne oferty?”

Integracja z systemami zewnętrznymi upraszcza i przyspiesza rozwój dowolnej aplikacji:

• Chcesz zorganizować płatności online? Istnieją gotowe rozwiązania od tego samego Stripe, Braintree.
• Czy konieczne jest wskazanie lokalizacji? Mapy Google  pomogą.
• Rejestracja za pośrednictwem sieci społecznościowych? Facebook, Twitter API.

Czasami początkujący PM mylą systemy zewnętrzne z bibliotekami ze względu na brak doświadczenia. Jak mówią w Odessie: „To są dwie duże różnice!” Czym innym jest wzięcie fragmentu kodu i osadzenie go w swoim, a czym innym podłączenie całkowicie niezależnego modułu, który znajduje się na cudzych serwerach. Obie metody są szeroko stosowane w praktyce, należy jednak pamiętać o ich zasadniczych różnicach.

Inną kwestią jest to, że w przypadku korzystania z systemów zewnętrznych istnieje ryzyko, że pojawią się problemy na etapie integracji lub w dalszej pracy. Głównymi powodami tego są: słaba dokumentacja, niestabilna wydajność, piekło w zarządzaniu dostępem lub rozwiązanie jest zbyt drogie.

Powyższe przyprawia o ból głowy nie tylko programistów, ale także project managerów. W przypadku PMów jest to jeszcze trudniejsze, bo to manager będzie musiał tłumaczyć się przed klientem w przypadku wystąpienia siły wyższej. Aby zmniejszyć ryzyko problemów wynikających z integracji z rozwiązaniem firmy trzeciej, ważne jest systematyczne podejście do jego oceny. Należy zacząć od przestudiowania informacji o działaniu systemu zewnętrznego.

Dokumentacja rozwiązań innych firm

Wszelka interakcja pomiędzy modułami odbywa się według określonych algorytmów. Systemy zewnętrzne nie są wyjątkiem. Ich praca powinna być w pełni zgodna z architekturą aplikacji i celami rozwoju. Dlatego ważne jest, aby specyfika rozwiązania strony trzeciej była w pełni i jasno określona w dokumentacji. Ważne jest również, aby wziąć pod uwagę czynnik wygody dla dewelopera.

Oceniając możliwy wybór na korzyść integracji z takim czy innym systemem zewnętrznym, należy zwrócić uwagę na:

1. Czy jest w ogóle dokumentacja i jak dawno temu była aktualizowana. Jeśli jej tam nie ma, zdecydowanie poszukaj innego rozwiązania. Podobna historia z wprowadzaniem zmian w działaniu modułu zewnętrznego i ich naprawianiem. Nie ma sensu tracić czasu na coś, co jest przestarzałe technologicznie.
2. Na jakiej stronie znajduje się dokumentacja i w jakiej formie. Czy informacje są przedstawione w sposób jasny i zrozumiały? Czy jest do niego bezproblemowy dostęp? Czy nie jest to plik txt, ale coś w rodzaju Swagger lub Postman Collections? Można pracować z taką dokumentacją. Lepiej nie brać pod uwagę pliku tekstowego, ponieważ ten format nie jest tak wygodny do studiowania informacji jak inne.

Łatwość czytania, łatwość zrozumienia i terminowe aktualizacje to cechy dobrej dokumentacji. W idealnym przypadku PM może zrozumieć dokumentację, nawet jeśli ma słabe zaplecze techniczne. Sytuacja komplikuje się w przypadku oceny stabilności interakcji aplikacji z usługą strony trzeciej.

Działanie systemu zewnętrznego

Wyobraź sobie sytuację. Rozwiązanie strony trzeciej jest odpowiednie pod każdym względem: spełnia wymagania zadania, cenę itp. Zespół specjalistów już czeka na integrację. Tylko doświadczony programista, który właśnie wrócił z wakacji i postanowił sprawdzić produkt zewnętrzny pod kątem stabilności pracy poprzez stronę statusu.

Badanie przez status page może dać jeden z dwóch wyników: wszystko jest w porządku lub występują awarie. Jeśli wszystko jest w porządku, nie ma już pytań – robimy integrację. W przypadku awarii radzimy pomyśleć o rozwiązaniach zapasowych lub mechanizmach failover (przełączanie awaryjne). Nawiasem mówiąc, dotyczy to również bezpieczeństwa aplikacji. A jeśli do tego doliczymy możliwe problemy w zarządzaniu dostępem, project manager będzie miał kolejny ból głowy.

Zarządzanie dostępem

Wyobraź sobie sytuację: jesteś project managerem i osoba opuszcza zespół. Co przede wszystkim robisz, aby zabezpieczyć projekt i firmę przed możliwym wyciekiem informacji? Zmieniasz dostęp do wszystkich usług, prawda? Dobrze, jeśli masz je uporządkowane, ale w praktyce zazwyczaj jest inaczej:

• Hasła są rozproszone w osobistych wiadomościach pomiędzy specjalistami. Przy dużych projektach wcale nie jest faktem, że niezbędne informacje znajdziesz tylko w swoim zespole. Może również dochodzić do interakcji z innymi specjalistami z firmy i wykonawcami zewnętrznymi.
• Dla wszystkich kont służbowych używana jest jedna poczta. W związku z tym, gdy ktoś odchodzi, należy zmienić dla niej hasło. O tym, że jest to ogromne naruszenie bezpieczeństwa, nie będziemy już mówić.
• Hasła gromadzone są w jednym dokumencie w chmurze, np. Confluence, do którego dostęp mają wszyscy członkowie zespołu. Z jednej strony jest to wygodne, ale częściej takie dokumenty tworzą uporządkowany chaos. Szybkie znalezienie czegoś jest czasem czymś rodem z fantastyki naukowej.
• Usługi stron trzecich są często wykorzystywane do przechowywania informacji, haseł itp. Dla wygody i oszczędności zwykle tworzone jest jedno konto. Wtedy historia jest taka sama jak w przypadku jednego maila dla wszystkich.

Prawdopodobnie możesz kontynuować tę listę przykładami ze swojej praktyki. Pytanie brzmi: co można zrobić z tym chaosem? Oferujemy następujące rozwiązania, które pomogą Tobie, jako PMowi, uporządkować zarządzanie dostępem:

• Utwórz osobne konta dla każdego serwisu i nie udostępniaj ich nikomu. Ważne wiadomości można przesyłać na pocztę. Metoda jest odpowiednia w przypadku pracy z małą liczbą kont.
• Skorzystaj ze specjalnych serwisów, które pomagają przenieść hasło za pomocą jednorazowego linku. Bezpiecznie i wygodnie, szczególnie w przypadku zdalnego zespołu, rozproszonego w różnych lokalizacjach.
• Zapomnij o tworzeniu jednego konta dla wszystkich. Nawet jeśli zdecydujemy się na testową recenzję jakiegoś serwisu, tworzymy osobny dostęp. Założenie jest takie, że 1 konto = 1 osoba. Dzięki temu w prosty sposób możesz zablokować dostęp do dowolnego serwisu lub bazy danych firmy. Podobnie jest z korzystaniem z prywatnej poczty elektronicznej podczas pracy nad projektem. Tworzymy tylko robocze e-maile, które w każdej chwili można zablokować.
• Podłącz specjalne systemy kontroli dostępu. Na przykład: Dashlane, Keeper, RoboForm. Takie podejście sprawdza się w przypadku dużej liczby projektów i uczestników, gdy zarządzanie dostępami staje się dla zespołu trudne.

Prawidłowe zarządzanie kontami i hasłami wpływa nie tylko na szybkość pracy zespołu specjalistów, ale także na bezpieczeństwo projektu w ogóle. Jeśli mówimy o interakcji z serwisami stron trzecich, bałagan i niechlujstwo w tej kwestii może znacząco wpłynąć w szczególności na budżet deweloperski.

Cena i integracja z systemami zewnętrznymi

Za serwis i komfort trzeba płacić. W przypadku podłączenia produktów firm trzecich sytuacja wygląda tak samo. Jeśli nie mówimy o usługach całkowicie bezpłatnych (jest ich wiele, ale nie wszystkie zapewniają niezbędną jakość interakcji), każda płatna ma swój własny rodzaj monetyzacji:

• Warunkowo bezpłatnie, w przypadku taryfy zerowej warunki są takie, że nadaje się tylko do prostych zadań lub testowania usług. W przyszłości konieczne będzie przejście na płatne warunki korzystania z usług lub poszukiwanie innych opcji.
• Płatność za określony czas. Często można zaoszczędzić, jeśli od razu zamówisz usługi na rok lub dłuższy okres.
• Płatność za liczbę połączonych kont. W przypadku tej opcji taryfy są zwykle podzielone na indywidualne, grupowe (dla małych zespołów, projektów) i korporacyjne. W związku z tym cena również jest różna.

Istnieją inne rodzaje monetyzacji, ale te wymienione są najczęstsze. Wybór usług zewnętrznych i taryf zależy od zadań i budżetu projektu. Aby uzyskać dodatkowe oszczędności, rozważ opcje z próbkowaniem (istotne dla systemów analitycznych) lub self-hosted.

W przypadku self-hosted system zewnętrzny (np. Jira) jest wdrażany na własnych obiektach firmy. Jest to zazwyczaj tańsze niż korzystanie z zasobów stron trzecich. Z punktu widzenia stabilności pracy taka decyzja to także plus. Kontrola dostępności usług i rozwiązywanie problemów z infrastrukturą nie jest zależna od Vendora (dostawcy usługi). Jednocześnie PM musi zrozumieć, że bezpieczeństwo projektu w tym przypadku całkowicie „spada” na jego zespół specjalistów. Należy jednak o tym pamiętać na każdym etapie opracowywania, ponieważ kwestie bezpieczeństwa mogą poważnie wpłynąć na terminy i ostateczne wyniki.

Bezpieczeństwo projektu

„Za bezpieczeństwo trzeba płacić i zapłacić za jego brak” – Winston Churchill.

Jeśli Twoja aplikacja ma „dziury” w zabezpieczeniach, prawdopodobieństwo włamania i kradzieży danych jest bliskie 100%. Konsekwencje tego? Co najmniej zaszkodzi to reputacji firmy i doprowadzi do strat finansowych w wyniku odmowy klientom korzystania z zawodnego produktu. Lepiej więc pomyśleć o tym już na samym początku tworzenia i zrobić wszystko dobrze.

Co PM powinien wiedzieć o bezpieczeństwie? Dostępność omawiano przy okazji analizy ewentualnych problemów z ich administracją. Skupmy się teraz na dwóch kluczowych koncepcjach bezpieczeństwa dowolnej aplikacji: haszowaniu i szyfrowaniu. Z fizycznego punktu widzenia pierwsza jest funkcją jednokierunkową (hash function), druga jest funkcją dwukierunkową. Każda ma swoje algorytmy pracy, należy jednak pamiętać o następujących kwestiach: dane podczas transmisji są szyfrowane, hasła w bazie danych są hashowane.

Aby lepiej zrozumieć, dlaczego to wszystko jest potrzebne, przyjrzymy się każdej funkcji osobno.

Haszowanie

Proces wygląda następująco:

1. Istnieje pewna linia, w której można przedstawić dowolny obiekt: tekst, grę, obraz itp.
2. Przekazujemy go do hash function.
3. Na wyjściu otrzymujemy niewielki ciąg znaków o ustalonym rozmiarze – hash, który zapisujemy w bazie danych (BD). Odwrotna konwersja nie jest możliwa.

Uzyskane w ten sposób informacje zajmują niewiele miejsca w BD, co przy dużych projektach czasami ma kluczowe znaczenie. Ważne jest również, aby hash tego samego ciągu był zawsze taki sam, niezależnie od tego, ile razy nastąpi konwersja. Głównym powodem wykorzystywania zahaszowanych danych w tworzeniu aplikacji jest to, że trudno je złamać. Tak, istnieją tzw. „tęczowe tablice” z dużą liczbą wszelkiego rodzaju hashów, ale w praktyce ich użycie jest mało efektywne.

Rozważmy na przykład klasyczny schemat. Podczas rejestracji użytkownik utworzył hasło, które system zapisał w bazie danych. Będzie tam przechowywany w formie hash. Następnym razem, gdy użytkownik wprowadzi swoje hasło, zostanie ono ponownie zaszyfrowane przy użyciu hash function. Następnie otrzymany hash jest porównywany z tym, co znajduje się w bazie danych. Jeśli się zgadzają, wszystko jest w porządku.

Haszowanie jest darem niebios w pracy z bazami danych. Bezpiecznie, ekonomicznie i szybko. Prawie jak szyfrowanie, ale tylko w jedną stronę. Jest to główna różnica między tymi dwoma procesami.

Szyfrowanie

Szyfrowanie można przedstawić w postaci takiego łańcucha działań:

1. Dane wyjściowe są szyfrowane przy użyciu specjalnych algorytmów.
2. Szyfr jest wysyłany zgodnie z przeznaczeniem.
3. Na wyjściu dane są odszyfrowywane i odczytywane.

Cały pomysł jest taki, że do odczytania informacji źródłowych potrzebny jest specjalny klucz. Powstaje w procesie szyfrowania przy użyciu algorytmu: symetrycznego lub asymetrycznego. Obie opcje są używane podczas pracy z aplikacjami, ale algorytm asymetryczny jest uważany za bardziej niezawodny.

W przypadku algorytmu symetrycznego do odszyfrowania i deszyfrowania potrzebny jest tylko jeden klucz. Głównym problemem w tym procesie jest bezpieczne przekazanie zarówno informacji, jak i klucza do niej. „Przechwycenie” wszystkich części może nastąpić w dowolnym momencie. W algorytmie asymetrycznym jest to bardziej niezawodne: do szyfrowania i deszyfrowania tworzone są osobne klucze. Na przykład https i ssl działają według tego schematu. Zdobycie cudzych danych jest w tym przypadku znacznie trudniejsze niż w pierwszym wariancie.

Dla maksymalnego bezpieczeństwa projektu należy koniecznie stosować haszowanie danych, a przy ich transmisji stosować algorytm szyfrowania asymetrycznego.

Kilka przydatnych wskazówek:

• Zapomnij o tworzeniu użytkowników o nazwie admin i haśle password (lub podobnym). Może to być fatalne dla Twojego projektu, ponieważ prawdopodobieństwo włamania przy takim podejściu jest wielokrotnie wyższe niż w przypadku innych opcji.
• Pozwól na integrację systemów monitorujących z projektem, aby zrozumieć, co dzieje się w aplikacji. Szybka reakcja na nietypową sytuację często zapobiega poważnym problemom w przyszłości.
• Jeśli Twój projekt się rozrośnie, koniecznie wypróbuj rozwiązania zabezpieczające oparte na chmurze, takie jak AWS Shield. Mogą nie tylko poprawić bezpieczeństwo, ale także ułatwić życie project managerom.

Najważniejszą rzeczą, o której powinien pamiętać każdy PM, jest to, aby nie wkładać znalezionych pendrive’ów do komputera służbowego lub osobistego i nie „wdawać się” w phishing! Można być bardzo fajnym specjalistą z nierealnym doświadczeniem, ale nikt nie jest odporny na zmęczenie umysłu. Dlatego zawsze uważaj, aby nie powiedzieć: „Jak to w ogóle możliwe? Ale ja nigdy! No nie!”

Zamiast wniosku

– Kiedy będziemy wiedzieć dokładnie, ile czasu zajmie projekt?

– Kiedy to skończymy!

Proza życia. Aby projekt zakończył się happy endem, PM musi zdecydowanie:

• Rozumieć, czym jest software architecture.
• Wiedzieć, jak prawidłowo wybrać systemy zewnętrzne do integracji.
• Pamiętać o bezpieczeństwie.

Jest to dodatek do jego innych obowiązków: analizy projektu i planowania pracy, tworzenia zespołu specjalistów, „wyłapywania” zdarzeń siły wyższej itp. Jednak im więcej umiejętności i ich wyższa jakość, tym rośnie koszt usług takiego specjalisty. Jest nad czym pomyśleć!

Jeśli chcesz „dostarczyć” projekty dokładnie na czas i zapomnieć o poprawkach, przyjdź i naucz się na kursie ArchiTech. To nie jest tylko kurs architektury i zarządzania zespołem technicznym dla managerów, ale szczegółowy program dotyczący terminowej i jakościowej realizacji złożonych projektów IT dla wszystkich PM, BA i Product poziomu Middle i wyższego!