Niepowodzenie zwrotu z inwestycji w modernizację chmury: luka w obserwowalności, której nikt nie planował

Globalne przedsiębiorstwa są na dobrej drodze do wydania ponad biliona dolarów na usługi chmury publicznej do 2026 roku. Biznesowe uzasadnienie tych wydatków opiera się na prognozach, które wahają się od obiecujących po niezwykłe: badania IDC pokazują, że organizacje, które skutecznie przeprowadzą modernizację, mogą osiągnąć zwrot z inwestycji na poziomie 334% w ciągu trzech lat i dziesięciomiesięczny okres zwrotu. Benchmarki AWS wskazują na 43% wzrost przychodów i 33% redukcję wydatków na IT w przypadku w pełni zmodernizowanych obciążeń. Liczby są realne. Reprezentują one możliwe do osiągnięcia rezultaty. Problem w tym, że większość organizacji ich nie osiąga.

Dane PwC pokazują, że 54% przedsiębiorstw deklaruje minimalną wartość inwestycji w chmurę, pomimo rosnącej adopcji. Flexera stwierdza, że ​​84% organizacji uznaje widoczność kosztów za priorytet, a jednocześnie tylko 38% aktywnie śledzi zwrot z inwestycji w chmurę w poszczególnych jednostkach biznesowych. Gartner podaje, że budżety na chmurę przekraczają prognozy średnio o 17%. Różnica między obietnicami modernizacji chmury a rzeczywistymi doświadczeniami organizacji nie jest awarią technologiczną. To awaria widoczności, która zaczyna się na długo przed przeniesieniem pierwszego obciążenia.

Niewygodna prawda o niepowodzeniu modernizacji chmury

Organizacje wydają miliardy na migracje do chmury, a mimo to wiele z nich nie osiąga obiecanego zwrotu z inwestycji (ROI). Przenoszenie obciążeń do chmury bez dbania o widoczność operacyjną, niekontrolowane koszty i rozproszone narzędzia potęgują problem. Warto zastanowić się nad zwrotem „potęguje problem”. Migracja do chmury nie neutralizuje długu technicznego, dług techniczny nie znika w chmurze; on się skaluje.

Schemat awarii jest spójny w różnych branżach. Zespoły wdrażają Kubernetes i architekturę opartą na usługach bez obserwowalności, dojrzałości CI/CD ani spójności zespołowej, która by je wspierała. Rezultat: rozproszony monolit o złożoności operacyjnej, ale bez żadnych korzyści. Organizacja, która migruje starszy monolit bez zrozumienia jego wewnętrznej struktury, zależności i przepływów danych, nie zyskuje elastyczności w chmurze. Zyskuje rachunki za chmurę, a jednocześnie te same problemy architektoniczne, których próbowała uniknąć.

Najważniejszym wnioskiem płynącym z nieudanych programów jest to, że awarie mają głównie charakter organizacyjny, a nie techniczny. Technologia działa. Struktury organizacyjne, motywacje i procesy decyzyjne często zawodzą. Niejasna struktura własności, błędne wskaźniki KPI oraz zespoły pozbawione uprawnień i umiejętności wykonawczych – oto przyczyny awarii, które ujawniają się w analizach post mortem. Jednak za każdą awarią organizacyjną kryje się awaria informacyjna: migracja została zaplanowana bez dokładnej wiedzy o tym, co jest migrowane.

Czym właściwie jest luka obserwowalności

Obserwowalność w kontekście chmury oznacza zdolność do zrozumienia stanu wewnętrznego systemu na podstawie jego zewnętrznych danych wyjściowych, a także do odpowiedzi na pytanie „co się dzieje i dlaczego” na podstawie danych telemetrycznych. Obserwowalność różni się od monitorowania. Monitorowanie powiadamia o dostępności usługi. Obserwowalność dostarcza informacji o przyczynie, pierwszej uszkodzonej granicy usługi oraz o łańcuchu zależności między usługami w momencie awarii.

Luka w obserwowalności w programach modernizacji chmury nie dotyczy przede wszystkim danych telemetrycznych, metryk, logów i śladów w czasie wykonywania po wdrożeniu aplikacji. Chodzi o wcześniejszą, bardziej znaczącą lukę: brak strukturalnej widoczności aplikacji przed rozpoczęciem migracji.

Ta wcześniejsza luka w obserwowalności ma trzy wymiary:

Co tak naprawdę zawiera aplikacja. Dokumentacja opisuje, do czego system został zaprojektowany. Rzeczywista baza kodu odzwierciedla piętnaście lat zmian, obejść i nieudokumentowanych decyzji, których nie uwzględnia żaden diagram architektury. Plan migracji oparty na dokumentacji to plan migracji oparty na niekompletnej mapie.

Sposób, w jaki komponenty łączą się ze sobą. Zależności między modułami, usługami i systemami determinują kolejność migracji, ryzyko i rzeczywisty zakres każdej proponowanej zmiany. Organizacje, które definiują możliwości chmury poprzez inicjatywy silosowe, a nie poprzez transformację całego portfolio, dostrzegają korzyści z nowych wdrożeń niwelowane przez bieżące wydatki na niezmienione systemy. Ocena silosowa zapewnia zrozumienie w silosach, a migracje pozwalają na wykrycie zależności między komponentami w trakcie realizacji, gdy odkrycie jest najbardziej kosztowne.

Na co migracja faktycznie wpłynie. Bez modelu zależności strukturalnych ocena wpływu jest jedynie szacowaniem. Oszacowanie wpływu generuje plany migracji o nieznanym zakresie. Nieznany zakres to miejsce, w którym prognozy zwrotu z inwestycji w chmurę przestają działać.

Gdzie powstaje luka: przed, w trakcie i po migracji

Przed migracją: iluzja oceny

Większość programów migracji do chmury rozpoczyna się od fazy oceny. Pierwsze 90 dni koncentruje się na ocenie: inwentaryzacji zasobów danych, ocenie gotowości do obsługi AI, linii bazowej FinOps oraz analizie luk w zarządzaniu. Brzmi to systematycznie. W praktyce ocena jest prawie zawsze powierzchowna, jeśli chodzi o kod aplikacji.

Narzędzia do wykrywania infrastruktury inwentaryzują serwery. Narzędzia do skanowania portfolio generują wyniki złożoności. Jednak faktyczna analiza strukturalna kodu aplikacji, czyli jakie funkcje istnieją, jak się wzajemnie wywołują, które komponenty współdzielą dane za pośrednictwem plików lub baz danych, a nie jawnych interfejsów API, który kod jest martwy i można go całkowicie wykluczyć z zakresu, jest rzadko przeprowadzana, ponieważ narzędzia do jej przeprowadzania w całym portfolio języków korporacyjnych nie są częścią standardowego zestawu narzędzi dostawców migracji.

Brak obserwowalności od pierwszego dnia. Dodanie pulpitów nawigacyjnych dotyczących stanu rurociągu, jakości danych i kosztów po uruchomieniu kosztuje trzy razy więcej niż ich wbudowanie. Ta sama zasada dotyczy strukturalnej obserwowalności portfolio aplikacji: koszt wykrycia złożoności architektonicznej po rozpoczęciu migracji jest wielokrotnością kosztu wykrycia jej przed jej rozpoczęciem.

Podczas migracji: problem odkrywania zależności

Najkosztowniejszym momentem w programie migracji do chmury jest moment, gdy zależność, która była nieznana przed migracją, zostaje odkryta w trakcie realizacji. Zespół zobowiązał się do przestrzegania harmonogramu. Infrastruktura została zapewniona. Umowy z dostawcami usług migracji są już podpisane. A potem, jako nieplanowane utrudnienie, pojawia się współdzielony podręcznik COBOL dołączony do 300 programów, wspólny schemat bazy danych, z którego odczytuje dane 12 usług, lub zadanie wsadowe, które przekazuje dane sześciu odbiorcom za pośrednictwem interfejsu plików.

Bez ujednoliconej obserwowalności i inteligentnej automatyzacji, modernizacja chmury często przenosi te problemy do bardziej złożonego, rozproszonego środowiska, zamiast je rozwiązywać. Monolit rozpada się na mikrousługi. Ukryte zależności między jego komponentami stają się wywołaniami sieciowymi między rozproszonymi usługami. Problem obserwowalności nie zostaje wyeliminowany, lecz rozproszony, co utrudnia jego dostrzeżenie.

Po migracji: załamanie widoczności kosztów

84% organizacji wskazuje zarządzanie wydatkami na chmurę jako swoje główne wyzwanie, a budżety przekraczają prognozy o 17%. Jednocześnie 69% liderów IT zgłasza przekroczenia budżetów w wydatkach na chmurę.

Przekroczenia kosztów chmury wynikają bezpośrednio z luki w obserwowalności przed migracją. Obciążenia, które były szacowane jako proste kandydaty do wdrożenia metody „lift-and-shift”, okazują się wymagać refaktoryzacji. Aplikacje o małym zakresie generują wysokie koszty transferu danych, ponieważ nikt nie zmapował przepływów danych w górę i w dół podczas oceny. Martwy kod, który został zmigrowany wraz z kodem rzeczywistym, działa w kontenerach, gdzie rozliczanie odbywa się na podstawie milisekundy. Mierzenie czasu sprawności systemu zamiast wyników biznesowych oznacza, że ​​zespoły optymalizują go pod kątem niewłaściwych rezultatów.

Flexera podaje, że tylko 38% aktywnie śledzi zwrot z inwestycji w chmurę w różnych jednostkach biznesowych. Organizacje nie mogą śledzić zwrotu z inwestycji, którego nie potrafią zmierzyć, ani mierzyć go w odniesieniu do poziomu bazowego, którego nie ustaliły dokładnie przed rozpoczęciem migracji.

Strukturalna obserwowalność, której potrzebują programy migracyjne

Zniwelowanie luki w obserwowalności wymaga innego rodzaju analizy niż ta, którą zapewnia odkrywanie infrastruktury. Wymaga ona analizy rzeczywistego kodu źródłowego każdej aplikacji w zakresie migracji i zbudowania modelu strukturalnego, który reprezentuje:

Pełna inwentaryzacja. Każdy program, funkcja, moduł, kopia zapasowa, schemat, strumień zadań i procedura, w tym te, których nie ma w dokumentacji, co w dużych środowiskach korporacyjnych często stanowi 20–30% rzeczywistej liczby.

Mapowanie zależności międzyjęzykowych. W jaki sposób usługa Java łączy się z programem COBOL, który odczytuje dane z tabeli DB2 wypełnianej przez zadanie wsadowe JCL. Zależności wykraczające poza granice językowe to te, których narzędzia infrastrukturalne nie dostrzegają i które generują najkosztowniejsze niespodzianki związane z migracją.

Identyfikacja martwego kodu. Komponenty bez odwołań przychodzących z jakiejkolwiek ścieżki produkcyjnej mogą zostać całkowicie wyłączone z zakresu migracji. Modernizacja starszych systemów w 2026 roku wymaga przejścia od sztywnych, monolitycznych systemów do nowoczesnych, zwinnych i skalowalnych architektur, ale migracja martwego kodu do chmury generuje rachunki za infrastrukturę chmurową, która nie służy celom produkcyjnym.

Klasyfikacja złożoności. Komponenty o wysokiej złożoności i wysokim stopniu sprzężenia są kosztowne w migracji i najbardziej narażone na przekroczenie kosztów. Ich identyfikacja podczas oceny, a nie odkrywanie w trakcie realizacji, stanowi różnicę między budżetem migracji z odpowiednim zabezpieczeniem awaryjnym a budżetem opartym na optymistycznych założeniach.

Zakres wpływu każdej proponowanej zmiany. Zanim jakikolwiek komponent zostanie zmodyfikowany, poddany refaktoryzacji lub przeniesiony, model strukturalny odpowiada na pytanie: na co jeszcze wpłynie? Ta odpowiedź przekształca nieznane ryzyko w ustrukturyzowaną, wyliczalną listę komponentów wymagających walidacji.

Dlaczego luka w obserwowalności jest większa w przypadku systemów starszych i komputerów mainframe

Środowiska chmurowe, które rozrastają się poprzez szybką, niekontrolowaną migrację, kumulują ryzyko w lukach między narzędziami, zespołami i odpowiedzialnością. Dla organizacji migrujących nowoczesne portfolio aplikacji internetowych ta luka jest znacząca. Dla organizacji migrujących obciążenia komputerów mainframe, COBOL, JCL, PL/I, RPG, często ma ona decydujące znaczenie.

Aplikacje mainframe kumulują złożoność, której nie jest w stanie ujawnić żadne skanowanie infrastruktury. Logika biznesowa osadzona w akapitach COBOL, modyfikowana przez kilkunastu programistów przez trzydzieści lat. Strumienie zadań JCL z warunkowymi ścieżkami wykonywania, działające tylko w określonych warunkach biznesowych. Kopie dokumentów dołączane do setek programów jednocześnie, gdzie pojedyncza zmiana nazwy pola wpływa na każdy program w łańcuchu. Zbiory danych, które służą jako niejawne kontrakty danych między programami, które nigdy nie wywołują się jawnie.

Metoda „lift-and-shift” odpowiada za większość niepowodzeń modernizacji. Zmiana platformy bez rearchitektury jedynie przenosi dług techniczny. Jest to szczególnie istotne w przypadku obciążeń komputerów mainframe. Konwersja programu COBOL do Javy bez zrozumienia jego wewnętrznej struktury, zależności i przepływów danych generuje kod Java z tymi samymi problemami strukturalnymi, co COBOL, ale teraz działający w infrastrukturze chmurowej, która generuje ciągłe rozliczenia.

Aby możliwe było strukturalne obserwowanie tej luki w przypadku komputerów mainframe i portfolio wielojęzycznych, potrzebne są narzędzia, które jednocześnie rozumieją wszystkie języki w środowisku i potrafią śledzić zależności między granicami językowymi, tworzące najbardziej niebezpieczne martwe pola.

Połączenie FinOps: Nie możesz rządzić tym, czego nie widzisz

FinOps to dyscyplina zarządzania finansami, która przypisuje odpowiedzialność za wydatki na chmurę na poziomie zespołu i obciążenia, zastępując nieprzejrzyste fakturowanie szczegółowym i praktycznym zarządzaniem kosztami. Każda struktura FinOps, zarządzanie tagami, rozliczanie i rozliczanie kosztów, optymalizacja zarezerwowanej pojemności, opiera się na wiedzy o tym, co jest wykorzystywane i jakie są koszty jego eksploatacji.

Organizacje, które ponoszą porażkę w FinOps, to te, które nie stworzyły inwentaryzacji strukturalnej przed migracją. Nie potrafią precyzyjnie oznaczyć zasobów, ponieważ nie wiedzą, do którego obciążenia należą. Nie potrafią przypisać odpowiedzialności za koszty, ponieważ własność migrowanych komponentów nigdy nie została zdefiniowana w odniesieniu do rzeczywistej struktury komponentów. Nie potrafią odpowiednio dostosować rozmiaru zarezerwowanej pojemności, ponieważ nie wiedzą, które obciążenia są stabilne, a które zmienne, co wymaga zrozumienia funkcji obciążenia, a nie tylko jego zużycia zasobów.

Brakującym elementem jest strategia łącząca budżetowanie, obserwowalność i działania związane z migracją do chmury z istotnymi rezultatami, takimi jak rozwój firmy, doświadczenie użytkownika i czas wprowadzenia produktu na rynek. Takiego połączenia nie da się stworzyć bez fundamentu strukturalnego: dokładnego modelu zawartości portfolio aplikacji przed sporządzeniem planu migracji.

W jaki sposób SMART TS XL Zamyka lukę w zakresie obserwowalności przed migracją

SMART TS XL Zapewnia warstwę strukturalnej obserwacji, której wymaga ocena migracji do chmury, a której nie są w stanie wygenerować narzędzia do wykrywania infrastruktury. Analizując rzeczywisty kod źródłowy każdej aplikacji w portfolio, w językach COBOL, JCL, Java, Python, RPG, PL/I, SQL i językach nowoczesnych, buduje ujednolicony model zależności, który sprawia, że ​​to, co niewidoczne, staje się widoczne przed rozpoczęciem migracji.

Analiza modernizacji starszych systemów rozpoczyna się od pełnej inwentaryzacji: każdego programu, kopii zapasowej, schematu i strumienia zadań w środowisku, w tym komponentów pominiętych w dokumentacji. Jest to rzeczywisty zakres migracji, wyznaczony na podstawie kodu, a nie szacunków.

Mapowanie zależności aplikacji śledzi każdą relację międzykomponentową w obrębie każdej granicy językowej – usługę Java, która wywołuje program COBOL odczytujący dane z tabeli DB2, którą wypełnia zadanie wsadowe JCL. Ten graf zależności międzyjęzykowych stanowi podstawę sekwencjonowania fal migracji: komponenty bez zależności od komponentów nadrzędnych migrują jako pierwsze; komponenty, od których wiele innych komponentów jest zależnych, migrują jako ostatnie, po przygotowaniu komponentów zależnych.

Funkcja analizy wpływu przekształca graf zależności w praktyczne planowanie migracji: zanim jakikolwiek komponent zostanie przeniesiony lub poddany refaktoryzacji, należy wyliczyć wszystkie pozostałe komponenty, na które będzie to miało wpływ, określić zakres prac walidacyjnych i zidentyfikować komponenty o najwyższym ryzyku migracji. To przekształca podejście „rozwiążemy to w trakcie realizacji” w ustrukturyzowany, oparty na dowodach program z określonym zakresem na każdym etapie.

Funkcja wyszukiwania w przedsiębiorstwie sprawia , że ​​pełny model strukturalny można przeszukiwać w trakcie całego programu migracji: można znaleźć każde użycie konkretnej funkcji, każdy program odczytujący z określonego zestawu danych, każdy komponent, na który wpłynie zmiana schematu, w ciągu kilku sekund, w milionach wierszy kodu w dowolnej kombinacji języków. To właśnie ta funkcja wyszukiwania sprawia, że ​​model strukturalny jest użyteczny w trakcie wieloletniego programu migracji, zamiast stać się jednorazowym artefaktem oceny, który z czasem traci na aktualności.

Likwidacja luki przed otwarciem budżetu

Dyrektorzy ds. informatyki (CIO), którzy osiągają największe wyniki w tym środowisku, niekoniecznie dysponują największymi budżetami na modernizację. To oni potrafią precyzyjnie określić koszt braku działania, jak i koszt działania. Ta sama precyzja dotyczy luki w obserwowalności. Pytanie nie brzmi, czy analiza strukturalna przed migracją jest czasochłonna i kosztowna. Owszem, jest. Pytanie brzmi, czy ten koszt jest mniejszy niż koszt wykrycia złożoności strukturalnej podczas migracji, który w każdej organizacji, która przeprowadziła ten eksperyment, jest konsekwentny.

Przedsiębiorstwa, które zdefiniują kolejną dekadę, to nie te, które wdrożyły najwięcej technologii. To te, które zrozumiały, do czego tak naprawdę służy ich technologia. Zwrot z inwestycji w modernizację chmury nie jest kwestią chmury. To kwestia wiedzy. Czy wiesz, co zawiera Twoje portfolio aplikacji? Czy wiesz, jak łączą się jego komponenty? Czy wiesz, jaki wpływ będzie miała zmiana dowolnego komponentu? Organizacje, które potrafią odpowiedzieć na te pytania przed rozpoczęciem migracji, to te, których programy modernizacji chmury przynoszą zwrot z inwestycji przewidziany w uzasadnieniu biznesowym. Pozostałe odkrywają lukę w swoich rachunkach za chmurę.