Obserwując zmiany na rynku zauważyłem, że rola architektury systemów (architektury oprogramowania) rośnie. Dziś w wielu organizacjach myśli nie tylko a architekturze oprogramowania, ale także o architekturze biznesowej. Z punktu widzenia organizacji architektura aplikacji jest dla zespołu tworzącego aplikację tym, czym projekt budynku dla budowniczych. Architektura systemów to jak małe osiedle. Zanim zaprojektujemy “nasze osiedle” zastanówmy się czym jest architektura.
„Architektura [systemów] określa podział oprogramowania na komponenty oraz definiuje funkcje tych komponentów i występujące między nimi relacje. Opis architektury oprogramowania pełni w projekcie rolę schematu jego budowy. Poza zakresem projektu architektury oprogramowania pozostaje określenie sposobu realizacji komponentów, nazywane niekiedy projektowaniem szczegółowym. Opracowanie architektury oprogramowania jest zadaniem twórczym, którego treścią jest definiowanie komponentów, których współdziałanie zapewni realizację wymaganego zachowania systemu.” – K.Sacha Inżynieria oprogramowania.
Architektura systemów jest ważna. Booch, Rumbaugh, Jacobson w „UML przewodnik użytkownika” nakładają na architekturę dużą odpowiedzialność. Ich zdaniem:
„Architektura to zbiór znaczących decyzji dotyczących:
- organizacji systemu komputerowego
- wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany
- zachowania tych elementów opisanego w kooperacjach
- składania elementów strukturalnych i czynnościowych w coraz to większe podsystemy
- stylu architektonicznego, według którego tworzy się konstrukcję
- systemu, to znaczy charakterystycznych elementów statycznych i dynamicznych oraz ich interfejsów, kooperacji i składania.
Architektura oprogramowania dotyczy nie tylko jego struktury i zachowania, ale także stosowania go, jego funkcjonalności, efektywności, odporności, możliwości ponownego użycia, ograniczeń ekonomicznych i technologicznych oraz estetyki.”
Moim zdaniem architektura systemów to wysokopoziomowy opis pojedynczej aplikacji lub zbioru kooperujących ze sobą aplikacji. Architektura nie zawiera szczegółów realizacji funkcji i struktur danych. Celem przygotowania architektury jest odzwierciedlenie zachowania i relacji pomiędzy jej składowymi elementami takimi jak komponent lub aplikacja, które możemy traktować jako czarne skrzynki. Architektura systemów nie tylko określa elementy składowe oprogramowania, ale zawiera również w sobie informacje o tym, w jaki sposób poszczególne elementy architektury wchodzą ze sobą w interakcje. Co więcej, poprzez fakt, że architektura jest pewnym widokiem abstrakcyjnym, może pomijać mniej istotne elementy.
Architektura systemów musi dotyczyć całościowego spojrzenia na rozwiązanie, na które składają się zarówno procesy biznesowe jak i funkcje poszczególnych aplikacji, które te procesy wspierają. Architektura systemów nie obejmuje tylko sytuacji obecnej, ale stanowi wizję rozwoju systemów, jaka ma nastąpić w przyszłości. Wizja architektury systemów informatycznych powinna być skorelowana z wizją rozwoju biznesowego.
Architektura systemów pokazuje nam jakie funkcje zapewni nam oprogramowanie A w przypadku połączenia architektury aplikacji z architekturą biznesową uzyskamy informacje, które moduły oprogramowania będą wspierały konkretne procesy biznesowe lub kroki w procesach biznesowych.
Architektura systemów musi określić odpowiednie ramy dla rozwoju aplikacji, ukierunkowując swobodę ich rozwoju i zapewniając jednocześnie zdolność do kooperacji. Co więcej, architektura systemów musi opierać się na podstawowym przemyśleniu całokształtu funkcjonalności, wydajności, niezawodności i bezpieczeństwie. Z tego też powodu, architekt (lub zespół architektów) powinien dysponować wymaganiami funkcjonalnymi wobec rozwiązania, procesami biznesowymi, a także wyraźnie określonym wykazem oczekiwanych od opracowywanej architektury atrybutów jakościowych, takich jak przykładowo wymagania dotyczące bezpieczeństwa lub wydajności.
Praca architekta wiąże się z podejmowaniem szeregu decyzji zależnych od potrzeb biznesowych, możliwości technicznych, czasu oraz oczekiwanych rezultatów. Architektura tak jak projektowane oprogramowania jest produktem, który zawsze albo przeważnie jest unikalny. Unikalność architektury to miks kompetencji architekta, środowiska, w którym działa jak i wpływ interesariuszy.
Interesariusze mają różne potrzeby, co do których oczekują, że planowana architektura je spełni. Potrzeby mogą dotyczyć funkcjonowania aplikacji zakresu, wsparcia procesu biznesowego albo czasu działania całego rozwiązania.
Architekt musi pogodzić oczekiwania biznesowe wobec projektowanej aplikacji z możliwościami technicznymi platformy, którą ma do dyspozycji.
Składowe elementy architektury oddziałują ze sobą wzajemnie za pośrednictwem interfejsów. Interfejs wskazuje jakie usługi oferuje dany element. Interfejs specyfikuje, z jakich funkcji mogą skorzystać inne elementy składowe architektury. Zachowanie każdego elementu stanowi część architektury takim zakresie, w jakim może ona być obserwowana lub dostrzegane z punktu widzenia innego elementu. To właśnie kooperacja, wzajemne korzystanie z usług (funkcjonalności), sprawia, że schematy złożone z ramek i linii nie są w ogóle architekturą. Na architekturę systemów składają się struktura elementów i zachowanie pomiędzy nimi. Z mojego punktu widzenia, osoby zajmującej się modelowaniem, najważniejsze jest to, że architektura jest niewielkim, możliwym do objęcia umysłem modelem struktury systemu i sposobu współdziałania jego elementów. Technicznie bardzo dobrze sprawdzają się UML-owe diagramy komponentów i diagramy sekwencji. Pierwsze odpowiadają za przedstawienie struktury, drugie opisują kooperację komponentów.
Same diagramy to nie wszystko. W architekturze systemów ważne są także pryncypia bądź wytyczne architektoniczne, które ukierunkowują rozwój poszczególnych składowych architektury.Architektura systemów po utworzeniu, jak każdy artefakt projektowy, powinna być rozesłana do wszystkich interesariuszy, którzy powinni być czynnie zaangażowani w jej recenzowanie – weryfikację. Warto przeanalizować ją pod kątem stosownych miar jakościowych (takich jak przykładowo wydajność) oraz formalnie oceniona pod kątem atrybutów jakościowych, zanim będzie za późno, aby wprowadzać do niej zmiany.
W idealnym świecie architektura systemów powinna być tak podzielona na komponenty by implementacja kilku z nich pozwoliła na uzyskanie minimum funkcji. Dobrze zdefiniowane interfejsy i zakres odpowiedzialności poszczególnych komponentów pozwalają na przyrostowy rozwój systemu. Ułatwia to też testy i re-testy.
Wspomniana odpowiedzialność poszczególnych komponentów to taki podział aplikacji by poszczególne komponenty mogły rozwijać się niemal autonomicznie. Przykładowo komponenty tworzące dane powinny być oddzielone od komponentów używających danych. Komponenty odpowiedzialne za komunikację z otoczeniem powinny być oddzielnie zdefiniowane dla użytkownika oraz oddzielnie dla innych systemów.
Ponadto architektura systemów stanowi opis, na wysokim poziomie abstrakcji, jej elementów składowych oraz interakcji, jakie zachodzą pomiędzy tymi elementami. Architektura pozwala na wczesne odzwierciedlenie decyzji projektowych. Decyzje mogą dotyczyć zakresu dostarczonej przez aplikację funkcji, sposobu jej wykorzystania przez inne elementy składowe rozwiązania lub wykorzystania komercyjnych albo samodzielnie budowanych składników architektury.
Architektura pozwala na wskazanie, które elementy będą rozwijane, a które wygaszane. Wpływa to na planowanie pracy projektantów, analityków, a także pozwala zaplanować wcześniej rozwój infrastruktury technicznej.
Na koniec warto też jest zauważyć, że samo utworzenie architektury systemu to dopiero początek. Warto jest pielęgnować ją, poprzez aktualizację i świadome decyzje architekta, który przy nowych funkcjach lub zmianach identyfikuje komponenty i interfejsy, które powinny zostać zmodyfikowane.
