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

— 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

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

Mikroserwisy

Serverless

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

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.

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ę

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.