Zapraszam Cię bardzo serdecznie do obejrzenia filmu, w którym omawiam projektowanie architektury rozwiązania IT:

A jeśli lepiej przyswajasz tekst, poniżej znajdziesz transkrypcję wystąpienia.

Architektura IT – od której zacząć?

Podczas prezentacji opowiemy sobie jak projektować architekturę IT. Szczegółowo porozmawiamy o procesie projektowania architektury IT, omówimy jakie są kroki, na czym polegają, dodatkowo wykorzystamy notację UML w celu dokumentowania naszej pracy architektonicznej.

Poznaj głównych aktorów Janka oraz Marcina, którzy będą uczestniczyli w naszej rozmowie na temat procesu projektowania architektury IT. Janek jest Klientem a Marcin Architektem IT.

Na pierwszym spotkaniu Janka oraz Marcina, Janek pyta „Na kiedy będzie gotowe?”.

Wtedy Marcin zdaje sobie sprawę, że musi natychmiast przystąpić do działania.

Marcin zastanawia się od czego zacząć, czy od architektury technicznej, czy od architektury integracji. Na pewno będziemy musieli zbudować integrację pomiędzy systemami, więc już warto teraz zdecydować się na podejście REST a może o protokół SOAP, a może warto zacząć od architektury infrastruktury, musimy przecież określić czy nasze rozwiązanie będzie oparte o Cloud, czy może o nasze własne serwery. Pewnie się domyślasz, że Marcin nie może jeszcze rozpocząć pracy nad rozwiązaniem.

Jaki masz problem?

Po dyskusji z bardziej doświadczonymi kolegami, Marcin wraca do Janka i pyta: „Janku, jaki masz problem?”. Raczej to pytanie tak zadane nie brzmi dobrze, ale właśnie od tego musimy rozpocząć.

Przed rozpoczęciem pracy nad projektowaniem rozwiązania musimy ustalić i zrozumieć jaki jest problem biznesowy lub jaka jest potrzeba biznesowa. Bez tych informacji, narażamy się na ogromne ryzyko, że rozwiązanie, nad którym pracujemy, które budujemy razem z zespołem, nie będzie odpowiadało na realne problemy lub potrzeby klienta. Dlatego Marcin musi uważnie wysłuchać i zrozumieć Janka.

W naszym projekcie Janek chciałby narzędzia wspierającego wyszukanie posiłków online na podstawie wybranych składników. Dodatkowo narzędzie musi dostarczać rekomendacji posiłków i umożliwiać prognozowanie cen posiłków. Mając takie informacje możemy przystąpić do pracy.

Jeszcze mała uwaga. Bardzo dobrą praktyką jest wprowadzenie słownika pojęć już na samym początku. Taki słownik ułatwi nam w przyszłości komunikację z innymi członkami naszego zespołu.

Po określeniu problemu biznesowego lub potrzeby biznesowej przechodzimy do kolejnego kroku, który polega na zebraniu oraz udokumentowaniu wymagań funkcjonalnych oraz niefunkcjonalnych.

Czym są wymagania funkcjonalne, a czym wymagania niefunkcjonalne?

Wymaganie funkcjonalne definiuje zachowanie, które musi realizować nasze rozwiązanie, natomiast wymaganie niefunkcjonalne jest parametrem jakościowym rozwiązania. Przykładem wymagania funkcjonalnego jest możliwość skomponowania posiłku czy wyszukanie posiłku a niefunkcjonalnym czas odpowiedzi systemu czy dostępność.

Następnie podczas warsztatów Zespół spotyka się z Jankiem w celu uszczegółowienia wymagań.

Janek wyjaśnia, że system musi umożliwiać skomponowanie posiłków na podstawie składników, musi umożliwiać wyszukanie posiłków czy wyznaczenie rekomendacji dań. Są to przykłady wymagań funkcjonalnych.

Janek podczas warsztatów dodaje również, że system musi być dostępny przez 95% czasu, a dane muszą być przechowywane przez okres 5 lat. Są to przykłady wymagań niefunkcjonalnych. W tym momencie szczególną uwagę musimy zwrócić na kwestie związane z wysoką dostępnością oraz niezawodnością. SLA na poziomie 95%, oznacza, że rozwiązanie jest niedostępne przez 36 godzin w miesiącu czy 18 dni w roku.

Po warsztatach dokumentujemy wymagania. Zarówno wymagania funkcjonalne jak i wymagania niefunkcjonalne.

Wymagania możemy również udokumentować z wykorzystaniem diagramu wymagań.

Dobrą praktyką jest określenie priorytetów wymagań. Priorytety możemy później wykorzystać w planowaniu dostarczenia rozwiązania na przykład, gdy chcemy rozwiązanie fazować. W kolejnym kroku przystępujemy zatem do analizy szczegółowej wymagań. Na temat procesów biznesowych oraz przypadków użycia porozmawiamy za chwilę.

Czym jest proces biznesowy?

Proces biznesowy stanowi listę aktywności, inicjowaną zdarzeniem, która na podstawie otrzymanych na wejściu informacji z wykorzystaniem dostępnych zasobów, przekształca je w wartość dla Klienta na wyjściu.

Po analizie wymagań jesteśmy w stanie zidentyfikować procesy biznesowe, wymagające utworzenia, modyfikacji lub usunięcia. W naszym rozwiązaniu możemy wyróżnić proces skomponowania oraz wyszukania posiłku, czy proces wyznaczenia rekomendowanych dań. Procesy biznesowe możemy zamodelować na wiele sposobów. Na przykład z wykorzystaniem diagramów aktywności notacji UML, czy z wykorzystaniem notacji BPMN.

Zwróć proszę uwagę na przykład procesu biznesowego jaki jest na tym etapie. Jest on bardzo ogólny i taki powinien być.

W następnym kroku zdefiniujemy przypadki użycia.

Czym jest przypadek użycia?

W skrócie opisuje interakcję pomiędzy aktorem (aktorami) oraz systemem. W naszym projekcie przypadkami użycia są skomponowanie posiłku, wyszukanie posiłku czy opłacenie posiłku. Przypadki użycia zamodelujemy z wykorzystaniem języka UML oraz diagramów przypadków użycia.

Przypadki użycia dobrze dokumentują wymagania. Określają aktorów, warunki wywołania, rezultat wywołania, dane wejściowe, wyjściowe oraz przede wszystkich scenariusz główny i scenariusz alternatywny. Tutaj widzimy przykład przypadku użycia Skomponowanie posiłku.

Chciałbym, abyś na to zwrócił uwagę. Wolumetria jest niestety bardzo często zapominana albo pomijana. Tak przygotowana wolumetria umożliwi nam oszacowanie infrastruktury rozwiązania.

Po określeniu problemu biznesowego oraz analizie wymagań funkcjonalnych i niefunkcjonalnych, zamodelowaniu procesów biznesowych, udokumentowaniu przypadków użycia, możemy przystąpić do opracowania wizji architektonicznej.

Opracowanie wizji architektonicznej

Wizja architektoniczna przedstawia zwięzły opis architektury docelowej rozwiązania wraz z wartościami dla organizacji, które wynikną z jej wprowadzenia. Warto dodać, że jest wysokopoziomowym opisem komponentów lub aplikacji, ich relacji oraz zachowania. Podczas pracy nad wizją architektoniczną musimy zwrócić uwagę na architektury referencyjne, zasady architektoniczne czy wzorce architektoniczne.

Architektury referencyjne dostarczane są między innymi przez największych dostawców IT, umożliwiają szybkie opracowanie architektury.

Wzorce architektoniczne są natomiast sprawdzonymi sposobami rozwiązania określonego problemu architektonicznego. W dużych organizacjach popularna jest cały czas architektura SOA, ESB czy monolityczna, natomiast coraz częściej wykorzystywane są architektury mikrousługowe czy zorientowane na zdarzenia.

Zasady architektoniczne są natomiast wytycznymi, którymi powinniśmy kierować się podczas projektowania. Bardzo popularną zasadą jest użyj ponownie przed kupnem, kup przed zbudowaniem. Jest to zasada promująca w pierwszej kolejności reużycie istniejącego rozwiązania, następnie kupno produktu, a na końcu budowa nowego.

Przy projektowaniu wizji architektonicznej powinniśmy rozważyć różne opcje/warianty dla kluczowych kryteriów.

My porównaliśmy 2 opcje. Opcja 1 polega na kupnie produktu Salesforce oraz opcja 2 na budowie własnego rozwiązania o architekturze mikrousługowej z wykorzystaniem chmury publicznej AWS. Porównując obie opcje ze względu na kryteria takie jak architektura, kompetencje zespołu, czas dostarczenia, utrzymanie czy koszty, przygotowaliśmy rekomendacje. Przedstawiamy swoją rekomendację Jankowi, czyli wybór opcji 2, którą Janek również popiera.

Architektura docelowa naszego rozwiązania zostanie zatem zbudowana z mikroserwisów odpowiedzialnych za zarządzanie restauracją, zamówieniami, płatnościami, użytkownikami, rekomendacjami oraz prognozowaniem. W rozwiązaniu wprowadzimy również interfejs użytkownika oraz narzędzie analityczne wraz z hurtownią danych.

Następnie Marcin rozmawia z Jankiem na temat możliwości fazowania projektu. Wspólnie podejmują decyzję, że fazowanie nastąpi względem priorytetów wymagań. W związku z tym rozwiązanie zostanie dostarczone w 2 fazach – Faza 1 (MVP) oraz Faza 2 (Docelowa rozwiązania).

Przechodzimy następnie do przygotowania architektury biznesowej dla rozwiązania dla Fazy 1 MVP.

Architektura biznesowa dla fazy MVP

Architektura biznesowa umożliwia nam przedstawienie uszczegółowionego sposobu realizacji procesów biznesowych z perspektywy rozwiązania. Uwzględnia również strukturę organizacyjną, relacje pomiędzy aktorami, strategię oraz politykę firmy. Wykorzystamy diagramy sekwencji notacji UML w celu zaprezentowania architektury biznesowej. Przykładowy proces przeglądania szczegółów zamówienia przedstawiony jest na aktualnym slajdzie. W kolejnym kroku przystępujemy do pracą nad architekturą danych.

Architektura danych dla fazy MVP

Architektura danych polega na przedstawieniu struktury encji oraz powiązań pomiędzy nimi, umożliwia również uszczegółowienie zakresu oraz formatu danych z architektury biznesowej.

Model danych dla Fazy 1 zawiera encje Użytkownika czy Zamówienia. Zamówienie zawiera numer zamówienia czy datę rejestracji zamówienia.

Następnie przystępujemy do pracy nad architekturą aplikacji.

Architektura aplikacji dla fazy MVP

Architektura aplikacji określana jest również jako architektura statyczna, a przedstawia komponenty (aplikacje) oraz ich powiązania (integracje). Wykorzystamy diagramy komponentów notacji UML w celu przedstawienia architektury aplikacji.

Przykładowo komponent Restauracja mikroserwis zbudowany jest z Restauracja API, Restauracja serwis oraz Baza restauracji.

Restauracja serwis komunikuje się z aplikacją zewnętrzną, którą jest Restauracja, z Restauracją API oraz z Bazą restauracji. Na diagramie przedstawione są przykładowe integracje takie jak pobranie danych o restauracji czy wyszukanie posiłków.

Restauracja serwis realizuje również funkcje takie jak pobranie danych o restauracji, daniach oraz składnikach, która oznaczona jest jako Funkcja 1, czy funkcja wyszukania posiłku oznaczona jako Funkcja 3.

Podczas pracy nad komponentem bazą restauracji opracowaliśmy model fizyczny, który powstał na podstawie modelu przygotowanego w ramach architektury danych. Przedstawiony model fizyczny związany jest z bazą restauracji oraz ograniczony jest tylko do domeny restauracji. Zawiera również techniczne pola takie jak klucze prywatne czy pola ważne od, ważne do.

W kolejnym kroku opracujemy architekturę integracji.

Architektura integracji dla fazy MVP

Celem architektury integracji jest zidentyfikowanie oraz przygotowanie specyfikacji interfejsów dla rozwiązania. Podczas pracą nad architekturą integracji musimy zwrócić uwagę na typy integracji, czy jest to integracja online czy offline, protokoły integracyjne, czy jest to na przykład protokół HTTPS, JDBC, wzorce integracyjne na przykład wzorzec request-response. Musimy wziąć pod uwagę powyższe kryteria podczas projektowania integracji. Architekturę integracji możemy przedstawić na diagramach komponentów.

Diagramy przypadków użycia wykorzystamy do przedstawienia integracyjnych przypadków użycia.

Na diagramach sekwencji w celu przedstawienia przepływy, typu integracji, czy jest to integracja synchroniczna, asynchroniczna, czy na diagramie klas w celu zaprezentowania modelu danych wykorzystanego w komunikacji.

Kolejnym krokiem po opracowaniu architektury biznesowej, danych, aplikacji, integracji jest praca nad architekturą techniczną rozwiązania.

Architektura techniczna dla fazy MVP

W naszym rozwiązaniu wykorzystamy usługi chmury publicznej AWS, takie jak API Gateway, Lambda oraz Aurora. Wykorzystamy również usługi wspierające, które nie są tutaj zaprezentowane takie jak CloudWatch, IAM i inne.

Przykładowo komponent Restauracja mikroserwis zostanie zaimplementowany z wykorzystaniem serwisu API Gateway, który odpowiada za realizację komponentu Restauracja API, serwisu Lambda odpowiadającego za realizację Restauracja serwis oraz serwisu Aurora, realizującego bazę restauracji.

W kolejnym kroku opracujemy architekturę infrastruktury.

Architektura infrastruktury dla fazy MVP

W naszym rozwiązaniu zaprojektujemy prywatną sieć VPC, w której zostaną umieszczone bazy restauracji, zamówień. W sieci publicznej umieścimy NAT Gateway. Szczegóły zmian od strony infrastruktury przedstawiamy podczas opracowania architektury infrastruktury.

Kolejnym etapem jest opracowanie architektury bezpieczeństwa.

Architektura bezpieczeństwa dla fazy MVP

Podczas prac nad architekturą bezpieczeństwa musimy zwrócić uwagę na takie rzeczy jak zakres odpowiedzialności, czyli za co odpowiada dostawca chmury publicznej, a za co odpowiedzialni jesteśmy my. Dodatkowo należy zwrócić uwagę na mechanizm uwierzytelniania użytkowników biznesowych czy administratorów. Należy zwrócić uwagę na mechanizm autoryzacji komponentów (aplikacji), jak są zabezpieczone dane uwierzytelniania? jak zostanie zrealizowane szyfrowanie danych, kopia zapasowa czy monitoring aplikacji? Na te wszystkie pytania musimy odpowiedzieć sobie podczas pracy nad architekturą bezpieczeństwa.

Przechodzimy teraz do architektury wdrożenia.

Architektura wdrożenia dla fazy MVP

W naszym rozwiązaniu wykorzystamy region Irlandia. W projekcie zostaną również wykorzystane narzędzia CI/CD zapewniające automatyzację wdrożenia oraz testów. W celu budowy środowisk wykorzystamy serwisy CloudFormation oraz SAM. Zbudujemy w sumie 6 środowisk. Przechodzimy do kolejnego kroku, którym jest weryfikacja architektury.

Weryfikacja architektury MVP

Będzie ona polegała na przeprowadzeniu testów funkcjonalnych oraz niefunkcjonalnych. Podczas weryfikacji architektury zwrócimy szczególną uwagę na testy polityki dostępów oraz ról IAM przydzielonych do zasobów.

Następnie przechodzimy do pracy nad fazą 2.

Przygotowanie rozwiązania dla fazy docelowej

Na diagramie komponentów, kolorem niebieskim przedstawione są komponenty, które zostaną zmodyfikowane w fazie 2, gdyż zostały wprowadzone w fazie 1. Kolorem zielonym przedstawione są komponenty nowe, a na czarno, które nie uległy zmianie.

Ponownie rozpoczynamy od architektury biznesowej, następnie przechodzimy do określenia zmian w architekturze danych.

Kolejnym krokiem jest praca nad architekturą aplikacji. Następnie nad architekturą integracji. Wprowadzamy odpowiednie zmiany w modelu danych przygotowanym w architekturze integracji.

Przechodzimy do opracowania architektury technicznej.

Kolejnym krokiem jest ponownie architektura infrastruktury, architektura bezpieczeństwa, architektura wdrożenia oraz na końcu następuje weryfikacja architektury.

Gdybyś chciał podzielić się ze mną swoim komentarzem napisz do mnie na marcin@marcinziemek.com

Jeśli chcesz rozwinąć swoją wiedzę z zakresu projektowania architektury IT, sprawdź też moją książkę dostępną pod adresem: https://architektura.marcinziemek.com