Dlaczego „wdrażanie” praktyk DevOps się nie udaje bądź udaje jedynie częściowo?

W jednym z naszych wcześniejszych artykułów opisywaliśmy czym DevOps tak naprawdę jest. Jeśli ktoś jeszcze nie miał okazji się zapoznać, to serdecznie zapraszam.

Dziś, z biegiem czasu DevOps stał się bardzo powszechny w świecie IT i nie tylko. Biznes również coraz częściej uczestniczy w takich procesach i to nie tylko w roli beneficjenta, ale także aktywnego aktora. Powstały między innymi role takie jak inżynierowie, architekci, ewangeliści, coachowie - wszystko z dopiskiem DevOps. Powstały różne odmiany i rozszerzenia tej koncepcji: DevSecOps, SecDevOps, BizDevOps i wiele różnych innych kombinacji, głównie trzyliterowych, skrótów.

Wszystko wygląda z pozoru na doskonale zrozumiane, opisane i zabezpieczone pod kątem narzędzi, procesów, kompetencji i wszystkich pozostałych elementów klasycznych modeli operacyjnych. Znak nieskończoności lub jak kto woli "leżącą ósemkę" również prawie każdy kojarzy, a często nawet potrafi wyjaśnić i wymienić wszystkie, bądź niektóre jej fazy.

Często pytamy naszych klientów o tematykę DevOps. Większość jest z nią przynajmniej zaznajomiona, kojarzy na czym polega wielokrotnie wspominając o zatrudnionych przez siebie specjalistach DevOps, zbudowanych zespołach czy stosowanych praktykach. Najczęściej wymieniają oni: ciągłą integrację (ang. Continuous Integration), ciągłe wdrożenia (ang. Continuous Deployment) czy testy automatyczne. Kiedy jednak zagłębimy się w temat i zaczynamy rozmawiać o korzyściach jakie osiągają dzięki wdrożonym przez siebie praktykom. Często dowiadujemy się, że nie są one do końca mierzalne i nie mają przełożenia na wymierne korzyści dla organizacji. Możemy również usłyszeć, że były pewne próby, ale wrócono do starych i sprawdzonych metod, gdyż okazało się to zbyt skomplikowane bądź trudne do osiągnięcia. Podobne spostrzeżenia poczynił Gartner i jak twierdzi, tylko do końca obecnego roku aż 75% inicjatyw DevOps zakończy się porażką.

Skąd to wynika i dlaczego tak się dzieje oraz co możemy zrobić, aby tę tendencję odmienić? To kluczowe obecnie pytania, na które próbują odpowiedzieć organizacje wdrażające praktyki DevOps w swoich organizacjach.

Pierwszym powodem, dla którego tak się dzieje jest częsty brak kontekstu biznesowego. Co mamy przez to rozumieć? Mianowicie, DevOps jest traktowany bardzo często jako zmiana czysto techniczna, polegająca na wdrożeniu nowych narzędzi np. do skanowania kodu źródłowego czy zautomatyzowaniu dotychczas manualnego procesu (może to być proces instalacji webserwisów). Moglibyśmy tu wymieniać wiele innych pomysłów, które znamy z własnych projektów, bądź opowieści znajomych pracujących w branży IT. Wdrożenie tych wszystkich zmian wydaje się na pierwszy rzut oka jak najbardziej prawidłowe, jest jednak jedno "ale". Czy zastanawiamy się jaką korzyść biznesową przyniesie naszej firmie ta konkretna zmiana? Czy i w jaki sposób wpłynie ona na nasz biznes? To są pytania, których często sobie nie zadajemy, przez co w efekcie mamy lepsze narzędzia i procesy, ale bez przełożenia na wyniki naszej firmy.

Rozwiązanie tutaj znajdziemy w spojrzeniu na DevOps od strony biznesowej, skupiając się na wartości dla firmy dla naszych klientów. Każda inicjatywa, bez względu czy wydaje się z pozoru czysto techniczna, powinna mieć przełożenie na biznes w postaci zwiększenia zysków, minimalizacji ryzyka, skrócenia time-to-market czy zwiększenia satysfakcji użytkowników. W celu zwiększenia szans na powodzenie, powinniśmy do tego celu zaangażować biznes, marketing, ryzyko i inne obszary organizacji. Pozwoli to lepiej zrozumieć, w które obszary i praktyki DevOps warto inwestować, a które dla organizacji będą miały marginalne znaczenie.

"Narzędzia nie są rozwiązaniem problemu kulturowego" (ang. "Tools are not the solution to a cultural problem"). Jest to zdanie wypowiedziane przez George'a Spafforda z Gartnera, współautora książki "The Phoenix project", z którym się w pełni zgadzam. Obecnie dostrzegamy prześciganie się firm w kupowaniu nowych "zabawek" dla IT, które mają na celu zwiększenie przyspieszenie realizacji zgłoszeń, zwiększenie jakości wytwarzanego oprogramowania oraz jego bezpieczeństwa. Z tego typu narzędziami jest jednak jak z samochodem, powinny zostać dobrane zgodnie z potrzebami. Nie kupujemy przecież ciężarówki, żeby dojeżdżać nią do pracy, czy też odbierać dzieci ze szkoły. Innym aspektem jest wykorzystanie narzędzi w sposób odpowiedni i zgodny z przeznaczeniem. Jeśli nie zapewnimy odpowiedniej kultury pracy, kompetencji, procesów, wytycznych czy metryk możemy skończyć np. z automatycznie generowanymi raportami dotyczącymi podatności bezpieczeństwa, natomiast bez zrozumienia ryzyk z nimi związanych i potencjalnych skutków dla organizacji, a co za tym idzie, bez jakiejkolwiek akcji.

Na powyższe wyzwanie również istnieją rozwiązania. Kluczowa jednak jest identyfikacja osób i zbudowanie na tej podstawie zespołu, który będzie miał odpowiednie podejście, będzie działał jako zespół, a nie grupa indywidualności, który rozumie nie tylko technologię, ale również kontekst biznesowy, jest chętny do nauki i potrafi brać na siebie odpowiedzialność za wytwarzany produkt.

Kolejnym aspektem, na który warto zwrócić uwagę są realistyczne oczekiwania wobec DevOps. Niestety często zakładamy, że jest to "lek na wszystkie nasze problemy". Analogicznie było jeszcze kilkanaście lat temu z wdrażaniem metodyk zwinnych (ang. Agile), które traktowaliśmy jako Święty Graal i rozwiązanie wszystkich problemów związanych z tradycyjnymi metodami wytwarzania oprogramowania. Agile z czasem pod tym kątem dojrzał. Zaczęto go stosować bardziej z wyczuciem, dopracowano bardziej szczegółowe metodyki i ramy oraz lepiej wszyscy oswoiliśmy się z jego ograniczeniami. Obecnie stanowi on podstawę działania wielu organizacji, co więcej wiele firm nie wyobraża sobie innego podejścia do codziennej pracy niż właśnie zwinne. Podobnie dzieje się z DevOps oraz wszystkimi jego rozszerzeniami i nic w tym dziwnego, gdyż mają one wiele wspólnego z Agile Można by wręcz pokusić się o stwierdzenie, że DevOps to młodszy, bardziej techniczny brat Agile.

Jak więc podjąć powyższe wyzwanie? Przede wszystkim należy podejść do tematu w sposób iteracyjny, krok po kroku, analogicznie jak w Agile, gdyż nie ma jednego słusznego rozwiązania i wszystkiego nie będziemy w stanie zaplanować z wyprzedzeniem oraz wdrożyć na zasadzie „Big Bang”. Każda organizacja jest inna, stąd kluczowe jest rozpoznanie potrzeb naszej oraz wybór i dostosowanie poszczególnych praktyk, precyzując zarazem konkretne efekty biznesowe, jakie chcemy osiągnąć. Podczas wdrażania poszczególnych praktyk DevOps skupmy się na ich testowaniu, monitorowaniu efektów i reagowaniu na pojawiające się wyzwania. Im szybciej jesteśmy w stanie otrzymać informację zwrotną, która pozwoli nam dostosować kierunek zmian tym lepiej.

Ostatni czynnik, a tak naprawdę zestaw czynników, na które chciałbym zwrócić dziś szczególną uwagę to brak spójności podejścia do DevOps na poziomie organizacji. W większości przypadków DevOps traktowany jest jako quick-win, drobne usprawnienie bądź zestaw usprawnień w ramach zespołu, projektu, czasem działu, co z kolei powoduje szereg ograniczeń. Po pierwsze wypracowane metody, standardy, dobre praktyki, skuteczne procesy w jednym zespole nie są przekazywane do innych zespołów ani na poziom organizacji. Po drugie posiadamy w organizacji szereg narzędzi, z których każde adresuje jakieś pojedyncze zagadnienie niekoniecznie w sposób optymalny czy też spójny z metodami zaadaptowanymi w innych obszarach firmy. Kolejnym elementem jest struktura organizacyjna, potencjalnie zmieniamy narzędzia, które ułatwiają nam codzienne tworzenie oprogramowania, z drugiej jednak strony jesteśmy blokowani przez archaiczną strukturę organizacyjną, przez co teoretycznie moglibyśmy np. robić wydania nowych wersji oprogramowania na produkcję kilka razy dziennie natomiast nasz kalendarz wdrożeń, proces akceptacyjny lub wewnętrzne procedury tego zabraniają.

Zaadresowanie powyższego problemu wymaga kilku elementów m. in. zmiany myślenia i gotowości do zaadoptowania praktyk DevOps na poziomie zarządczym. Odpowiedniego planu, dzięki któremu w sposób kontrolowany będziemy podążać w kierunku sprecyzowanych przez nas celów i aspiracji, jak również strategii, choćby w kontekście narzędziowym, która zapewni odpowiednią spójność rozwiązań na poziomie całej organizacji.

Przechodząc do konkluzji, w przypadku DevOps to nie narzędzia są największym wyzwaniem, a jak się okazuje to na nich najbardziej się skupiamy podczas optymalizacji naszych procesów wytwórczych. Kluczowy jest aspekt kulturowy, ludzki, który musi objąć całą organizację - od zespołów wytwórczych po zarząd, budując odpowiednią świadomość nt. DevOps, jako kultury, podejścia, metodyki a nawet filozofii.

Jak możemy pomóc?

W dzisiejszych czasach firmy żyją zmianami. Nowe kanały, nowi klienci, nowe produkty, to wszystko wymaga ciągłego dostosowywania narzędzi IT. Nasz zespół postawił sobie jeden cel – sprawić, żeby nasi klienci nie tylko przeszli przez te zmiany niepoturbowani, ale by jak najlepiej wykorzystywali technologie do realizacji swoich celów biznesowych.

Pomagamy liderom IT oraz ich zespołom w procesie przemian technologicznych:

• Opracowujemy nowe modele operacyjne, procesy i struktury.
• Wspieramy w uruchamianiu praktyk architektonicznych i planujemy wspólnie z nimi mapy drogowe rozwoju systemów.
• Prowadzimy również organizacje poprzez zwinne transformacje, wspierając w uruchomieniu wcześniej wypracowanych koncepcji strategicznych.

Zapraszamy do kontaktu.