W poszukiwaniu zwinności w architekturze systemów IT - ebook

PRZEDMOWA

Mimo swojej formalizacji, projekty, nad którymi pracują setki programistów, dziesiątki menedżerów, analityków, testerów, inżynierów systemowych oraz innych osób zaangażowanych w realizację przedsięwzięcia, często kończą się tylko częściowym sukcesem. Powodów tego może być wiele: fluktujące wymagania, zmieniające się otoczenie projektu w zetknięciu z długotrwałym procesem tworzenia oprogramowania, niezrozumienie lub niejednoznaczne przekazanie wymagań pochodzących od osób je specyfikujących, przez osoby odpowiedzialne za ich identyfikację, do osób bezpośrednio zaangażowanych w ich implementację. Wszystkie one wpływają na wartość dodaną, która mogłaby być w tym samym czasie wypracowana, gdyby działania przebiegały według wcześniejszych założeń. Jednak przypadkowość weryfikuje wszystkie czynności i wymusza konieczność ciągłego dostosowania do zaistniałych okoliczności, nie dając gwarancji końcowego sukcesu przedsięwzięcia.

Wypełnienie luki między rzeczywistymi oczekiwaniami a tym, co aktualnie jest w stanie wykonać oprogramowanie, jest najistotniejsze. Koncentrując się na tej kwestii, warto spojrzeć na wytwarzanie oprogramowania z innej perspektywy. Abstrahując od procesów zdefiniowanych w organizacjach narzucających określony sposób pracy, warto skupić się na czystej interakcji między ludźmi i właśnie jej poświęcać najwięcej zainteresowania. Nie otaczać się formalizmami, a działać na płaszczyźnie obopólnego zaufania. Dążyć do osiągnięcia zakładanych celów biznesowych przez budowanie zrozumienia między interesariuszami zgłaszającymi wymagania a osobami te wymagania realizującymi, które będą się musiały zmagać z wpływem zmian na powstające rozwiązanie.

Kluczem do osiągnięcia sukcesu nie są procesy, a ludzie. To ich nastawienie do pracy i chęć rozwoju mają bezpośredni wpływ na powodzenie realizowanych przedsięwzięć, co przekłada się na korzyści odnoszone przez organizację. Praca z osobami kompetentnymi, a przede wszystkim wspierającymi dążenia całego zespołu, jest gwarancją osiągnięcia nakreślonych celów.

Podejście zwinne do architektury (ang. agile architecture) zapewnia nieograniczoną elastyczność w doborze stosowanych metodyk i narzędzi w zależności od kontekstu, w którym zostaną wykorzystane, a z którymi na co dzień będą się stykać architekci zwinni (ang. agile architects), realizując powierzone zadania według wytycznych wywodzących się z zastosowania podejścia zwinnego.

Podejście zwinne ma jeszcze jedną zaletę. Do koniecznego minimum pozwala ograniczyć łańcuszek osób pośredniczących między momentem specyfikacji wymagań a momentem ich implementacji. Jak się można domyślić, wiąże się to z koniecznością posiadania w zespole ekspertów dziedzinowych, do których nie każda organizacja ma dostęp, podnosząc tym samym poziom ryzyka realizowanych projektów i utraty potencjalnych kontrahentów. Doświadczenie w zespołach zwinnych, samoorganizujących się, jest kluczowe do osiągnięcia końcowego sukcesu rozumianego jako wytworzenie oprogramowania spełniającego zidentyfikowane wymagania zamawiającego i dostarczającego wartość dodaną.

Bezpośrednia komunikacja werbalna jest wpisana w naturę podejścia zwinnego. Nie zastąpi jej nawet najdoskonalszy sposób formalizacji. Systemy, na obecnym etapie rozwoju branży zajmującej się wytwarzaniem oprogramowania, są budowane przez ludzi i bezpośrednio czy też pośrednio dla ludzi.

Prezentowana pozycja w zamierzeniu autora nie ukazuje samych faktów czy praktyk, ale pozwala się zatrzymać i zastanowić nad tym, co robić, jak robić i dlaczego to robić, aby robić to lepiej niż dotychczas. Udostępnia wiele użytecznych wskazówek i umożliwia zrozumienie zagadnień związanych z architekturą systemów IT oraz podejściem zwinnym do tej kwestii. Porusza zagadnienia związane z wytwarzaniem oprogramowania, wskazując możliwości, jakie daje podejście zwinne widziane z perspektywy roli architekta, w różnych obszarach aktywności, w których będzie się poruszał podczas realizacji przedsięwzięć. Stanowi inspirację do znalezienia chwili na refleksję nad codziennie wykonywanymi zadaniami.PODZIĘKOWANIA

Specjalne podziękowania kieruję do dr. Sławomira Pawlikowskiego za wkład merytoryczny, porady, sugestie, zgłoszone uwagi oraz poświęcony czas prywatny, a wszystko to z zamiarem podniesienia jakości i przystępności prezentowanego opracowania.

Ogromne podziękowania kieruję do Pani Ireny Puchalskiej za zaangażowanie i wniesiony wkład pracy podczas recenzowania i przygotowania treści książki do druku.

Serdeczne podziękowania kieruję do osób, które otworzyły przede mną możliwość odkrycia nowego obszaru, zarówno rozwoju, jak i przekazywania już posiadanej wiedzy szerokiemu gronu zainteresowanych odbiorców.

Duże podziękowania należą się wszystkim, którzy tolerowali moją ograniczoną dostępność, a czasami także niedostępność w ramach obowiązków zawodowych i w życiu prywatnym, w trakcie realizacji książki.SŁOWO WSTĘPNE

Dlaczego zagadnienie architektury wzbudza takie podekscytowanie? Co skłania ludzi do podejmowania wyzwań z nią związanych? Tworzenie rozwiązań informatycznych można porównać do opracowywania strategii, przygotowywania całych kampanii. Decyzje podejmowane dzisiaj mają wpływ na przyszłość, której skutki będą widoczne w krótszej lub dłuższej perspektywie czasu. Jest tak samo pasjonujące, mimo że jego efekty nie są widoczne bezpośrednio, jak w innych branżach zajmujących się konstrukcjami, rozwojem całych miast, tworzeniem organizacji, kreowaniem biznesu, budowaniem sieci dystrybucji i kontaktów oraz innymi zagadnieniami wymagającymi kreatywnego myślenia, których skutków nie da się przewidzieć, ale można mieć na nie wpływ.

Na poziomie architektury można doszukiwać się podobieństw do zarządzania strategicznego, taktycznego i operacyjnego, wpływu podejmowanych decyzji na zespół realizujący przedsięwzięcie oraz na otoczenie projektu. Im czas odpowiedzi otoczenia jest krótszy, tym prawdopodobieństwo powodzenia jest większe.

Kolejne fazy projektu niosą poczucie euforii i/lub stagnacji, rezygnacji, obawy o to, czy obrany kierunek jest właściwy. Zagrożenia wynikające z niestabilności wymagań oraz zwiększającej się świadomości realizowanych funkcjonalności mają znaczący wpływ na kształt architektury rozwiązania. Dlatego tak ważna jest rola architekta w przedsięwzięciach informatycznych. Aby stać się dobrym architektem, nie wystarczy jednak nabyć jedynie wiedzę techniczną, którą – w dobie powszechnego do niej dostępu – mogą posiąść wszyscy. Trzeba mieć osobowość umożliwiającą prowadzenie całego zespołu w obranym kierunku i omijanie wszelkich pułapek, „gór lodowych”, na które narażony jest każdy projekt. Trzeba chronić zespół przed szkodliwym oddziaływaniem otoczenia, które będzie usiłowało przeszkodzić w osiągnięciu sukcesu przez realizację własnych interesów. Może to być otoczenie wewnątrz organizacji, mogą to być działania konkurencji – na co dzień będzie się z nimi stykał każdy architekt, dla którego nadrzędnym celem jest sukces projektu rozumiany jako realizacja wymagań biznesowych w oczekiwanym czasie, aby budować przewagę biznesową na szybko zmieniającym się rynku.

Poniższa książka nie jest czysto technicznym przewodnikiem, w którym są wyliczone style architektoniczne, wskazane możliwe sposoby postępowania, zasugerowane czynności, które należy wykonywać, aby stać się architektem zwinnym i w zwinny sposób prowadzić projekty. Wskazane są sposoby zachowań, za którymi dobrze jest podążać, aby minimalizować prawdopodobieństwo niepowodzenia i budować relacje ze wszystkimi interesariuszami projektu, ciągle mając na uwadze poszukiwanie najkrótszej i najprostszej drogi do osiągnięcia sukcesu.

Zwinność wprowadza zmianę sposobu myślenia o architekturze systemu, koncentrując się na tym, co należy zbudować, a nie jak to zbudować. Oprogramowanie zwinne nie jest projektowane po to, aby dostarczało statycznych funkcjonalności, ale skupiło się na potrzebie zmiany wraz ze zmieniającymi się potrzebami biznesowymi, aby w efekcie osiągnąć sukces biznesowy. Opiera się na podejściu przyrostowym i ewolucyjnym, adaptacyjnym planowaniu, szybkim i elastycznym reagowaniu na zmiany.

Zamierzeniem autora jest, by książka podniosła świadomość zagadnienia architektury systemów IT w kontekście metodyk zwinnych, wskazała odpowiednie podejście do architektury – zapewniające redukcję kosztów i spojrzenie na aspekty techniczne nie z perspektywy stosowanych rozwiązań technologicznych, a z perspektywy biznesowej i realizacji oczekiwań biznesu. W całym opracowaniu duży nacisk położono na kontekst i aspekty biznesowe realizowanych prac. Zaspokajanie potrzeb sponsorów i użytkowników końcowych oraz dostarczanie wartości dodanej powinno być najważniejsze podczas podejmowania wszelkich działań. Oczekiwaną reakcją odbiorcy książki jest refleksja nad uzasadnieniem biznesowym podejmowanych decyzji w zakresie organizacyjnym, jak i nad dokonywanymi wyborami technologicznymi.

Do kogo jest skierowana książka

Książka jest skierowana przede wszystkim do architektów chcących zapoznać się z podejściem zwinnym. Zachęca ich do stosowania tego podejścia w codziennej pracy, tłumaczy aspekty zwinności w kontekście architektury systemów IT.

Książka jest także przeznaczona dla osób zajmujących się biznesem. Pozwala im zrozumieć, w jaki sposób działa proces wytwarzania oprogramowania w ujęciu zwinnym, z perspektywy architektury systemów, oraz że podejście zwinne stara się być przyjazne w wypracowywaniu porozumienia i realizowaniu wymagań specyfikowanych przez osoby związane z biznesem. Może działać w sposób proaktywny, wspierając zmiany otoczenia biznesowego, dostosowując się do nich i dbając o budowę przewagi konkurencyjnej.

Poza wymienionymi wyżej odbiorcami, książka jest także adresowana do deweloperów, sponsorów i pozostałych interesariuszy projektu związanych z wytwarzaniem oprogramowania. Przybliża ideę i upraszcza zrozumienie mechanizmów zwinnego wytwarzania oprogramowania. Wskazuje korzyści i zagrożenia wynikające ze stosowania tego podejścia oraz pozwala zapoznać się ze specyfiką pracy architektów zwinnych.

O czym jest książka

W książce, w głównej mierze, poruszono zagadnienia zwinności w kontekście architektury systemów IT, jak i pracy architektów zwinnych. Ukazano, w jaki sposób znaleźć nić porozumienia między przedstawicielami biznesu a zespołami zajmującymi się wytwarzaniem oprogramowania. Zaprezentowano w niej architekturę w ujęciu manifestu zwinnego wytwarzania oprogramowania. Wskazano ścieżki i sposoby organizacji pracy w zespołach, aby podnieść jakość, efektywność i wartość dostarczanych produktów. Wytłumaczono, na jakich wzorcach opiera się podejście zwinne do tworzonej architektury, do których zalicza się zaufanie, komunikację oraz samoorganizację zespołów. Zwrócono uwagę na konieczność kooperacji wszystkich interesariuszy projektu i niezwykle istotną informację zwrotną, która powinna się pojawiać na każdym etapie projektu prowadzonego w sposób zwinny.

W prezentowanej pozycji opisano zasady pracy w zespołach zwinnych oraz zwinne podejście do modelowania systemów. Skoncentrowano się na ukazaniu w sposób ewolucyjny zarówno samej koncepcji architektury, jak i ewolucji stylów architektonicznych, ukazując powody dokonywania określonych zmian w podejściu do architektury. Przedstawiono koncepcyjne spojrzenie na architekturę w zakresie opracowywania jej formy oraz rozwiązywania zagadnień związanych z systemami rozproszonymi. Zawarto wiele odpowiedzi i cennych rad, które pozwolą stać się jeszcze lepszym architektem niż dotychczas, które przydadzą się osobom, dla których jednym z elementów praktyki zawodowej jest spojrzenie na architekturę z wysokiego poziomu.

O czym nie jest książka

W książce nie poruszono technicznych, niskopoziomowych aspektów związanych z wytwarzaniem oprogramowania. Nie wskazano właściwych dróg doboru adekwatnych rozwiązań do zaistniałych problemów. Nie zajęto się metodami, technikami i notacjami wykorzystywanymi do modelowania i nie pokazano, w jaki sposób je stosować. Nie ma w niej również analizy problemów związanych z przetwarzaniem równoległym czy wielowątkowym. Wszystkie z wymienionych zagadnień są istotne z punktu widzenia wytwarzania oprogramowania, ale promują spojrzenie niskopoziomowe, którego w przygotowanym opracowaniu nie poruszono. Większość odpowiedzi czy też rad zamieszczonych w książce nie będzie mogła zostać zastosowana w kontekście wymienionych powyżej zagadnień.

Struktura książki

Tematycznie można w książce wyróżnić dwie części. Część pierwsza zawiera opisy praktyk zwinnych związanych z architekturą systemów IT, natomiast w części drugiej zaprezentowano style architektoniczne ze szczególnym naciskiem na przedstawienie ewolucji architektur systemów rozproszonych.

W części pierwszej poruszono zagadnienia związane z koncepcją architektury oraz podejściem zwinnym; została ona podzielona na pięć rozdziałów.

Rozdział pierwszy Wprowadzenie do architektury

W rozdziale tym są rozpatrywane zagadnienia związane z pojęciem architektury, jego niejednoznaczność i podjęte próby uchwycenia w mniej lub bardziej szczegółowy sposób przewodniego przekazu, który ze sobą niesie. Są w nim także poruszone kwestie wielu widoków, spojrzeń na architekturę systemu przez pryzmat ram architektonicznych, są zawarte definicje pojęć związanych z tymi spojrzeniami wraz z ich krótką charakterystyką. Nawiązano w nim do zasad tworzenia architektury w ujęciu tradycyjnym, przedstawiono koncepcję podejścia klasycznego i zwinnego do architektury, definicje podstawowych interesariuszy projektu, opisano role architektów wynikające w dużej mierze z widoków na architekturę oraz przybliżono proces ewolucji roli architekta, która dokonała się w ostatnich latach.

Rozdział drugi Architektura zwinna

W rozdziale tym nawiązano do głównego zagadnienia opisywanego w książce – związanego z architekturą zwinną. Przedstawiono koncepcję tworzenia architektury zwinnej, cele stawiane przed architekturą zwinną, zasady tworzenia architektury zwinnej wraz z odmiennym spojrzeniem na architekturę w stosunku do podejścia tradycyjnego. Poruszono zagadnienia związane z organizacją pracy w zespołach architektonicznych i wytwórczych – wady i zalety dla architekta i dla pozostałych członków zespołów. Zaprezentowano opis wartości, jakie niesie ze sobą stosowanie architektury zwinnej, wraz z wytycznymi, które pozwalają na wypracowanie przewagi rynkowej będącej pośrednio następstwem zastosowania podejścia zwinnego do architektury.

Rozdział trzeci Architektura zwinna a manifest Agile Alliance

Rozdział trzeci to klasyka tematu zwinności przybliżająca postanowienia manifestu zwinnego wytwarzania oprogramowania w kontekście stosowania praktyk zwinnych podczas opracowywania architektur systemów IT. Przedstawiono w nim cztery nadrzędne wytyczne manifestu w kontekście architektury i organizacji pracy w zespołach: ludzie i interakcje ważniejsi niż procesy i narzędzia, działające oprogramowanie ważniejsze niż kompleksowa dokumentacja, współpraca z klientem ważniejsza niż negocjacje kontraktu, reagowanie na zmiany ważniejsze niż przestrzeganie planu. Zaprezentowane wytyczne uzupełniono o zasady wynikowe, uszczegóławiające spojrzenie na zagadnienie zwinności przez pryzmat architektury.

Rozdział czwarty Architektura zwinna a zespoły samoorganizujące się

Nie można mówić o zwinności, nie poruszając zagadnienia samoorganizujących się zespołów i dlatego również ono znalazło swoje miejsce w rozważaniach poruszanych w niniejszym opracowaniu w kontekście architektury zwinnej. Rozdział ten zawiera opis koncepcji zespołów samoorganizujących się, roli architekta zwinnego w tych zespołach, poruszono w nim także zagadnienia powoływania zespołów samoorganizujących, a także ich koegzystencję w ramach struktur liniowych zarządzania organizacją.

Rozdział piąty Dobre praktyki architektury zwinnej

Rozdział ten zawiera opis praktyk, którymi powinien kierować się architekt dążący do osiągnięcia zwinności w codziennych pracach. Praktyki te należy rozpatrywać w ujęciu technicznym, organizacyjnym oraz komunikacyjnym. Wszystkie trzy spojrzenia przenikają się nawzajem, wspomagając osoby potrafiące biegle je zastosować w codziennym życiu zawodowym.

Rozdział szósty Modelowanie zwinne

Omówienie zagadnień architektury zwinnej byłoby niepełne bez poruszenia tematu modelowania, nieodłącznego w codziennej pracy architekta. Przekaz informacyjny, jaki niosą ze sobą modele, ma znaczny wpływ na uproszczenie komunikacji między rozmówcami. W rozdziale tym przybliżono kwestie związane z modelowaniem zwinnym, wytyczne oraz praktyki związane ze stosowaniem koncepcji modelowania zwinnego.

W części drugiej zagadnienie podejścia do architektury rozpatrzono pod kątem stylów architektonicznych. Uzupełniono ją o zwięzły opis idei propagowanych przez manifest reaktywny (ang. reactive manifesto) poruszający kwestie elastycznych i skalowalnych systemów nawiązujących do koncepcji zwinności. Część druga składa się z dwóch rozdziałów.

Rozdział siódmy Ewolucja architektury

W rozdziale tym przedstawiono ewolucję architektury i stylów architektonicznych z uwzględnieniem kontekstu, w jakim dany styl mógłby zostać zastosowany. Zaprezentowano zmieniającą się koncepcję podejścia do architektury, ze szczególnym naciskiem na tworzenie systemów rozproszonych, które są coraz bardziej powszechne. Ukazano ewolucję architektury na przestrzeni lat istnienia dziedziny wytwarzania oprogramowania aż do czasu obecnego.

Rozdział ósmy Manifest reaktywny

Rozdział ten stanowi uzupełnienie koncepcji podejścia do stylów architektonicznych o spojrzenie zwinne na systemy rozproszone. Przedstawiono w nim wytyczne manifestu reaktywnego poruszającego zagadnienia systemów dużej skali, sposobów osiągania wysokiej niezawodności i dostępności. Nawiązano do zagadnień dotyczących responsywności, odporności, elastyczności oraz zorientowania systemów na zdarzenia, promując koncepcję asynchroniczności we wszystkich obszarach związanych z wytwarzaniem oprogramowania.

Jak korzystać z książki

Książka ta została napisana przede wszystkim dla architektów. Przeczytanie jej w całości pozwala zapoznać się z praktykami i poznać zasady leżące u podstaw architektury zwinnej. Przyswojenie przekazywanej wiedzy i zastosowanie jej w praktyce w znacznym stopniu pomoże osiągnąć większą efektywność w codziennej pracy w zespołach zwinnych.

Osoby zawodowo zajmujące się architekturą, którym obce jest spojrzenie na architekturę z punktu widzenia zwinnego, zgłębią zagadnienia związane z tą tematyką, czytając rozdziały Architektura zwinna, Architektura zwinna a manifest Agile Alliance, Architektura zwinna a zespoły samoorganizujące się, Dobre praktyki architektury zwinnej oraz Modelowanie zwinne. Dla osób chcących odświeżyć posiadaną wiedzę o stylach architektonicznych ze szczególnym naciskiem na zagadnienie systemów rozproszonych zostały przygotowane rozdziały Ewolucja architektury oraz Manifest reaktywny.

Osoby zawodowo zaangażowane w zarządzanie zasobami ludzkimi, jak i przeprowadzanie analizy biznesowej, zainteresowane poznaniem zasad współpracy przedstawicieli biznesu z członkami zespołów architektonicznych i wytwórczych, ze szczególnym naciskiem położonym na zasady zwinnego prowadzenia prac, znajdą wiele cennych informacji w rozdziałach Architektura zwinna, Architektura zwinna a manifest Agile Alliance oraz Architektura zwinna a zespoły samoorganizujące się. Rozdziały te zawierają wyczerpujący opis zasad i praktyk zwinnych z punktu widzenia architektów zwinnych. Wiedza w nich przekazana pozwoli zrozumieć, że biznes i przedstawiciele branży IT związanej z wytwarzaniem oprogramowania, przy odpowiednim podejściu, mogą ze sobą współpracować i wspierać się nawzajem.

Osoby zawodowo zajmujące się wytwarzaniem oprogramowania, chcące zgłębić spojrzenie architekta zwinnego na tworzone systemy, powinny zapoznać się z rozdziałami Architektura zwinna oraz Architektura zwinna a manifest Agile Alliance. Osoby pragnące poszerzyć zakres posiadanych umiejętności w zakresie spojrzenia wysokiego poziomu na architekturę znajdą wiele cennych odpowiedzi na nartujące je pytania oraz uzasadnień podejmowanych decyzji architektonicznych w projektach w rozdziale Ewolucja architektury.

Dla osób poszukujących informacji dotyczących zagadnienia architektury zwinnej zostały przygotowane rozdziały Architektura zwinna, Architektura zwinna a manifest Agile Alliance, Architektura zwinna a zespoły samoorganizujące się oraz Dobre praktyki architektury zwinnej. Zawarto w nich opis architektury zwinnej, omówiono wytyczne i praktyki jej stosowania w codziennej pracy oraz przedstawiono rolę architekta zwinnego, promując stosowanie podejścia zwinnego do architektury w zespołach zwinnych.

Osoby zainteresowane wyłącznie stylami architektonicznymi, ich ewolucją oraz obecnie panującymi trendami powinny zapoznać się z rozdziałami Ewolucja architektury oraz Manifest reaktywny. Przedstawione w nich informacje pozwalają zrozumieć przyczyny pojawiania się określonych technologii oraz stylów architektonicznych w kontekście tworzenia systemów rozproszonych.All architecture is design but not all design is architecture.

Architecture represents the significant design decisions that shape a system,

where significant is measured by cost of change.

Grady Booch

1. WPROWADZENIE DO ARCHITEKTURY

Architektura – stykamy się z nią na co dzień, tworząc systemy, kształtujemy ją, podejmując nawet najprostsze decyzje projektowe. Niepozorna zmiana może odcisnąć piętno na całym projekcie. Lepiej mieć nad nią kontrolę niż liczyć na łut szczęścia. Oczywiste jest, że architektura występuje w każdym rozwiązaniu. Powstaje w sposób bardziej lub mniej świadomy. Należałoby się jednak zastanowić, dlaczego w ogóle należy się zajmować tematem architektury.

Architektura nie stanowi tylko i wyłączenie technicznego spojrzenia na system. Odzwierciedla przede wszystkim potrzeby biznesowe, obejmując swoim zakresem punkt widzenia interesariuszy, który ma wpływ na projekt rozwiązania technicznego. Czuwa nad wprowadzanymi zmianami i pozwala redukować koszty rozwiązywania zaistniałych problemów i zagadnień. Stanowi wartość dodaną w zakresie informacyjnym, współdzieląc wizję, ideę systemu między zespołami wytwórczymi a innymi interesariuszami, na różnych poziomach szczegółowości. Co nie mniej ważne, pozwala w sposób płynny wspierać proces podejmowania decyzji biznesowych i projektowych dzięki spojrzeniu z wyższego poziomu na tworzone rozwiązanie, z poziomu, który może być zrozumiały nie tylko dla osób związanych z technologią, ale przede wszystkim dla osób kreujących biznes.

Mimo wartości, które ze sobą niesie, architektura częściej bywa postrzegana jako uciążliwy koszt, który trzeba ponosić, niż jako wartość dostarczana końcowemu użytkownikowi, który de facto jej nigdy nie zobaczy. W szczególnych przypadkach może ją odczuć, gdy styka się, obcuje z rozwiązaniami podobnej klasy, udostępniającymi podobny zakres funkcjonalny, i porównać zarówno jej ergonomię, jak i elastyczność. Architektura nie jest czymś, co widać, ale jest czymś, co da się poczuć. Podejście kosztowe jest bardzo krótkowzroczne. Wynika z braku zrozumienia wagi problemów, z jakimi stykają się zespoły tworzące systemy przygotowywane do instalacji i dalszej eksploatacji w środowisku produkcyjnym, które mają przez wiele lat przynosić wartość i budować przewagę rynkową swoim sponsorom.

Dobra architektura przynosi korzyści użytkownikom końcowym dzięki skróceniu czasu między zrozumieniem potrzeb użytkowników a dostarczeniem gotowego rozwiązania, które zaspokaja te potrzeby. Można to osiągnąć przez wyeliminowanie konieczności ciągłego przebudowywania produktu i dostarczenie ram architektury opartych na modelu dziedziny. W przeciwieństwie do podejścia tradycyjnego, podejście zwinne do architektury daje znacznie większe prawdopodobieństwo dostarczenia klientowi produktu, którego oczekuje, w krótszym czasie. Pozwala uzyskać znaczącą redukcję kosztów przez skrócenie odległości między otoczeniem, w którym porusza się użytkownik końcowy, a powstałą strukturą techniczną rozwiązania, ograniczając zbędną pracę, która nie zostanie nigdy skonsumowana w końcowym produkcie, i nastawiając się na realizację potrzeb danej chwili. Spojrzenie zwinne na zagadnienie architektury eliminuje niekorzystne zjawisko wynikające z konieczności wprowadzania zmian w gotowym produkcie, jaki stanowi całościowy projekt architektury wykonany i dostarczony zespołom wytwórczym przed przystąpieniem do implementacji. Powstaje w wyniku ewolucji będącej następstwem pojawiających się nowych funkcjonalności biznesowych. Nie mniej ważną cechą dobrej architektury, rozumianej jako przyjęty i rozwijany standard w projekcie, jest udogodnienie utrzymywania elementów systemu w sposób harmonijny, jako wzajemnie pasujących do siebie części.

Dobra architektura może być narzędziem, które pomaga biznesowi dostosować produkty do indywidualnych wymagań klientów, jak i całych rynków przez elastyczne wsparcie zastępowania jednych modułów systemu innymi.

Podejście zwinne łączy w sobie zasady tworzenia architektury w sposób tradycyjny z iteracyjnym i ewolucyjnym podejściem do zarządzania zmianą. Odpowiednio zastosowane dostarcza nowej wartości w procesie tworzenia rozwiązań w branży IT. W znacznym stopniu pozwala redukować koszty inwestycji bieżących oraz umożliwia wyższy poziom elastyczności w zaspokajaniu przyszłych potrzeb i oczekiwań klientów. Jak już wspomniano, pozwala zmniejszyć ilość pracy, której efekty nigdy nie zostaną wykorzystane w produkcie końcowym, dzięki czemu wpływa na optymalizację pracy zespołów. Wprowadza jednorodne spojrzenie na cały system, dzięki czemu wystarczająco szybko redukowane są miejsca występowania niespójności. Zespołom wytwórczym pozwala się skupić na implementacji funkcjonalności i zarządzaniu zmianą.

Co najważniejsze, architektura, a w szczególności architektura zwinna, umożliwia odzwierciedlenie nakładów inwestycyjnych. Ich ewentualna strata, wynikająca z niepowodzenia projektu, może być niewielka dzięki zastosowaniu krótkich czasów dostaw, redukując tym samym ryzyko inwestycyjne, natomiast długofalowe korzyści, jakie przynosi, mogą być znaczące.

1.1.
Definicja pojęcia architektury

Architektura jest jednym z tych pojęć, które mają tyle znaczeń, ile osób go używa. Można się z nią zetknąć w różnych dziedzinach życia. O architekturze należy myśleć bardziej w kategoriach formy, przekazu myśli, pewnej idei niż jako o strukturze. Z formy, stanowiącej esencję kształtu i porządku rzeczy, abstrahującej od sposobu, w jaki zostanie wykonana, wyłania się struktura stanowiąca jej uprzedmiotowienie. To spojrzenie na architekturę pozwala osiągnąć poziom ekspresji niezaburzony przez szczegóły implementacji, prowadzący do stworzenia architektury, która lepiej się skaluje, jest łatwiej rozszerzalna oraz znacznie lepiej realizuje swoją funkcję komunikacyjną.

Forma bierze swój początek bezpośrednio z pomysłów biznesowych. Struktura implementuje formę, poniekąd urzeczywistniając te pomysły.

Architektura w sposób spójny ukazuje byty i powiązania między nimi, wraz z ich atrybutami. Stworzony przekaz musi pozostać prosty i czytelny, oparty na wiedzy pochodzącej z dziedziny biznesowej, współdzielonej przez wszystkich interesariuszy.

W większości przypadków architektura nie jest wykorzystywana do rozwiązywania problemów użytkowników. Im zależy przede wszystkim na funkcjonalności dostarczanej przez oprogramowanie, nie są bezpośrednio zainteresowani jego formą. Występuje jednak pośrednie powiązanie formy z funkcjonalnością. Forma powstaje w długim okresie, potrzebnym do poznania oczekiwań, wymagań, zrozumienia dziedziny, istoty budowanego systemu, wsparcia tego, co powinno zostać stworzone w zgodzie z wizją interesariuszy. Na formę należy spojrzeć w szerszym ujęciu niż tylko przez pryzmat samych wymagań. Kształtowanie jej jest procesem długofalowym. Wymaga ujęcia z różnych perspektyw, aby przyniosła oczekiwane rezultaty, które w kontekście zwinności mają ułatwić wprowadzanie zmian przy zachowaniu krótkich czasów uzyskania informacji zwrotnej i wypracowania rzeczywistych korzyści wynikających z obniżenia kosztów oraz skrócenia czasu dostaw produktów na rynek.

W różnych opracowaniach można się natknąć na różne definicje pojęcia architektury używane w kontekście branży zajmującej się wytwarzaniem oprogramowania. Poniżej zostały przedstawione wybrane z nich, prezentujące w sposób bardziej lub mniej ogólny istotę analizowanej rzeczy.

Instytut Inżynierów Elektryków i Elektroników IEEE (ang. Institute of Electrical and Electronics Engineers), w opracowaniu IEEE 1471 scharakteryzował rekomendowane praktyki dotyczące architektury oprogramowania oraz zaproponował definicję pojęcia architektury w ujęciu wytwarzania oprogramowania jako:

Architektura to podstawowa organizacja systemu urzeczywistniona w jego komponentach, powiązaniach komponentów między sobą oraz z otoczeniem zewnętrznym, zawierająca wiodące zasady odnoszące się do projektowania i ewolucji organizacji systemu.

Ta dosyć ogólna definicja przedstawia kluczowe aspekty dotyczące architektury jako koncepcji właściwości systemu i jego podstawowej organizacji. Według niej system zawsze ma architekturę, jednak nie zawsze architektura musi mieć sformalizowany opis. Sam opis nie stanowi architektury, a jedynie służy do uzyskania wyższego stopnia zrozumienia koncepcji przyświecającej opisanemu systemowi. Opis architektury tego samego systemu tworzony przez osoby niewspółpracujące ze sobą może się różnić z uwagi na przyjęte różne techniki opisu oraz akcentację różnych punktów widzenia. Architektura nie będzie zrozumiała, jeśli nie będzie umieszczona w określonym dla odbiorcy kontekście. Stosowanie różnych punktów widzenia na architekturę zapewnia wspólny język komunikacji między osobami zaangażowanymi w proces konstruowania systemu na różnych poziomach i etapach jego rozwoju. Każdy z widoków architektonicznych stanowi odpowiedź na pytania określonej grupy zidentyfikowanych odbiorców i odnosi się do konkretnego punktu widzenia na system.

Zaktualizowana wersja standardu IEEE 1471 została opublikowana w opracowaniu ISO/IEC/IEEE 42010 , które zawiera definicję architektury następującej treści:

Architektura to podstawowe koncepcje lub właściwości systemu określone w jego środowisku, zawarte w jego elementach i relacjach, oraz pryncypia jego projektowania i rozwoju (tłumaczenie zostało zaczerpnięte z ).

Powołując się na definicję z opracowania , architekturę można zdefiniować jako zbiór istotnych decyzji dotyczących organizacji systemu informatycznego, wyboru elementów struktury oraz interfejsów, dzięki którym system został skomponowany, łącznie z ich zachowaniem wynikającym ze współpracy między tymi elementami, kompozycji elementów struktury oraz zachowań w coraz większe podsystemy, jak również stylu architektonicznego, który wskazuje grupie elementów i interfejsów ich kompozycję i zasady współpracy.

Niezależnie od tej definicji, wspólnym motywem powyższego opisu jest ukazanie ogólnej idei, przesłanek, ograniczeń, układu, wzorców, odpowiedzialności i połączeń wewnątrz systemu lub między systemami wchodzącymi w skład większego systemu. Nieformalnie architekturę można zdefiniować jako opis układu, przesłanek i kształtu systemu.

Według opracowania proces tworzenia architektury składa się z następujących elementów: tworzenia, definiowania, wyrażania, dokumentowania, komunikowania, poświadczania właściwego zaimplementowania, utrzymywania i udoskonalania architektury w trakcie życia systemu. Samo tworzenie architektury zawsze ma miejsce w określonym kontekście, na przykład osoby lub grupy osób posiadających możliwości aranżowania odpowiedzialności, władzy, powiązań lub projektu mającego na celu stworzenie produktu lub usługi w zgodzie z wyspecyfikowanymi zasobami i wymaganiami.

Oprócz samej definicji architektury opracowanie to dostarcza również informacji na temat ram architektonicznych (ang. architecture framework), które są rozumiane jako konwencje, zasady i praktyki wykorzystywane do opisu architektury, umiejscowione w określonej dziedzinie zastosowania i/lub społeczności interesariuszy.

Wśród najbardziej znanych ram architektonicznych, stanowiących międzynarodowe standardy, znajdują się:

■ siatka Zachmana (ang. Zachman’s information systems architecture framework) ;

■ ramy architektoniczne Ministerstwa Obrony Zjednoczonego Królestwa, MODAF (ang. UK Ministry of Defence Architecture Framework) ;

■ ramy architektoniczne The Open Group, TOGAF (ang. The Open Group’s Architecture Framework) ;

■ model 4+1 widoków (ang. Kruchten’s “4+1” view model) ;

■ metoda czterech widoków (ang. Siemens’ 4 views method) ;

■ model referencyjny dla heterogenicznych systemów rozproszonych, RM-ODP (ang. Reference Model for Open Distributed Processing) ;

■ uogólniona, referencyjna architektura korporacyjna, GERA (ang. Generalized Enterprise Reference Architecture) ;

■ ramy architektoniczne Departamentu Obrony Stanów Zjednoczonych, DoDAF, wcześniej C4ISR (ang. Departament of Defense Architecture Framework) , .

Z uwagi na kontekstowość architektury systemów nie można zapomnieć o jej umiejscowieniu w ramach architektury korporacyjnej (ang. enterprise architecture) organizacji, dla której jest tworzony system. Mimo że niniejsza książka nie porusza tematów architektury korporacyjnej, w wielu miejscach wystąpią punkty styku między architekturą systemu a architekturą korporacyjną. Osoby wnikliwe, chcące zgłębić temat architektury korporacyjnej, mogą skorzystać z opracowania , w którym to zagadnienie zostało precyzyjnie omówione.