Nie ma chyba dzisiaj w informatyce nikogo, kto nie chciałby być agile. Słowa „zwinność”, „elastyczność”, „lekkość” zastąpiły wcześniej modne formalne procesy i metodyki. Mało kto jednak potrafi określić, jakie czynniki sprawiają, że organizacja informatyczna możne być zwinna. Powiedzmy dzisiaj o architekturze – a dokładniej, trzech wymiarach architektury, które są warunkiem koniecznym zwinności.

Na potrzeby tego artykułu zdefiniujmy zwinność biznesową jako zdolność organizacji IT przedsiębiorstwa do znaczącej zmiany obsługiwanych wolumenów biznesowych, radykalnej przebudowy portfela produktów i usług lub głębokiej zmiany organizacyjnej (np. szerokiego outsourcingu albo przejęcia konkurenta) w stosunkowo krótkim czasie, liczonym raczej w dniach i tygodniach niż latach.

Elastyczna architektura infrastruktury

Pierwszy warunek elastyczności biznesowej to zwirtualizowana, skalowalna, modularna infrastruktura zarządzana w modelu SDI (software defined infrastructure). Ktoś powie – co ma do elastyczności technologia serwerów czy sposób zarządzania systemami operacyjnymi? Otóż – elastyczność biznesowa to konieczność wdrażania nowych aplikacji, szybkich modyfikacji do nich oraz gwałtowne zmiany wolumenów biznesowych. Innowacyjny biznes przechodzi gwałtowne przemiany. Co jeśli wczoraj obsługiwaliśmy sto umów dziennie, a dzisiaj ta liczba skacze do tysiąca? Tydzień temu 90% klientów dokonywało płatności w gotówce, dzisiaj 90% robi to przelewem i kartą? Miesiąc temu obieg dokumentów był głównie papierowy, w jednym radykalnym ruchu został całkowicie zelektronizowany? To oznacza kolosalne zmiany w wolumenach danych i ruchu. Jedne serwery pozostaną bezczynne, inne będą grzały się do czerwoności od dodatkowego obciążenia. Zmieni się profil wykorzytanie pamięci masowych, objętość kopii zapasowych i wymagana pojemność łącz.

Oczywiście w takich warunkach nie ma mowy o interwencyjnych zakupach. Terminy dostawy serwerów liczone są w tygodniach, wdrożenie ich do pracy zajmuje kwartał. Nie może być także mowy o utrzymywaniu dużego (np. dwukrotnego) zapasu mocy obliczeniowej i pojemności pamięci – to wielkie koszty, których nie da się uzasadnić biznesowo.

Jedyne wyjście to możliwość „przerzucania” odpowiednich mocy z miejsca na miejsce, w miarę, gdy jedne aplikacje przestają być ważne, a inne zaczynają. Możliwe jest to tylko tam, gdzie środowisko infrastrukturalne jest ujednolicone (a w więc zarządzanie nim jest proste), zautomatyzowane (a więc zdecydowana większość czynności może odbyć się z poziomu zdalnie lub z poziomu skryptu) oraz zwirtualizowane (instalacja nowego serwera trwa pojedyncze minuty).

Warto więc polecić narzędzia SDI (np. Ansible, Chef, Puppet) oraz automatycznej budowy i wdrażania aplikacji (np. Jenkins, Gradle) – dzięki nim czynności związane z budowaniem, odtwarzaniem i konfigurowaniem środowiska mogą być zautomatyzowane w postaci skryptów.

Oczywiście nie każda firma posiada własne centrum danych i własną infrastrukturę. Warto jednak pamiętać, że każda firma musi zarządzać swoją infrastrukturą – nawet jeśli jest ona outsourcowana. „Nie istnieje coś takiego jak chmura, zawsze jest komputer po drugiej stronie kabla” – mówi popularny mem internetowy. Warto o tym pamiętać – nawet w czasach, gdy koncepcja chmury prywatnej pozwala nie myśleć o komputerze jako rzeczy fizycznej, zawsze istnieje pewna bariera – liczba rdzeni, pamięć operacyjna, moc obliczeniowa, wydajność łącz i prędkość pamięci masowych – która sprawia, że rzeczywista chmura nie jest idealnie elastyczna i skalowalna.

Modularna architektura aplikacji

Ale wirtualizacja i „zachmurzenie” infrastruktury to nie wszystko. Kolejnym ograniczeniem dla elastyczności aplikacji biznesowych pozostaje ich architektura. Wielka Integracja – trend, który panował w informatyzacji w pierwszej dekadzie XXI wieku – pozostawił nas z klasycznym modelem spaghetti. Nawet tam, gdzie wdrożono szynę usług (Enterprise Service Bus), najczęsciej nie jest ona jedynym interfejsem danych.

Mnogość interfejsów pomiędzy aplikacjami – stąd dane są brane, tutaj przetwarzane, tam wysyłane – sprawia, że środowisko staje się niezmiernie trudne w zarządzaniu. Każda zmiana musi przejść przez obszerną i drobiazgową analizę zależności, dla każdej trzeba wykonać testy – albo liczyć się z ryzykiem błędów i niedostępności, na co organizacja AD 2016 jest bardzo wrażliwa. A szczegółowa analiza zależności jest pracochłonna i trudna, bo bazuje na dokumentacji systemowej, która – uderzmy się w pierś – nie jest priorytetem przy realizacji systemów.

W efekcie, zmiana oferty produktowej czy kształtu procesu – warunek konieczny zwinnej zmiany w przedsiębiorstwie – przebiega po trochu po omacku: tu zmienimy, tam coś może działać inaczej, ten interfejs może przestać działać, ale co dokładnie się wydarzy, tego nie wie nikt. Oczywiście w takiej sytuacji pomóc mogą tylko drobiazgowe testy. Tylko najczęściej nie ma na nie czasu.

Co w tej sytuacji zrobić? Najlepszą odpowiedzią jest stosowanie zasady, że żaden system nie dowierza drugiemu i weryfikuje dane na stykach. Jeśli podsumowania sprzedaży przesyłane są do systemu analitycznego oraz finansowego, to każdy z nich powinien na wejściu je weryfikować: czy dane są kompletne, czy sumy się zgadzają, czy spójność wewnętrzna jest zachowana, czy nie ma duplikatów. Skrupulatnie uruchamiane procedury weryfikacji pozwolą ograniczyć błędy do jednego systemu. Automatyczne ich uruchamianie zaś pozwoli wykryć błąd natychmiast po jego wystąpieniu i zatrzymać go tam, gdzie powstał. Na linii produkcyjnej Toyoty każdy pracownik miał prawo zatrzymać linię, jeśli widział defekt. W ten sposób ochraniał innych przed propagacją błędów w procesie, a zepsutą maszynę przed robieniem kolejnych zepsutych części. W dobrej architekturze systemy powinny móc wstrzymać import lub przetwarzanie, jeśli widzą błędne dane. Lepiej poprawić je ręcznie i uruchomić proces ponownie, niż tygodniami lub miesiącami usuwać skutki błędów.

Na dłuższą metę jednak nic nie zastąpi ładu w architekturze. Ważniejsze od wykrywania błędów jest nie dopuszczanie do ich powstawania. A powszechnie wiadomo – im większa złożoność systemów, tym więcej sposobności do wystąpienia błędów. Złożoność będzie rosnąć tam, gdzie nie ma kontroli architektonicznej. Jeśli organizacja IT nie ma funkcji głównego architekta, mapy architektonicznej oraz procesów „policyjnych”, które sprawią, że inwestycja będzie mogła być zrealizowana wyłącznie wtedy, gdy nowy system będzie zgodny z wytycznymi architekta – to prędzej czy później przegra. Znajdzie się w sytuacji, w której zawartość środowiska IT jest sumą wektorów interesów poszczególnych projektów i interesariuszy, nie zaś długofalowej wizji i strategii informatycznej.

Zwinna architektura procesów

Kolejna „warstwa” organizacji IT zapewniająca elastyczność to architektura procesów. Nie można myśleć o zwinności, jeśli jest ona sztywna i zbiurokratyzowana.

Problem w tym, że ład procesowy to jeden z warunków wysokowydajnej organizacji IT. Zapewnia terminowe realizowanie projektów, utrzymanie wysokiego poziomu dostępności aplikacji oraz sprawne rozwiązywanie zgłoszonych incydentów. Jak więc pogodzić dojrzałą, silnie obudowaną procedurami organizację informatyczną w przedsiębiorstwie z potrzebą dużej elastyczności?

Gartner pisze o „IT dwóch prędkości”. Radzi, by do bieżącego zarządzania utrzymywać dobrze naoliwioną maszynę operacyjną, która rozwiązuje zgłoszenia, instaluje niezbędne aplikacje oraz buduje i wdraża zmiany. A oprócz tego mieć innowacyjny, kreatywny „garaż” – grupę osób, które tworzą i wdrażają innowacje na zasadach podobnych do startupów.

Nie każdego stać na taki luksus; umiar i rozsądek to najlepsi doradcy CIO. Na dobry początek warto wiedzieć, kiedy zasady rygorystycznie egzekwować, a kiedy je łamać. Na co dzień zarządzajmy naszym IT jak dobrze zorganizowaną fabryką: zanim rozpoczniemy projekt uzgadniamy jego zakres, zasoby, budujemy komitet sterujący i określamy termin realizacji liczony w miesiącach. Przegladamy miary z procesów ułożonych według wytycznych ITIL i rozliczamy ludzi ze źle wdrożonych zmian i nieskutecznych rozwiązań problemów. A raz na jakiś czas łamiemy zasady. Pojawia się okazja, żeby zrealizować coś dużego – przejęcie konkurenta, wejście na nowy rynek, nowy, przełomowy produkt – po prostu rzucamy to wszystko w kąt i biegniemy do przodu, bez oglądania się za siebie. Dobrze jest znać reguły, dobrze także wiedzieć, jakie są ramy ich obowiązywania.

Zasady pisane są na czasy stabilne, kiedy sprawy idą „jak zwykle”. W czasach niepewnych zasady trzeba łamać. Ale łamanie zasad nie może stać się nową regułą. Tam, gdzie nie ma procesów, miar, zorganizowanego procesu wytwórczego, testów przed wdrożeniem i ładu korporacyjnego, wkracza entropia, a potem chaos, koszty, luki bezpieczeństwa i nieprzewidziane niedostępności. Po karnawale przychodzi post i jego ograniczenia – i trzeba pamiętać, aby po wielkiej zmianie zawsze wrócić na ziemię. Sztuka zarządzania to w dużej mierze zdolność odróżniania tych dwóch momentów w czasie życia organizacji IT.

Bez kultury się nie uda

Na koniec najważniejsze: wszystkie trzy powyżej wymienione aspekty – architektura infrastruktury, aplikacji i procesów – nie pomogą, jeśli organizacja kulturowo jest niezdolna do ruchliwości. Jeśli celebruje pewne rytuały, podkreśla hierachię i dystans władzy, oczekuje przede wszystkim posłuszeństwa i nie zostawia miejsca na eksperyment i porażkę – może wdrożyć elastyczną infrastrukturę, modularną architekturę, zadeklarować innowacyjność, a i tak nie będzie do niej zdolna. Warto pamiętać, że to, co najważniejsze, dzieje się w głowach, że mindset pracownika to równie ważny komponent elastyczności biznesowej, co narzędzia wirtualizacji i testy jednostkowe.