Tworząc wycenę nowej aplikacji czy przystępując do pierwszych prac projektowych, na samym początku zespół musi zrozumieć zakres projektu. Na dziesiątkach spotkań, staramy się dookreślić wymagania, wybrać technologię, identyfikując tym samym obszary niebezpieczne. Wykluwa się wówczas wstępny zarys architektury aplikacji, a decyzje podjęte na tym etapie, mogą rzutować na koszty realizacji i zmian tych decyzji w przyszłości.

Ostatnio wpadła mi w ręce ciekawa książka Simona Browna zatytułowana „Software Architecture for Developers”. Książka ta, w bardzo przyjemny sposób, przybliża nam, czym jest architektura, wyjaśnia znaczenie architektury w tworzeniu oprogramowania oraz przybliża nam rolę architekta w zespole. Jednak autor pierwszy rozdział poświęca tzw. driverom architektonicznym. Czym są i w jaki sposób mogą one pomóc na etapie wyceny bądź w pierwszych decyzjach nowo tworzonej aplikacji?

Architektura

W dużym uogólnieniu architektura odnosi się do wszystkiego, co dotyczy procesu tworzenia oprogramowania, od struktury kodu, aż po wysokopoziomowe procesy biznesowe, poprzez infrastrukturę, na jakiej działać ma oprogramowanie. Dotyczy niemal wszystkiego, co wiąże się z tworzeniem oprogramowania. Architektura oprogramowania wiąże się więc z podjęciem najważniejszych decyzji projektowych, gdzie znaczenie jest mierzone przez koszt wprowadzenia zmian. Im ważniejsza więc decyzja, tym większe koszty późniejszych zmian.

Architektura zapewnia:

• jasną wizję produktu oraz roadmapa dla całego zespołu
• stymuluje do rozmów (zarówno wewnątrz jak i na zewnątrz zespołu)
• wprowadza framework do zarządzania ryzykiem
• styleguide oraz kosekswencja w podejściu do rozwiązania problemów i strukturze kodu
• strukturę różnych warstw abstrakcji i komunikacji między nimi

Dużo szerzej ten temat opisany jest w ww. książce, jednak jak widać, korzyści ze stosowania architektury są namacalne.
Zatem jak się do tego wszystkiego zabrać?

Drivery architektoniczne

Simon wskazuje, że kluczowym elementem jest zadanie odpowiednich pytań, przed napisaniem pierwszej linijki kodu. Drivery architektoniczne (architectural drivers), bo o nich tutaj mowa, to zbiór wymagań mających kluczowe znaczenie na architekturę aplikacji. Ich odkrycia możemy dokonać, poprzez zadawanie odpowiednich pytań, dotykających następujących tematów:

• Wymagania funkcjonalne – czyli określenie zakresu MVP (minimum viable product), wysokopoziomowa lista funkcjonalności jaka musi znaleźć się programie
• Wymagania jakościowe (niefunkcjonalne):
  • wydajność (czas odpowiedzi, opóźnienia)
  • skalowalność (w jaki sposób system ma sobie radzić z większą ilością użytkowników, zapytań, danych)
  • dostępność (np. uptime 99,9% oznacza max. 1 minutę dziennie na prace konserwacyjne i nieoczekiwane błędy)
  • bezpieczeństwo (od autentykacji i autoryzacji, przez poufność przesyłanych danych aż po storage)
  • prywatność (GDPR, prawo do zmiany danych, prawa do bycia zapomnianym, anonimizacja)
  • kopie zapasowe i politykę przywracania danych
  • dostępność dla osób niepełnosprawnych
  • monitoring systemu (np. dashboard z błędami)
  • zarządzanie konfiguracją (np. późniejsze zmiany pewnych ustawień systemu, widoczności elementów, itp)
  • logowanie zmian w systemie (kto, co kiedy zmienił)
  • elastyczność systemu (np. zmiana pewnych reguł biznesowych)
  • rozszerzalność (np. dodawanie pluginów czy api)
  • utrzymanie (kto i jak będzie utrzymywał program po realizacji)
  • regulacje prawne (np. wymagania bankowe, audyty itp)
  • internacjonalizacja (i18n – kilka wersji językowych)
  • lokalizacja (L10n – formatowanie dat i numerów według lokalizacji)

Należy określić, które z tych wymagań są najważniejsze. Często doprecyzowanie, zadawanie odpowiednich pytań, pokazywanie alternatywnych rozwiązań i drobne kompromisy, mogą znacznie uprościć skomplikowanie i cenę systemu (np. zmiana uptime z 99,99% na 99,9%).

• Ograniczenia organizacyjne
  • czas i budżet
  • lista zaakceptowanych technologii
  • integracja z istniejącymi systemami
  • docelowe środowisko produkcyjne
  • dojrzałość wybranych technologii
  • korzystanie z bibliotek Open Source
  • dotychczasowe doświadczenia klienta
• Pozostałe
  • wielkość i doświadczenie zespołu
  • zdolność zespołu do skalowania
  • możliwość korzystania z usług konsultantów

Wysokopoziomowe zrozumienie wymagań to fundament do podjęcia decyzji architektonicznych. Pochylenie się nad powyższymi punktami powinno znacznie pomóc w lepszym poznaniu tych driverów. To z kolei stanowić będzie solidny fundament do tworzonej wyceny i architektury tworzonej aplikacji.

PS. W książce znajdziemy również sporo informacji na temat samej roli architekta, kim jest i jak wyglądać powinna jego praca w zespole. Autor poświęca również sporo miejsca samemu procesowi tworzenia architektury i zarządzaniu ryzykiem.

Książka dostępna jest tutaj.

Ciekawa prezentacja autora w temacie: