Zwinność i architektura IT

Data: 2017-09-14
Autor: Sebastian Konkol
Zwinność i architektura IT

Imperatyw dopasowania w sferze rozwoju oprogramowania zmaterializował się w postaci zwinnych metod rozwoju oprogramowania. W sferze architektury IT zwinność sięgać musi znacznie dalej – powinna objawiać się niezależnie od procesów rozwoju oprogramowania. Chodzi wszak o to, żeby nie trzeba było uruchamiać zwinnego projektu, żeby w pośredni sposób uzyskać zwinność – powinna być ona wbudowana w reguły konstrukcji rozwiązań tak, aby istnieć niezależnie od procesów rozwoju oprogramowania.

Pamiętamy, że definicja zwinności w architekturze włącza do tworzenia zwinności także – a może przede wszystkim – użytkowników systemów IT. Architektura ma zapewnić zdolność do wykorzystania funkcji systemów w sposób nieprzewidziany w czasie tworzenia tych systemów. Takie systemy klasyfikowane są jako złożone systemy adaptujące się. I nie ma w tym żadnej wewnętrznej sprzeczności, choć – bez wątpienia – tworzenie zwinnej architektury wymaga pozbycia się kilku zakorzenionych przyzwyczajeń i w pewnym zakresie także zmiany sposobu myślenia o tym, czym jest system informatyczny.

Ludzie i ich zachowania – tak samo jak systemy IT – stają się elementami systemu złożonego. Ludzie organizują się, a systemy informatyczne powinny im to ułatwiać, a przynajmniej w tym nie przeszkadzać. W konsekwencji, tradycyjne „ciężkie” zdolności systemów informatycznych powinny ustąpić konstrukcjom luźno powiązanych funkcji. Te funkcje mogą być powiązane procesami (w znaczeniu rutynowych czynności, powtarzanych okresowy), ale wcale nie muszą. Równie dobrze mogą być wiązane przez użytkowników systemów IT. Wszak, gdyby systemy IT wspierały jedynie zdefiniowane procesy (rutynowe), to jedyną korzyścią z IT byłaby efektywność kosztowa – gdzie tu miejsce na dostosowanie? Aktywności ludzi są tak samo dobrym spoiwem działania systemów informatycznych, jak zdefiniowane procesy. Tak powinien wyglądać szkielet myślenia dla zwinnej architektury biznesowej: jakie funkcje musimy dostarczyć i jak minimalnie usztywnić ich współpracę, nie ograniczając ich wykorzystania poza kontekstem usztywnienia. Informatyka nie musi organizować życia w firmie, ale ma zapewnić usługi, które pomagają zorganizować to życie. Odpowiedzialność za organizowanie spoczywa ba ludziach, opiera się na ich współpracy, a nawet zachowaniach grupowych, jak flash mob. Systemy IT nie mają prawa wprowadzać przesztywnienia do sposobu działania organizacji. Rzecz jasna, wprowadzając w miejsce kontroli (zdefiniowany proces) aktywności użytkowników systemu wymaga od tych ostatnich istotnie więcej świadomości i odpowiedzialności – krótko mówiąc zaufania im, ale zaufanie leży u samych fundamentów Agile. Chcemy móc się dopasowywać – doskonale, ale musimy rozluźnić mechanizmy „samoobrony” systemów informatycznych.

Skoro wiemy, że dopasowanie jest cechą ludzkiego komponentu systemu złożonego, to zadaniem systemów IT jest zapewnienie gotowości do wykorzystania funkcji systemów w okolicznościach odmiennych od znanych w czasie tworzenia danego systemu. Na szczęście wiemy, jak tworzy się systemy IT, na które składają się luźno powiązane funkcje – to architektura SOA i EDA, o ile w myśleniu o nich oderwiemy się od czysto technologicznej perspektywy integracji systemów IT. Usługą SOA może być funkcja CRM rejestracji klientów, a integracja (EAI) nie ma tu żadnego znaczenia. Jeśli usługa „na platformie integracyjnej” jest zrozumiała dla użytkownika biznesowego (potrafiłby podać wartość wszystkich parametrów wywołania i poprawnie zinterpretować wynik) to taka usługa jest SOA. Cóż bowiem stałoby na przeszkodzie wygenerowania prostego interfejsu WWW dla takiej usługi i użytkowania jej wprost przez użytkowników? Wiązanie luźnych funkcji może (ale nie musi) wykorzystywać narzędzia klasy BPM / BAM. Im zwinniejsza organizacja, tym mniej tych „ograniczających” wiązań musi występować.

Antytezą luźno powiązanych funkcji są systemy zintegrowane, które zbyt często narzucają organizacji ramy działania wprowadzając znaczne przesztywnienia do formuły jej działania. Jeśli o powodzeniu biznesu ma decydować zwinność, to systemy zintegrowane (ERP, CRM) są tragicznymi przeżytkami, dinozaurami czekającymi na swój meteoryt, których nic nie jest w stanie uratować. W ich miejsce powinniśmy wykorzystywać platformy aplikacyjne ułatwiające osadzanie komponentów realizujących luźne usługi oraz korzystać z integracji i narzędzi procesowych, a przede wszystkim pozwolić użytkownikom być częścią takiego systemu złożonego. Musimy jednak pokonać jeszcze jedno przyzwyczajenie – imperatyw wbudowywania w systemy polityk dostępu do nich nie przekłada się na luźne komponenty. Luźno wiązane funkcje powinny być budowane bez włączania w ich logikę reguł dostępu do nich, a takie reguły i ich egzekwowanie powinno być zadaniem wydzielonej, specjalizowanej platformy zarządzania polityką dostępu. Wszak w czasie życia usługi chcemy nie tylko nadawać uprawnienia do wykonania usługi, ale wręcz zmieniać zbiory reguł rządzących tymi uprawnieniami. Takim samym elementem polityki wykorzystania systemu (opisywanym i egzekwowanym) powinna być także możliwość dokonywania eksperymentów na zbiorze luźno powiązanych funkcji (sandbox). Takim samym elementem polityki jest egzekwowanie założonych parametrów QoS i SLA. W tym samym miejscu możemy wręcz różnicować sposób działania funkcji systemu, uzupełniając ich wywołania o parametry sterujące. Zasady zmieniane w trybie runtime, nie zaś zmiany w systemie informatycznym, nawet wprowadzanej zwinnie.

Aby nie dać się zwariować, nie wszystko musi być zwinne. Zwinność może być kosztowna, szczególnie dla organizacji przyzwyczajonej do braku takiego trybu działania. Nie każda funkcja organizacji ma wpływ na sposób działania całego organizmu firmy. W miejscach, w których wdrożenie zwinności nie przyniosłoby znaczących efektów lub wiązałoby się ze zbyt dużym ryzykiem „uzwinnianie” nie ma najmniejszego sensu. Zalecam zdrowy rozsądek.

Budowanie zwinnej architektury nie jest łatwe. Dysponujemy jednak wszelkimi narzędziami, które na to pozwalają. Zwinność biznesowa wynikająca wyłącznie z architektury to ślepa uliczka. Architektura powinna zapewnić realizację swojej części zadania zwinności biznesowej – dopasowanie, póki co, jest domeną ludzi a nie informatyki. Rozwiązania informatyczne nie są ograniczeniem zwinności. Jeśli coś nim jest, to raczej decyzja, jak wiele uprawnień jesteśmy w stanie przekazać użytkownikom, którzy tę zwinność mają zapewnić.

Pozostaw komentarz