Spiskowa teoria buły, czyli o zagadnieniach Release Management

Data: 2009-09-23
Autor: Sebastian Konkol

Długo zastanawiałem się, czy warto pisać o takich zagadnieniach, gdyż cała tematyka dotyczy wewnętrznej organizacji IT, nie zaś budowania biznesu per se. W końcu uznałem, że warto o tym napisać – po części dlatego, że zmagałem się z takimi zagadnieniami w kilku miejscach, a po części dlatego, że konsekwencje braku regulacji i rozwiązań w tym obszarze miewają wydźwięk zdecydowanie biznesowy, w większości przypadków negatywny, na pograniczu katastrofy. Rzecz dotyczy zarządzania wprowadzaniem zmian do systemów informatycznych firmy w taki sposób, który nie będzie miał odczuwalnych konsekwencji biznesowych.

Ustalmy zatem najpierw przedmiot rozważań. Firmy, szczególnie te większe, posiadają wiele różnych systemów informatycznych, które w taki czy inny sposób wspomagają przeróżne obszary działania tychże firm. Są to systemy ERP, hurtownie danych, systemy obsługi klienta, systemy rozliczeniowe, systemy zarządzania produkcją i logistyką, serwisy Intranet, bazy danych i wiele, wiele innych lub specjalizowanych. Poszczególne te systemy są powiązane między sobą w różny sposób. Żeby nie utrudniać sobie życia, stosując terminologię zaczerpniętą z nauk biologicznych, sumę systemów informatycznych i ich powiązań przyjęło się nazywać środowiskiem systemów informatycznych firmy, ekosystemem informatycznym lub w skrócie środowiskiem informatycznym. Skuteczne prowadzenie działalności wymaga zwykle sprawności działania większości z tych systemów, a „w dobie gospodarki elektronicznej i w czasach biznesu on-line coraz częściej oznacza to dostępność w trybie ciągłym (tzw. 24/7). Mimo różnych wysiłków testów i walidacji, każda zmiana dowolnego elementu tego środowiska łączy się z pewnym ryzykiem niedostępności tego elementu, co w prosty sposób prowadzi do wniosku, że każda zmiana ma potencjalnie wpływ na jakość prowadzenia biznesu firmy.

Współczesny biznes skraca czas życia produktów, skraca cykle działalności biznesowej i ogólnie przyspiesza znacznie. Sprawia to, że linie biznesowe firm muszą częściej dokonywać zmian w ofercie firm, co prowadzi nader często do zmian w środowisku informatycznym firmy. Ci klienci wewnętrzni IT, czyli – jak są oni nazywani w IT – „Biznes”, żądają więc często zmian w funkcjonowaniu poszczególnych składowych środowiska, a organizacja IT, mając wielu takich klientów wewnętrznych w firmie, musi realizować wiele takich zmian równocześnie. Często jest tak, że klienci wewnętrzni IT nie mają w zwyczaju „synchronizować” swoich żądań między sobą (IT nazywa to „niespójnością celów biznesowych”), a zadania synchronizacji, często nakładających się lub wręcz sprzecznych żądań, spadają na pracowników IT. Nakłada się na to narastająca niechęć „Biznesu” do finansowania firmowego IT, co jest po części uzasadnione na przykład zadziwiająco niską skutecznością i efektywnością IT, ale stanowi zupełnie oddzielną historię, podobnie jak nieumiejętność dogadania się obu stron (IT i klienta wewnętrznego) co do kształtu rozwiązań technologicznych, jakie pozwoliłyby na budowanie rozwiązań biznesowych o większej trwałości i użyteczności bazującej na wielokrotnym ich wykorzystaniu w różnych kontekstach.

Wracając jednak do środowiska informatycznego firmy i mnóstwa żądań wprowadzania do niego przeróżnych zmian, powstaje problem natury koordynacyjnej: jak przeprowadzić wdrożenie tych wszystkich zmian i zintegrować je ze środowiskiem informatycznym firmy tak, aby zminimalizować nakład sił i środków na ich realizację oraz zminimalizować zagregowane ryzyko reprezentowane przez każdą ze zmian z osobna i wykładniczo zwiększane przez wolumen zmian? Właśnie takimi zagadnieniami zajmuje się kompleks procesów, ról, zadań, narzędzi, dobrych praktyk i paru jeszcze innych rzeczy, które przyjęło się określać terminem Release Management (tłumaczenie na język polski, zarządzanie wydaniami, jest używane chyba jedynie przez purystów językowych). Wszystkie żądane zmiany (lub ich podzbiór) są zwykle realizowane niezależnie (bo jest ich dużo) i szybko (bo tego żąda klient wewnętrzny), czego efektem jest swoisty patchwork, a każda kolejna zmiana nakładana jest na istniejące już łatki, warstwa po warstwie tworząc jedną, nierozerwalną całość. Tak rodzi się „buła”, czyli środowisko systemów informatycznych firmy, które nie poddaje się już zarządzaniu z powodu swej złożoności i niemożności rozpatrywania jednego elementu w oderwaniu od pozostałych lub przynajmniej w kontekście nielicznych powiązań. Taki twór, powstały ewolucyjnie, ma tendencje do przeszkadzania w każdym aspekcie działalności rozwojowej środowiska informatycznego, co sprawia, że zaczyna być postrzegana jako inteligentna i złośliwa istota, a wręcz przypisywane są jej cechy z pogranicza teorii spiskowych. Prawda jest jednak taka, że złożoność wielowarstwowo i ewolucyjnie nakładanych łatek przerasta zwykle złożoność oryginalnych systemów informatycznych, a poprawność ich działania daje się rozpatrywać bardziej w sferze statystycznej niż deterministycznej. Co istotne, wolne tempo narastania „buły” usypia zwykle czujność odpowiedzialnych za IT w firmie, a przebudzenie wynika zwykle z poważnego kryzysu wynikającego z niemożności wdrożenia czegoś szczególnie ważnego w istotnie krótkim czasie. W takich sytuacjach próbuje się wynajdywać jakieś rozwiązania tych problemów, stosując to, co w danej chwili jest „bardziej pod ręką”, co prowadzi do wielu – jak to nazywają naukowcy – ciekawych przypadków.

Pierwsza patologia wyrasta na gruncie inżynierii systemowej, gdzie stosowanym rozwiązaniem dla przypadków żądań zmian było… zarządzanie zmianą typu One Size Fits All. Podejście do prowadzenia działań Release Management w takim samym stylu zarówno dla dużych, fundamentalnych zmian architektonicznych jak i dla małych modyfikacji pojedynczych aplikacji wymaga wypracowania „standardowych” przepisów na zarządzanie zmianą i sprawia, że w większości przypadków stosowane są nieadekwatnie skromne zabezpieczenia w odniesieniu do rewolucyjnych więc ryzykownych operacji oraz nieprzystająco rozbudowane metody kontrolne do małych więc bezpiecznych zmian ewolucyjnych. W ten sposób, pomimo wzrostu nakładu sił i środków na działalność IT, traci się zarówno na bezpieczeństwie jak i na efektywności wprowadzania zmian.

Inna patologia, wyrastająca zwykle z fascynacji „instytucją” projektu, polega na traktowaniu absolutnie wszystkiego jak projektu. Każdy projekt jest w takich okolicznościach niezależny i jest obłożony niezależną (czyt. konkurującą o zasoby) strukturą zarządczą. Każdy musi więc „utorować” sobie  drogę do wdrożenia, a więc pozwala się mu na realizację swojego własnego pomysłu na Release Management. Bezpośrednią konsekwencją takiego podejścia jest przeniesienie konfliktu żądań zmian z obszarów organizacyjnych relacji między klientami wewnętrznymi IT do obszarów ściśle technologicznych rozwoju oprogramowania i utrzymania systemów informatycznych. W ten sposób nie rozwiązuje się żadnych problemów, a jedynie tworzy nowe.

Jeszcze inna patologia, wyrastająca na gruncie książkowej wiedzy i wyidealizowanego, punktowego podejścia do wdrażania metod zarządzania IT, zasadza się na myśleniu typu „Release Management dobry na wszystko”. Podejście to polega na ustanowieniu odpowiedzialności za Relase Management w taki sposób, że degeneruje się lub wręcz zanika odpowiedzialność za inne elementy wprowadzania zmian do środowiska systemów informatycznych firmy, np. odpowiedzialność za jakość tworzonego oprogramowania (niezależnie czy wewnętrznie, czy przez zewnętrznych dostawców), odpowiedzialność za weryfikację i testy, odpowiedzialność za architekturę korporacyjną i systemową, czy odpowiedzialność za skuteczność zarządzania wdrażaniem poszczególnych zmian. Pierwotna myśl „Release Management dobry na wszystko” szybko przemienia się w „Release Management winny wszystkiemu”.

Przykładów takich patologii, większych lub mniejszych, można mnożyć, ale nie o to chodzi, aby utyskiwać. :-) Ważne jest to, aby dobrać rozwiązania organizacyjne do problemów i skali trudności, zaczynając od przyznania się (przed samym sobą), że sytuacja przerosła zdolności wewnętrznych struktur IT. Istnieją zarówno klasyczne, jak i innowacyjne rozwiązania dla takich sytuacji, choć w swej sterylnej formie występują one jedynie w literaturze. Na bazie takich wyidealizowanych pomysłów na realizację Release Management daje się jednak wypracować coś, co wypełnia stawiane cele co najmniej trochę lepiej, niż dotychczasowe praktyki (zwykle jest to istotna różnica).

Podejście „klasyczne” do wdrożenia praktyk Release Management opiera się na doświadczeniach skodyfikowanych na przykład w postaci IT Infrastructure Library, a dokładniej składowej ITIL Service Transition. W tym podejściu wprowadza się dodatkowy proces zarządczy, którego celem jest synchronizacja punktów kontrolnych wdrażania różnych zmian i wspólne prowadzenia ich testowania, weryfikacji i wdrożenia. Taki proces przeprowadza się co pewien czas (np. co kilka miesięcy), a przedmiotem działań jest duża porcja zmian w systemach informatycznych, liczona nawet w tysiącach osobodni pracy analityków, programistów i testerów. ITIL definiuje proces, role, zadania, odpowiedzialność, narzędzia wsparcia i powiązania Release Management z innymi obszarami operacyjnego zarządzania IT. Na pierwszy rzut oka bardzo przegadane, ale polecane dla organizacji IT, które dotąd nie miały do czynienia z zagadnieniami Release Management, a odczuwają już skutki nie do końca uporządkowanej sytuacji w tym obszarze.

O ile „klasyczne” podejście wyrasta z tradycyjnego myślenia o rozwoju oprogramowania (wodospad) o tyle podejście „innowacyjne” wynika z alternatywnego myślenia o tworzeniu oprogramowania – metod agile. To nowsze podejście bazuje na konstatacji, że zapewnienie odpowiedniego wsparcia dla realizacji celów biznesowych wymaga częstego wprowadzania małych zmian w różnych komponentach systemów informatycznych, czego wynikiem jest pewnego rodzaju stan płynności tego oprogramowania (nie mylić z niestabilnością). W takich sytuacjach, kiedy zmiany są wprowadzane np. co tydzień, nie dałoby się stosować machiny „klasycznego” podejścia do zagadnień Release Management. Podejście „innowacyjne” zakłada więc istnienie narzędzi aktualizacji oprogramowania takich, jakie stosuje Microsoft, HP, czy Symantec i usuwa ze słownika pojęcie wydania pakietu oprogramowania. Fanów podejścia agile nie trzeba do tego przekonywać, a przeciwników nie przekonam i tak. :-) O takim podejściu pisał konsultant Cutter Consortium, Israel Gat.

W każdej firmie o odpowiednio rozbudowanym środowisku informatycznym problem zarządzania wprowadzaniem zmian do produkcyjnych systemów ujawni się prędzej lub później, przez problemy (a czasem katastrofy) i objawy uboczne. Rozwiązanie takich problemów wymaga dobrania odpowiednich metod i narzędzi, przy czym największą rolę odgrywa tu zastana kultura IT w zakresie rozwoju oprogramowania. Biorąc pod uwagę ten czynnik oraz pamiętając, że – w takim, czy innym rozwiązaniu – działania architektoniczne, rozwoju oprogramowania i zarządzania wydaniami muszą współdziałać w taki sposób, aby zmierzać w tym samym celu, udaje się zwykle uzyskać istotne efekty poprawy.

W razie wątpliwości, jestem do dyspozycji!

komentarze 2 dla

  1. Tomasz napisał(a):

    Świetny artykuł.

  2. Sebastian Konkol napisał(a):

    Bardzo dziękuję!

Pozostaw komentarz