Wstęp
Architektura IT jest jednym z fundamentów sukcesu projektu. Czym właściwie architektura jest i jak ją definiować?
“If you think good architecture is expensive, try bad architecture.” —Brian Foote and Joseph Yoder
Ta wypowiedź podsumowuje, jak ważna jest architektura w projekcie.
Miarą dobrej architektury nie jest to, że jest tania na początku, tylko jak wyglądają koszty rozwoju oprogramowania z każdą kolejną wersją.
Definicja Architektury IT
Martin Fowler w jednym z artykułów powiedział, że architektura jest rzeczą ważną, a architekci to osoby, które zajmują się ważnymi rzeczami.
TOGAF przedstawia dwa opisy architektury:
- *The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (Source: ISO/IEC/IEEE 42010:2011)*
- *The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.*
Architektura IT opisuje z jakich elementów budujemy system, w jaki sposób te elementy ze sobą współpracują oraz jakie zasady i ograniczenia przyjmujemy podczas jego projektowania i rozwoju. To nie tylko diagram — to świadome decyzje, które wpływają na to, jak system będzie się zachowywał, rozwijał i jak kosztowne będą w nim zmiany.
Mówiąc o architekturze IT, ciężko uniknąć porównań do architektury budynku.
Chcąc zbudować nowy budynek musimy określić jaki jest cel budowy, do czego ma służyć ten budynek. Kto będzie z niego korzystał. Czy będzie ktoś tam mieszkał, czy będzie to biurowiec.
Podobne pytania musimy zadać sobie zanim zaczniemy projektować rozwiązanie.
Nie żyjemy w próżni. Otoczenie w naszej organizacji także ma wpływ na oprogramowanie, które tworzymy. Także standardy w firmie mogą wpływać na wybór rozwiązania.
Czym w takim wypadku kierować się podczas wyboru rozwiązania?
Tworzenie architektury IT bazuje na wymaganiach stawianych przez cel i potrzebę biznesową. Musimy pamiętać o tym jakie problemy ma rozwiązać oraz do kogo będzie skierowane oprogramowanie.
Inaczej będzie projektowane rozwiązanie dla wewnętrznej aplikacji do obsługi klienta, niż portal internetowy dostępny dla wszystkich.
Trzeba wziąć pod uwagę, że architektura może ewoluować i jej cechy mogą się z czasem zmieniać.
Elementy Składowe Architektury IT
Podczas opracowywania rozwiązania musimy wziąć pod uwagę 4 elementy:
- styl architektoniczny
- charakterystyki architektoniczne
- decyzje architektoniczne
- zasady projektowania
Każdy z tych elementów potrzebny jest, żeby spojrzeć na architekturę z różnych perspektyw.
Omówmy więc w skrócie poszczególne elementy.
Style Architektoniczne
Określa rodzaj architektury zastosowany w rozwiązaniu.
Opowiadałem już o dwóch stylach architektonicznych:
Wyróżniamy ich o wiele więcej. Nie ma uniwersalnego rozwiązania, każdy styl ma zastosowanie w konkretnych problemach do rozwiązania.
Styl architektoniczny musi być dostosowany do potrzeb projektu.
Trzeba tutaj powiedzieć, że chodzi o określenie stylu architektury, a nie struktury aplikacji.
Charakterystyki Architektoniczne
Chcąc zaprojektować rozwiązanie musimy wiedzieć jakie ma charakterystyki, czyli na jakich elementach trzeba się skupić.
Co jest ważniejsze: jak największa dostępność aplikacji, czy ograniczenie jej działania do godzin roboczych.
Ma być skalowalna, czy jednak jest aplikacją wewnętrzną z małym ruchem.
Wszystkie słowa, którymi możemy określić aplikację, nadają kierunek, w jakim będzie się rozwijała.
Decyzje Architektoniczne
Podczas opracowywania rozwiązania, wyboru stylu architektonicznego, technologii podejmujemy decyzję.
Decyzje, które zostały podjęte, powinny być zapisywane wraz z opisem mówiącym o szczegółach podjętej decyzji.
W tym celu wykorzystywane są ADR-y, czyli Architecture Decision Record.
Zawierają one w sobie informację o problemie, możliwych opcjach i ostatecznej decyzji.
Pamiętajmy, że decyzje są podejmowane w konkretnym momencie. Możemy dołączyć do projektu, kiedy architektura jest już rozwinięta i nie każda decyzja z dzisiejszej perspektywy może nam się wydawać logiczna.
Powrót do ADR-ów i przeczytanie o możliwych opcjach w przeszłości może nam pomóc podjąć decyzję dzisiaj.
Zasady Projektowe
Zasady projektowe to drogowskazy wykorzystywane podczas projektowania rozwiązania.
W odróżnieniu od ADR-ów nie są wyrytymi w skale zasadami.
Mówią one o kierunku jaki powinien być obierany podczas rozwiązywania problemów. Np. preferowane jest wykorzystywanie komunikacji synchronicznej, ale nie oznacza to, że jeżeli w danej sytuacji lepsza będzie komunikacja asynchroniczna to nie możemy jej użyć.
Poziomy Architektury
Architektura IT występuje na różnych poziomach szczegółowości i realizuje ona inne cele.
Możemy powiedzieć, że przechodzi od ogółu do szczegółu.
Wyróżnić możemy:
- architekturę korporacyjną
- architekturę rozwiązań
- architekturę oprogramowania
Przyjrzyjmy się bliżej poszczególnym poziomom.
Architektura Korporacyjna
Na poziomie strategicznym przedsiębiorstwa określana jest architektura korporacyjna.
Nadaje ona kierunek rozwoju architektury, która ma spełniać strategiczne cele przedsiębiorstwa.
Wykorzystywane są w tym celu frameworki takie jak TOGAF czy Zachman.
Mówią one w jaki sposób zarządzać architekturą.
Decyzje podejmowane na tym poziomie wpływają na standardy, z którymi spotkasz się w każdym projekcie.
Architektura Rozwiązania
W ramach architektury rozwiązania schodzimy poziom niżej. W ramach tej architektury zajmujemy się konkretnym projektem, niekoniecznie musi być to jeden system.
Możemy skupić się na grupie systemów, domenie, za którą jesteśmy odpowiedzialni.
Określamy sposoby integracji, przepływu danych (data flow), sposób rozwoju oprogramowania.
Naszym celem jest spójność architektury w obszarze, za który jesteśmy odpowiedzialni.
Na tym etapie następuje współpraca z analitykami biznesowymi.
Architektura Oprogramowania
Najniższy poziom. Zajmujemy się kodem. Tym w jaki sposób ma wyglądać struktura projektu, jakie konkretne rozwiązania powinny zostać zastosowane.
Odpowiedzialni jesteśmy za jakość tworzonego kodu.
Podejmowanie Decyzji Architektonicznych (Trade-offy)
Podczas określania architektury rozwiązania pojawia się wiele momentów kiedy dochodzimy do Trade-offów.
Trade-offów, inaczej kompromisy to decyzje, które podejmujemy w trakcie projektowania rozwiązania.
Wszystkie decyzje powinny być zapisane za pomocą ADR-ów, o których wspomniałem wcześniej.
Jakie to mogą być decyzje?
- Build vs Buy – lepiej zbudować samemu rozwiązanie czy je kupić
- Cloud vs On-premise – gdzie powinna znajdować się infrastruktura dla oprogramowania
- Monolit vs Mikroserwisy – które podejście lepiej się sprawdzi w projekcie.
Decyzje te muszą być podjęte na podstawie analizy wymagań, kosztów oraz możliwości technicznych jakie posiadamy w organizacji.
Jeżeli nie posiadamy kompetencji związanych z chmurą obliczeniową to koszty ich zbudowania powiększą budżet projektu.
Architektura Ewolucyjna
Często mówiąc o architekturze opisujemy początkowy jej stan. Jednak architektura nie jest czymś, co raz stworzone, pozostaje niezmienne.
Architektura ewoluuje wraz z rozwojem i decyzje związane z rozwiązywaniem problemów pojawiają się cały czas.
To, że aplikacja powstała jako monolit nie oznacza, że nie zostanie przebudowana na mikroserwisy.
W trakcie rozwoju oprogramowania może pojawić się wiele zmiennych, które będą wpływały na kierunek rozwoju.
Dlatego ważne jest, aby podczas projektowania oprogramowania było ono elastyczne i dostosowane do wprowadzania zmian.
Podsumowanie
Architektura istnieje, a nasza świadomość jej istnienia i dogłębne zrozumienie pozwalają na lepsze podejmowanie decyzji związanych z rozwojem oprogramowania.
Niezależnie od naszej pozycji w projekcie, decyzje architektoniczne oddziaływują na naszą pracę.
Warto wiedzieć o przyczynach oraz skutkach podejmowanych decyzji.
Następny artykuł w ścieżce Architektura: