ITIL Service Value Chain

Dzisiaj krótko omówimy najbardziej widoczne różnice różnice pomiędzy ITIL v. 3 i v.4. oraz przymierzymy nowy koncept do zwinnych metodyk zarządzania projektami.

Wśród największych mankamentów poprzedniej wersji na pewno należy wspomnieć o braku wsparcia dla takich ram projektowych jak DevOps, Lean czy Agile. Można nawet stwierdzić, że powiązanie usług z procesem wytwórczym oprogramowania było jedynie zarysowane, stawiało wyraźny podział pomiędzy wytwarzaniem, a utrzymaniem (design – transition – operation). Ten podział w nowej wersji został wyraźnie zasypany i zespolony z zastosowaniem podejścia DevOps. W wersji 3, doskwierał również brak jakichkolwiek odwołań do tzw. „nowych technologii” ( BigData, Cloud, RPA czy Machine Learning). Czyli usługi były opisywane w ramach świata, który praktycznie już przestaje istnieć.

Nowa odsłona likwiduje ten „dług technologiczny” po swojej poprzedniczce.

Znacznemu podkreśleniu uległa również rola klienta w całym cyklu życia usługi, wskazano nie tylko konieczność większego angażowania go w cykl utrzymania i rozwoju usług, ale zaangażowanie go już na bardzo wczesnym etapie określania potrzeb, a nie szukaniu rozwiązań.

Ze standardu koncentrującego się na cyklu życia usług, staje się metodyką skupiającą się na tworzeniu, zarządzaniu i zwiększaniu ich wartości. Nie sądzę, żeby znalazł się ktoś próbujący negować takie podejście, gdyż w praktyce tak właśnie patrzy się na usługi, a przecież ITIL to zbiór najlepszych praktyk, a nie zbiór hipotez do wytestowania.

Service Value System

Wiele miejsca poświęcono tzw. „miękkiemu zarządzaniu” i kulturze organizacyjnej. Sama definicja usługi uległa znacznej transformacji. Nie mówimy już o jej dostarczaniu ale o współtworzeniu jej wartości. To jedna z najbardziej spektakularnych i istotnych zmian.

ITIL a zwinne metodyki wytwórcze

Przyczyny tego stanu rzeczy wydają się wbrew pozorom dość oczywiste, od kilku lat obserwujemy, być może nie masowy, ale jednak stosunkowo trwały trend przenoszenia rozwiązań informatycznych z lokalnych serwerowni do tzw. „chmury”. To musi skutkować odmiennym spojrzeniem na procesy ITSM. Najwięksi rynkowi gracze oferują usługi chmurowe, a także propagują model SaaS, praktycznie w całości przejmują obsługę administracyjną rozwiązań, w tym kwestie związane z dostępnością, pojemnością, usuwaniem incydentów czy problemów.

Drugim niezwykle istotnym czynnikiem jest radykalna zmiana w podejściu do wytwarzania oprogramowania, dzisiaj najwyższym stopniu podium znajduje się szybkość dostarczania rozwiązań, która często decyduje o tym czy będziesz liderem, challengerem czy outsiderem. Zmiany technologiczne galopują w takim tempie, że wartościowe narzędzia programistyczne bywają wypierane przez „lepsze”, zanim jeszcze na dobre zdążą okrzepnąć.

Przy takim stanie rzeczy stabilność i jakość rozwiązań, która jest bólem głowy zespołów utrzymujących systemy (często stosujące w jakimś zakresie ITIL), zaczyna być traktowana przez zespoły developerskie jako zbędna biurokracja, utrudniająca pracę i uniemożliwiająca szybkie „podsunięcie główki do pogłaskania” przez firmowych decydentów.

W związku z tym rodzi się pytanie czy możliwe jest pogodzenie DevOps z ITIL? Czy te dwa rozwiązania się wykluczają, czy możliwy jest efekt synergii przy ich zastosowaniu? Czy DevOps, który jest przedstawiany jako panaceum na zakończenie odwiecznej potyczki pomiędzy developerami i adminami nie pokryje obszaru operacji? Odpowiedź jest prosta – nic na to nie wskazuje.

DevOps-owymi bożkami są CI (Continuous Integration) i CD (Continuous Delivery), czyli mówiąc krótko „wgrywamy software na produkcję i niech sobie działa”. To czego brakuje w tym koncepcie już na pierwszy rzut oka, to coś co moglibyśmy nazwać (gdyby istniało) CO czyli Continuous Operation. Przecież każde rozwiązanie informatyczne po „uprodukcyjnieniu” trafia do utrzymania, gdzie spędza największą część swojego elektronicznego „życia”. Czy wszyscy o tym zapomnieli? ITIL o tym pamięta!

Podobnie jak SCRUM, nie jest kompletną metodyką zarządzania projektami, a skupia się jedynie na najbardziej efektywnych metodach wytwarzania oprogramowania. Zgodnie z definicją „Scrum to ramy postępowania, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów ….. . Definiuje jedynie ogólne reguły postępowania, w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik. „ (cyt. Scrum Guide), tak DevOps nie proponuje żadnych pomysłów na zarządzanie operacyjne już wytworzonym produktem.

Brak strategii, kontroli, monitorowania, dbania o jakość, zdefiniowanych ról i odpowiedzialności musi doprowadzić w końcu do ogólnego bałaganu czasami nawet utraty kontroli nad tym co mamy, świadomości do czego to służy i jaką powinno przynosić wartość. Dlatego zdecydowanie DevOps i ITIL należy traktować jak komponenty połączonego procesu wytwórczo-utrzymaniowego.

ITIL nadal zdaje się być najlepszą kodyfikacją obsługi procesów biznesowych, które stanowią podstawę operacji IT. Dostarcza wiedzę i metody działania potrzebne do tego, aby operacje IT wspierały strumień pracy w stylu DevOps.

Chmura, kontenery oraz inne nowe technologie i platformy powodują, że zespół operacyjny odpowiedzialny za obsługę zmian aplikacji, obiektów i scenariuszy operacyjnych nie może już polegać na ręcznym tworzeniu zleceń pracy, ręcznym wyzwalaniu itp. ITIL v.4 to rozumie i podpowiada jak można to dynamicznie, ale także efektywnie obsługiwać.

Spójrzcie (poniżej) na zestawienie ITIL-owych pryncypiów z kultowym manifestem agile. Łatwo możemy zauważyć, że co najmniej pięć z nich bezpośrednio referuje do deklaracji wspólnych zasad dla zwinnych metod tworzenia oprogramowania.

Agile Manifesto vs ITIL guiding principles

Jak więc widać Agile i DevOps ma wiele punktów styku z najnowszą wersją ITIL. Agile to adaptacyjne podejście do wytwarzania wartościowych produktów, oparte o częste zbieranie informacji zwrotnych i błyskawiczne dostosowywanie kierunku rozwoju produktu do najbardziej aktualnych uświadomionych potrzeb. Jednocześnie, co również istotne promujące autonomię w zespołach i bliską współpracę a klientem. DevOps dostarcza oprogramowanie do środowisk produkcyjnych, koncentrując się na ujednoliceniu operacji technicznych i rozwoju.

ITIL 4 znakomicie uzupełnia ten duet o procesy związane z utrzymaniem.