Jak architektura projektu IT wpływa na pracę Project Managera

2 lutego 2024

  • Autor: Aleksander Kononenko

  • Złożoność: normalna

  • Czas: 6 min

— Czy jesteś pewien, że wybrano odpowiednią architekturę projektu IT?

— Tak, biorąc pod uwagę cele biznesowe Klienta oraz wyznaczone przez niego terminy realizacji projektu i budżet.

– Pomyślmy jeszcze raz. Potrzebujemy maksymalnej optymalizacji czasu i zasobów na realizację, a także ograniczenie ryzyka do minimum.

To jest przykład dialogu pomiędzy Solution Architect a PMem, który ma techniczną wiedzę na temat projektu. Następnie omawiają oni kluczowe aspekty architektury przyszłej aplikacji, porównują różne opcje, aby znaleźć najlepsze rozwiązanie. O tym, dlaczego jest to ważne i jaka jest rola menedżera projektu w tym procesie, opowiemy więcej w artykule. Zacznijmy od podstaw – czym jest software architecture i dlaczego jest ważna.

Rola architektury w IT

Wyobraź sobie, że stoisz przed zadaniem budowy domu. Można go wykonać w dowolnym stylu i z różnych materiałów, ale będzie on oparty na określonym rozwiązaniu architektonicznym. To właśnie dyktuje, jakich technologii użyć, w jaki sposób i w jakiej kolejności wykonywać określone prace. To samo dzieje się w rozwoju rozwiązań IT, dostosowanych do specyfiki branży. Jednocześnie związek pomiędzy architekturą a realizacją projektu można prześledzić na wszystkich etapach: od oceny do wydania i późniejszego wsparcia technicznego.

Software architecture pomaga:

  • określić podstawową strukturę aplikacji, elementy pierwotne i wtórne;
  • zbudować logikę interakcji pomiędzy różnymi komponentami architektury projektu;
  • brać pod uwagę ryzyko, znajdować sposoby zapobiegania problemom technicznym podczas procesu tworzenia i działania gotowego oprogramowania;
  • rozważyć bezpieczeństwo i potencjalną skalowalność projektu;
  • stworzyć ujednolicony system komfortowej pracy zespołowej;
  • oszacować czas, koszt i etapy rozwoju.

Lista jest długa, ale najważniejsze jest to, że software architecture określa, w jaki sposób „piszesz” aplikację, jak ona działa i jaki jest potencjał rozszerzenia funkcjonalności w przyszłości. Od tego w dużej mierze zależy proces rozwoju i zarządzania projektem IT w ogóle, a w szczególności wpływ architektury na rolę menedżera.

Rodzaje software architecture

Jak architektura projektu IT wpływa na pracę Project Managera

Podstawą każdej aplikacji są różne elementy architektury projektowej połączone w jedną całość. Kolejną kwestią jest to, w jaki sposób wszystkie systemy, moduły i interfejsy są ze sobą połączone oraz jaka jest struktura ich interakcji. Zależy to w dużej mierze od rodzaju architektonicznego rozwiązania IT:

  • monolit – oparty na blokach funkcjonalnych, które znajdują się w tej samej bazie kodu i są od siebie zależne;
  • mikroserwisy – opierają się na poszczególnych modułach, które współdziałają ze sobą według określonego algorytmu i tworzą wspólny system;
  • serverless – alternatywna opcja mikroserwisów, która koncentruje się na maksymalnym wykorzystaniu technologii chmurowych, dzięki czemu automatyzuje całe wdrożenie.

Przyjrzymy się głównym zaletom i wadom każdego typu software architecture.

Monolit

Jak architektura projektu IT wpływa na pracę Project Managera

 

Zalety

Wady

Łatwy do otwarcia. Ponieważ monolit ma zasadniczo tylko jeden punkt wejścia, wdrożenie jest bardzo szybkie i stosunkowo proste.

 

Tworzenie. Zwykle robi się to szybko – wszystkie komponenty i moduły zawarte są w jednej bazie kodu i są zawsze pod ręką, co pozwala zaoszczędzić czas.

 

Debugowanie. Jest to znacznie uproszczone, ponieważ wszystkie elementy znajdują się w pobliżu, można śledzić wszystkie połączenia z wykonaniem kodu.

Skalowanie. Całość można jedynie rozbudować – jeśli obciążenie wzrośnie na jednym module, trzeba przeskalować cały monolit.

 

Niezawodność i słabe punkty projektu IT. Jeśli jedno się nie powiedzie, wszystkie moduły zawiodą na raz.

 

Zmiana i unowocześnienie technologii. Bardzo trudne!

 

Elastyczność. Monolit jest sztywny – zmiana jednego modułu prawie zawsze wpływa na inne.

Mikroserwisy

Jak architektura projektu IT wpływa na pracę Project Managera

 

Zalety

Wady

Elastyczność. Każda usługa jest odrębnym systemem i wszelkie zmiany w niej zachodzące nie wpływają na inne części architektury, chyba że jest to konieczne.

 

Skalowanie. Można skalować każdy moduł indywidualnie.

 

Elastyczność technologii. Każdy podsystem można zaimplementować na swój własny sposób, inny niż pozostałe.

 

Niezawodność i bezpieczeństwo projektu IT. Prosta awaria podsystemu rzadko powoduje wyłączenie całego systemu.

Proces tworzenia. Zwykle wymaga to więcej czasu i zasobów niż w przypadku pracy ze strukturą monolityczną, ponieważ konieczne jest wdrożenie i ustalenie interakcji kilku podsystemów.

 

Debugowanie. Procesy są bardziej skomplikowane niż w monolicie – konieczne jest ustalenie uszkodzonej usługi i przyczyn jej awarii.

 

Rozlokowanie. Każde dodanie nowej usługi wymaga konfiguracji głównych części projektu IT.

Serverless

Jak architektura projektu IT wpływa na pracę Project Managera

 

Zalety

Wady

Elastyczność. Duża ze względu na izolację modułów od siebie.

 

Chmura automatycznie decyduje, który system operacyjny i ustawienia są potrzebne.

 

Łatwy próg wejścia. Zazwyczaj serverless ma oddzielny, prosty kod, który specjalista może łatwo i szybko zrozumieć.

 

Niezawodność. Porównywalne do struktury mikroserwera, jeśli projekt jest poprawnie zbudowany.

Elastyczność. Jednocześnie plus i minus. Wadą jest to, że skalowanie zależy od możliwości i ustawień usługi chmurowej.

 

Debugowanie. Skomplikowane ze względu na interakcję pomiędzy oddzielnymi komponentami.

 

Zależność od serwisu. Każda Chmura ma swój własny algorytm działania, więc bezbolesne przejście z jednej „chmury” do drugiej jest trudne do zrealizowania w praktyce.

 

Kaskadowa awaria. Jeżeli konstrukcja i konfiguracja poszczególnych modułów jest nieprawidłowa, mogą one wzajemnie na siebie oddziaływać, co niesie ze sobą potencjalne ryzyko awarii całego systemu.

Powyższe wyraźnie pokazuje wpływ software architecture  na rozwój produktów IT. Ważne jest również, aby zrozumieć, że w przypadku urządzeń mobile, web i desktop każdy typ architektury będzie miał swoją specyfikę. Dlatego ważne jest, aby początkowo wziąć pod uwagę wszystkie aspekty: funkcjonalność i bezpieczeństwo projektu, skalowalność i inne aspekty. W tej sprawie na pierwszy plan wysuwa się rola PM.

Rola menedżera projektu w architekturze produktów IT

W idealnym projekcie, menedżer ma w swoim zespole Solution Architecta, który przeanalizuję architekturę aplikacji. Aby to zrobić, potrzebny jest przynajmniej pomysł i podstawowa specyfikacja techniczna. Specyfikacje techniczną podaje najczęściej Business Analyst lub Project Manager. Następnie zachodzi proces wyboru rozwiązania architektonicznego, biorąc pod uwagę:

  • dane o celach biznesowych i potrzebach klientów;
  • aktualne zasoby: poziom specjalistów, pożądane terminy, przydzielony budżet;
  • zarządzanie ryzykiem i tak dalej.

W takim przypadku menedżer może w ogóle nie uczestniczyć w procesie, a jedynie monitorować wynik z późniejszą oceną i zarządzaniem projektem zgodnie z wybraną architekturą. W praktyce często zdarza się, że projekt nie posiada SA ani nawet BA – w tym przypadku wszystko ląduje na barkach Project Managera.

W tym przypadku rozwój software architecture realizowany jest przez Project Managera samodzielnie, jeśli pozwalają na to umiejętności techniczne, lub z jednym z programistów – dzieje się tak w przypadku, gdy zarządzanie projektem z wiedzą techniczną na temat architektury jest łatwiejsze niż bez niej. Jednak w komunikacji z Solution Architectem takie umiejętności będą również plusem dla menedżera.

Korzyści ze zrozumienia technicznej strony projektu

Jak architektura projektu IT wpływa na pracę Project Managera

Prawidłowo skonfigurowana komunikacja i ustalone procesy to jeden z najważniejszych aspektów udanej pracy zespołowej. Zrozumienie, czym jest software architecture, znajomość terminów i procesu tworzenia oraz niezbędne umiejętności techniczne pomagają menedżerom projektów:

  • znaleźć „wspólny język” z programistami – skraca to czas podejmowania decyzji i eliminuje ewentualne problemy;
  • poprawnie oszacować czas i budżet projektu, uwzględniający rozwój software architecture i refactoring – zawsze możliwe są uzupełnienia do bieżących celów biznesowych, zmiany w aplikacji i nie tylko;
  • lepiej planować obciążenie zespołu, opisywać zadania i kontrolować ich realizację – upraszcza to zarządzanie ryzykiem i projektem jako całością, zmniejsza procent długu technicznego i występowanie problemów w dłuższej perspektywie;
  • szybko i łatwo przedstawiać klientowi informacje od specjalistów, bronić własnych propozycji dotyczących harmonogramu i ceny – zarząd z pewnością to doceni;
  • poprawnie prowadzić dokumentację i jasno opisywać funkcjonalności, co uprości dalsze utrzymanie aplikacji i wprowadzanie zmian – takie podejście znacząco optymalizuje ogólną pracę nad projektem.

Oprócz powyższej wiedzy, software architecture pozwala menedżerowi znaleźć i zaproponować zespołowi wraz z klientem najlepsze opcje. Jednocześnie należy wziąć pod uwagę różne czynniki i ryzyka: od bezpieczeństwa do potencjalnego rozwoju projektu.

ArchiTech

Przykłady wpływu wyboru architektury na losy projektów

Na początku rozwoju jedna firma dokonała złego wyboru architektury do skalowania aplikacji – nie wzięła pod uwagę możliwości szybkiej zmiany funkcjonalności w celu dostosowania do różnych żądań użytkowników. W rezultacie musieli właściwie stworzyć nową wersję produktu od podstaw, ze wszystkimi tego konsekwencjami. Doświadczony PM z pewnością poradziłby klientowi i zespołowi, aby przyjrzeli się skalowalności.

Inny przykład dotyczy identyfikacji potencjalnych podatności i prawidłowego doboru rozwiązań architektury bezpieczeństwa. Klient zamówił aplikację biznesową zbierającą zaawansowane dane użytkowników. Ponieważ jest to potencjalny czynnik ryzyka, RM zasugerował klientowi wzmocnienie ochrony i przeznaczenie na to dodatkowego budżetu. Ze względu na niepewność w kwestiach technicznych i słabą komunikację Project Manager nie był w stanie uzyskać zgody klienta. W efekcie już po wydaniu, aplikacja została szybko zhakowana, a dane użytkowników skradzione. Z jednej strony nie jest to wina menadżera, ale gdyby miał hard i soft skills, negocjacje z klientem mogłyby zakończyć się inaczej.

Bonus: Jak dyskutować i recenzować architekturę

Jak architektura projektu IT wpływa na pracę Project Managera

W celu konstruktywnej dyskusji na temat software architecture z architektem lub programistami zalecamy zapoznanie się z książką WAF – Well-Architected Framework firmy Amazon. Tutaj znajdziesz aktualne rekomendacje dotyczące oceny produktów IT. Krótko mówiąc, WAF proponuje ocenę projektu w oparciu o pięć kategorii wymagań niefunkcjonalnych:

  1. Operational Excellence.
  2. Security.
  3. Reliability.
  4. Performance Efficiency.
  5. Cost Optimization.  

Jeśli wszystkie powyższe zostaną spełnione, z prawdopodobieństwem 99,9% architektura projektu zostanie opracowana poprawnie.

Aleksander Kononenko

Marketingowy copywriter z wykształceniem technicznym oraz doświadczeniem w sprzedaży i marketingu. Zawsze poszukuje najlepszych rozwiązań do osiągnięcia swoich celów i uważa, że tworzenie tekstów to symbioza sztuki i nauki.