Google Cloud odrzuca wielki skok z mainframe na rzecz migracji wspieranej przez AI

Google Cloud przedstawił czteroetapową alternatywę dla ryzykownych migracji systemów mainframe, wykorzystując analizę AI, generowanie kodu, konwersję danych i równoległą walidację przed przełączeniem.

Propozycja podważa dobrze znany wybór. Przedsiębiorstwa mogą nadal utrzymywać starzejące się systemy albo podjąć próbę dużej migracji, w której zależności stają się widoczne dopiero po rozpoczęciu prac. Google twierdzi, że żadna z tych opcji nie rozwiązuje najtrudniejszego problemu: zrozumienia, co faktycznie robi istniejący system.

Odpowiedź firmy łączy Mainframe Assessment Tool, Gemini CLI, Mainframe Connector i Dual Run w jeden ciągły proces. Zespoły najpierw odtwarzają reguły biznesowe i zależności. Następnie budują aplikacje chmurowe na podstawie zweryfikowanych wymagań, przenoszą odpowiednie dane i porównują oba środowiska przy rzeczywistych obciążeniach.

Ta sekwencja sprawia, że jest to coś więcej niż kolejne ogłoszenie dotyczące konwersji kodu. Główna rywalizacja dotyczy iteracyjnej modernizacji kontra migracja typu big bang, a nie infrastruktury chmurowej kontra sprzęt mainframe.

Google mierzy się też z uznanymi alternatywami. IBM stosuje AI, jednocześnie zachowując centralną rolę IBM Z. AWS promuje usługę agentową, która śledzi wygenerowane wymagania i kod aż do źródeł mainframe. Każdy dostawca uznaje, że samo generowanie kodu nie wystarczy, by rozstrzygnąć, czy system zastępczy jest poprawny.

Kluczowe pytanie nie brzmi więc, czy Gemini potrafi przetłumaczyć COBOL. Chodzi o to, czy połączony przepływ pracy Google może zachować dekady ukrytych zachowań biznesowych, jednocześnie pozwalając przedsiębiorstwom modernizować się w możliwych do opanowania częściach.

Google Cloud łączy cztery narzędzia w jedną ścieżkę migracji

Istotną zmianą jest połączenie oceny, generowania, przenoszenia danych i walidacji produkcyjnej.

Platforma modernizacyjna Google zaczyna się od inżynierii wstecznej. Mainframe Assessment Tool analizuje kod źródłowy, struktury baz danych, monitory transakcji, konfiguracje harmonogramów i relacje między zasobami.

Obsługuje programy COBOL, copybooki, zadania JCL, procedury, pliki include i powiązane artefakty. Narzędzie wykorzystuje Gemini do generowania podsumowań, specyfikacji technicznych i proponowanych reguł biznesowych na podstawie tych materiałów.

Reguły biznesowe to zasady zakodowane wewnątrz aplikacji, takie jak warunki kwalifikacji, obliczenia odsetek czy decyzje dotyczące kierowania transakcji. Są ważne, ponieważ obserwowalne zachowanie starego programu często wykracza poza zachowaną dokumentację.

Google podaje, że zespoły mogą przeglądać, filtrować i walidować wyodrębnione reguły przed ich eksportem. Ten punkt kontroli z udziałem człowieka odróżnia propozycję od prostego polecenia przetłumaczenia każdej linii na Javę lub inny nowoczesny język.

Ocena może również podzielić środowisko na domeny biznesowe i mniejsze jednostki możliwe do migracji. Jednostka możliwa do migracji to ograniczony zbiór programów, danych i zależności, które mogą zostać przeniesione razem bez zakłócania sąsiednich usług.

Ten podział tworzy podstawę programu iteracyjnego. Bank może wyodrębnić jeden przepływ raportowania, zanim dotknie autoryzacji płatności. Ubezpieczyciel może przenieść usługę przetwarzania dokumentów, pozostawiając rozliczanie roszczeń na systemie mainframe.

Po ocenie Gemini CLI wspiera inżynierię postępową. Oznacza to, że zespoły wykorzystują zwalidowane wymagania do planowania architektury docelowej i generowania nowego kodu, zamiast traktować starą bazę kodu jako projekt docelowy.

Przepływ pracy może proponować modele danych i usługi w Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB i Cloud SQL. Propozycje te nadal wymagają przeglądu architektonicznego, ponieważ wygenerowana rekomendacja nie jest decyzją operacyjną.

Mainframe Connector obsługuje inny, często niedoceniany problem. Kopiuje i konwertuje dane mainframe, w tym rekordy kodowane w EBCDIC, do formatów, z których mogą korzystać usługi Google.

EBCDIC to kodowanie znaków związane ze środowiskami IBM mainframe. Jego poprawna konwersja wymaga czegoś więcej niż zmiany reprezentacji tekstu, ponieważ rekordy mogą zawierać liczby dziesiętne w formacie packed, układy copybooków i konwencje specyficzne dla aplikacji.

Dual Run domyka proponowaną pętlę. Uruchamia obciążenia w istniejącym środowisku mainframe i środowisku chmurowym, a następnie porównuje ich wyniki przed przełączeniem produkcyjnym.

Połączony proces zmienia miejsce, w którym zespoły lokują swoje zaufanie. Zamiast ufać jednorazowej konwersji, gromadzą dowody na etapach odkrywania, przeglądu reguł, implementacji, testowania danych i równoległego wykonywania.

To centralne twierdzenie tego wydarzenia. Google przedstawia modernizację jako kontrolowany system dowodów, a nie pojedynczy projekt transformacyjny.

Dlaczego modernizacja mainframe nie jest zadaniem tłumaczenia kodu

Konwersja poprawna składniowo może nadal odtworzyć niewłaściwy system biznesowy.

Duże środowiska mainframe rzadko zachowują się jak uporządkowane zbiory niezależnych aplikacji. Nocne zadanie wsadowe może aktualizować dane wykorzystywane następnego ranka przez transakcję online. Wspólny copybook może kształtować rekordy używane w kilku jednostkach biznesowych.

Część zależności znajduje się w kodzie. Inne są ukryte w harmonogramach, konwencjach baz danych, instrukcjach operacyjnych lub wiedzy pracowników, którzy utrzymywali dane obciążenie przez dziesięciolecia.

To sprawia, że bezpośrednie tłumaczenie kodu jest niepełnym modelem. Model językowy może wygenerować wiarygodną Javę z procedury COBOL, lecz nie dostrzec, dlaczego ta procedura działa po innym zadaniu. Może też zachować logikę, której firma już nie chce.

Przeciwne ryzyko jest równie poważne. Wygenerowany zamiennik może uprościć zachowanie, które wygląda na zbędne, ale obsługuje rzadki wyjątek regulacyjny. Taka porażka może ujawnić się dopiero podczas rzadkiej transakcji lub procesu końca kwartału.

Projekt Google, w którym ocena jest pierwszym krokiem, ma uczynić te relacje możliwymi do zbadania. Dokumentacja firmy mówi, że narzędzie tworzy drzewa wywołań, raporty zależności, podsumowania reguł biznesowych i proponowane jednostki możliwe do migracji.

System oceny obsługuje również serwer MCP, który pozwala agentom AI odpytywać dane oceny za pośrednictwem Model Context Protocol. MCP to standardowy interfejs do łączenia modeli z zewnętrznymi narzędziami i ustrukturyzowanym kontekstem.

Ta architektura daje Gemini coś więcej niż folder plików źródłowych. Może pracować z odkrytymi relacjami, zweryfikowanymi specyfikacjami i regułami biznesowymi przypisanymi do konkretnej domeny aplikacyjnej.

Bogatszy kontekst nie gwarantuje jednak trafnej interpretacji. Wygenerowane specyfikacje mogą pomijać przypadki brzegowe, a analiza statyczna nie może zaobserwować każdej zależności tworzonej przez konfigurację w czasie działania lub operacje zewnętrzne.

Przegląd przez człowieka pozostaje więc częścią mechanizmu. Eksperci dziedzinowi muszą zdecydować, czy proponowana reguła biznesowa jest prawidłowa, przestarzała, niepełna czy błędnie zrozumiana.

Tworzy to praktyczne ograniczenie dla przedsiębiorstw zmagających się z odpływem pracowników. Przepływ pracy najbardziej potrzebuje doświadczonych operatorów wtedy, gdy ich wiedzę najtrudniej zastąpić. AI może uporządkować ich przegląd, ale nie potrafi z mocą wsteczną dostarczyć brakującej pamięci instytucjonalnej.

Podejście Google zmienia także cel kodu legacy. Zamiast traktować każdą instrukcję jako coś, co należy zachować, zespoły mogą traktować środowisko jako dowód dotyczący zamierzonego zachowania biznesowego.

To rozróżnienie wspiera przeprojektowanie natywne dla chmury. Monitor transakcji nie musi mieć dosłownego odpowiednika, jeśli usługa zarządzana może spełnić ten sam zweryfikowany wymóg. Proces wsadowy może stać się usługą sterowaną zdarzeniami, gdy pozwalają na to ograniczenia czasowe i dotyczące spójności.

Przeprojektowanie zwiększa jednak obciążenie związane z walidacją. Im dalej architektura docelowa odchodzi od pierwotnej implementacji, tym mniej przydatne staje się porównanie linia po linii.

Zespoły muszą porównywać wyniki, skutki uboczne, czas, integralność danych i odzyskiwanie po awarii. Dlatego Dual Run jest centralnym, a nie opcjonalnym elementem narracji Google.

Obietnicą nie jest idealne tłumaczenie. Jest nią możliwy do prześledzenia łańcuch od dowodów z systemu legacy, przez zweryfikowane reguły i wygenerowaną implementację, po zmierzoną równoważność.

Prawdziwa rywalizacja to iteracyjna modernizacja kontra big bang

Najsilniejszy argument Google ma charakter organizacyjny: mniejsze jednostki migracji ograniczają konsekwencje niepewności.

Migracja typu big bang skupia wiele założeń w jednym przełączeniu. Zespoły muszą zrozumieć zależności, przekształcić kod, przenieść dane, przetestować interfejsy, przeszkolić operatorów i przygotować procedury wycofania zmian w szerokim zakresie.

Jedna błędnie rozpoznana zależność może opóźnić cały program. Co gorsza, wada może trafić na produkcję dopiero po tym, gdy odtworzenie pierwotnego środowiska stanie się trudne.

Iteracyjna modernizacja zmniejsza ten promień rażenia. Zespoły mogą wybrać ograniczoną domenę, udokumentować jej relacje, zbudować implementację docelową i zwalidować ją, podczas gdy sąsiednie obciążenia pozostają niezmienione.

Nie sprawia to, że modernizacja staje się prosta. Zmienia sposób, w jaki zachowuje się porażka.

Problem wykryty podczas jednej jednostki migracyjnej może ulepszyć zasady oceny dla następnej jednostki. Niezgodności w testach mogą ujawnić nieudokumentowane zachowanie, zanim przedsiębiorstwo zdecyduje się na szersze przełączenie.

Dual Run zapewnia pomost operacyjny. Wcześniejszy model testów równoległych Google utrzymuje mainframe jako system podstawowy, podczas gdy kopia chmurowa wykonuje to samo obciążenie jako system pomocniczy.

Dane wyjściowe z chmury można następnie porównać z ustalonym wynikiem. Powtarzające się różnice ujawniają defekty w przekształconej logice, konwersji danych lub założeniach środowiskowych.

Jest to szczególnie istotne dla systemów obsługujących dużą liczbę transakcji. Test jednostkowy może zweryfikować znane obliczenie, ale nie potrafi odtworzyć każdej interakcji między rzeczywistymi wzorcami wejściowymi, warunkami harmonogramowania i integracjami dalszego etapu.

Równoległe wykonywanie dostarcza szerszych dowodów bez natychmiastowego przyznawania nowemu systemowi uprawnień produkcyjnych. Zespoły mogą ustalać progi akceptacji, badać różnice i powtarzać testy przed przekazaniem odpowiedzialności.

Kompromisem jest przedłużone współistnienie. Uruchamianie dwóch środowisk wymaga synchronizacji, monitorowania, kontroli zduplikowanego przetwarzania i jasnej decyzji, który system odpowiada za każde wyjście.

Koszty mogą również nakładać się w okresie przejściowym. Google nie eliminuje tego obciążenia operacyjnego. Twierdzi, że obciążenie to zapewnia bezpieczniejszą drogę odejścia od wydarzenia typu wszystko albo nic.

Model przyrostowy wprowadza także kwestie zarządzania. Zespoły potrzebują zasad wyboru jednostek migracyjnych oraz decydowania, kiedy aplikacja wykazała wystarczającą równoważność.

Muszą śledzić, które reguły biznesowe zostały zaakceptowane, kto je zatwierdził, jakie dowody testowe je wspierają i co zmieniło się po walidacji. Bez takiego rejestru praca iteracyjna może stworzyć rozdrobnione hybrydowe środowisko.

Istotna jest tu dyscyplina architektoniczna. Sekwencja odizolowanych projektów chmurowych może odtworzyć złożoność mainframe poprzez nowe usługi, kolejki, bazy danych i nieudokumentowane interfejsy.

Narzędzia Google mogą mapować i generować artefakty, ale przedsiębiorstwo nadal potrzebuje spójnej architektury docelowej. Potrzebuje też planu wycofania każdego komponentu mainframe zastępowanego przez chmurę.

Podejście odnosi sukces, gdy iteracja prowadzi do kumulatywnego uproszczenia. Zawodzi, gdy każda zmigrowana jednostka dodaje kolejny trwały most z powrotem do środowiska legacy.

Dlatego rywalizacja nie dotyczy szybkości kontra ostrożność. Pospieszny big bang może zakończyć się spektakularną porażką, podczas gdy niekończący się program przyrostowy może zawieść po cichu.

Miara sukcesu to ukończona zdolność biznesowa. Każda jednostka migracji powinna osiągnąć zweryfikowane działanie produkcyjne i usunąć odpowiadającą jej odpowiedzialność systemu legacy.

Google Cloud mierzy się z IBM i AWS na innych warunkach

Wszyscy trzej dostawcy wykorzystują obecnie AI, lecz różnią się co do tego, gdzie powinno działać zmodernizowane obciążenie oraz jak ustala się równoważność.

Stanowisko IBM wychodzi od nieustającej wartości mainframe'ów. watsonx Code Assistant for Z wspiera rozpoznanie, wyjaśnianie, refaktoryzację, generowanie kodu, optymalizację i transformację, jednocześnie zachowując IBM Z jako ważne środowisko uruchomieniowe.

IBM twierdzi, że jego asystent potrafi wyjaśniać COBOL, PL/I, REXX, Assembler i JCL. Może również refaktoryzować wybrane programy do modułowych usług albo przekształcać COBOL w obiektową Javę.

Firmowe narzędzia modernizacyjne AI obejmują automatyczne testy jednostkowe weryfikujące równoważność semantyczną. Termin ten oznacza, że nowy kod powinien zapewniać to samo zamierzone zachowanie co oryginał, nawet jeśli zmienia się jego struktura.

To podejście może odpowiadać przedsiębiorstwom, które chcą poprawić praktyki programistyczne bez zobowiązania się do przeniesienia każdego obciążenia do chmury hiperskalowej. Pozwala również zespołom modernizować rozwiązania wokół mainframe'a, zamiast traktować tę platformę jak termin graniczny.

AWS zajmuje stanowisko bliższe chmurowemu celowi Google, lecz jego obecny przekaz kładzie nacisk na realizację agentową i śledzalność. AWS Transform for mainframe obejmuje ocenę, ekstrakcję reguł biznesowych, wymagania, generowanie kodu, testowanie i wdrożenie.

AWS twierdzi, że każdy wygenerowany wynik można prześledzić od wymagań do oryginalnego kodu źródłowego. Jego przepływ pracy agentowej integruje się również z agentami programistycznymi, takimi jak Kiro, oraz istniejącymi środowiskami programistycznymi za pośrednictwem otwartych protokołów.

Ta śledzalność adresuje tę samą lukę zaufania co Dual Run Google. Daje recenzentom ścieżkę audytu pokazującą, skąd pochodzi wymaganie lub wygenerowany komponent.

Wyróżnikiem Google jest połączenie oceny kontekstowej z konwersją danych i równoległą walidacją na poziomie obciążenia. Gemini pomaga w rozumieniu i generowaniu, a Dual Run testuje zachowanie względem obowiązującego systemu referencyjnego.

Nie są to wyraźnie rozdzielone kategorie produktów. IBM również oferuje rozpoznanie i testowanie. AWS także deklaruje automatyczną walidację równoważności funkcjonalnej. Każdy z dostawców rozszerza ofertę na cały cykl życia.

Presja konkurencyjna przesunie się więc w stronę dowodów wdrożeniowych. Kupujący muszą wiedzieć, które języki, harmonogramy, bazy danych, systemy transakcyjne i formaty danych obsługuje każdy przepływ pracy w ich środowisku.

Muszą również odróżniać możliwości produktu od realizacji usług. Programy mainframe często angażują integratorów systemów, wewnętrznych ekspertów, specjalistów dostawców oraz lata historii aplikacji.

Żaden model nie działa niezależnie od tej struktury realizacyjnej. AI może ograniczyć ręczną analizę, tworzyć projekty specyfikacji i generować kod, lecz decyzje integracyjne pozostają specyficzne dla każdego środowiska.

Kolejną kwestią jest uzależnienie od dostawcy. Wygenerowana architektura może preferować bazy danych, platformy obliczeniowe, systemy monitoringu i usługi AI jednego dostawcy.

Takie dopasowanie może uprościć wdrożenie. Może też podnieść koszty zmiany dostawcy, gdy firma później zmieni strategię chmurową lub zachowa obciążenia w kilku środowiskach.

Przedsiębiorstwa powinny więc oceniać artefakty, a nie tylko demonstracje. Eksportowalne reguły, czytelne specyfikacje, przenośne testy i śledzalne zatwierdzenia mają znaczenie także po początkowej transformacji.

Rynek zbliża się do modernizacji wspieranej przez AI. Nierozstrzygnięta rywalizacja dotyczy tego, gdzie ludzie weryfikują pracę, jak dostawcy mierzą równoważność i która platforma przejmuje rezultat.

Czego przepływ pracy AI Google Cloud wciąż nie może zagwarantować

Przepływ pracy ogranicza określone ryzyka migracyjne, ale nie dowodzi, że wygenerowane reguły biznesowe ani kod docelowy są poprawne.

Pierwsza niepewność pojawia się podczas rozpoznania. Analiza statyczna może identyfikować relacje w kodzie źródłowym i zadeklarowane wywołania, lecz zachowanie dynamiczne może zależeć od wartości w czasie działania, decyzji operatorów albo systemów zewnętrznych.

Podsumowanie wygenerowane przez AI może również brzmieć pewniej, niż pozwalają na to dowody. Recenzenci mogą zatwierdzić jasne wyjaśnienie, ponieważ jest czytelne, nawet gdy pomija rzadko wykonywaną gałąź.

Prowadzi to do błędu automatyzacji, który występuje, gdy ludzie nadmiernie ufają rekomendacji systemu. Dopracowana specyfikacja może zwiększać to ryzyko, ponieważ ukrywa niejednoznaczność obecnej w bazowym środowisku.

Własny przepływ pracy Google zachowuje etap przeglądu wyodrębnionych reguł. Przedsiębiorstwa powinny traktować ten etap jako mechanizm kontrolny, a nie punkt administracyjny.

Przegląd wymaga wskazanych właścicieli, powiązanych dowodów i jednoznacznych rozstrzygnięć. Reguła powinna zostać oznaczona jako zaakceptowana, odrzucona, zmieniona albo nierozstrzygnięta, zanim pokieruje wygenerowanym kodem.

Bezpieczeństwo dodaje kolejną warstwę. Google twierdzi, że Mainframe Assessment Tool przechowuje zebrane dane oceny w obrębie wdrożonej maszyny wirtualnej. Dokumentacja mówi również, że kod źródłowy jest przesyłany do Gemini Enterprise Agent Platform.

Ta sama dokumentacja stwierdza, że model nie jest wzbogacany informacjami wyodrębnionymi z tego kodu. Organizacje nadal muszą zweryfikować kontrolę regionalną, zasady dostępu, zachowanie retencji oraz wymogi umowne dotyczące ich obciążeń.

Testowanie również ma ograniczenia. Dual Run może wykrywać różnice między obserwowanymi wynikami, lecz równoważność zależy od pokrycia i jakości porównań.

Jeśli oba środowiska otrzymują wyłącznie typowe transakcje, rzadkie przypadki pozostają nieprzetestowane. Jeśli logika porównywania ignoruje czas, kolejność lub skutki uboczne w systemach zależnych, dwa wyniki mogą wyglądać na równe, podczas gdy systemy zachowują się inaczej.

Testowanie równoległe może także odtwarzać błędne zachowanie systemu legacy. Dopasowanie do mainframe'a jest użyteczne podczas migracji, ale nie dowodzi, że każda odziedziczona reguła jest pożądana ani zgodna z aktualną polityką.

Zespoły muszą rozdzielić dwa pytania. Czy implementacja chmurowa zachowuje się jak oryginał i czy oryginalne zachowanie powinno przetrwać?

Drugie pytanie wymaga oceny biznesowej, prawnej, bezpieczeństwa i operacyjnej. Sama analiza kodu nie może na nie odpowiedzieć.

Twierdzenia dotyczące wydajności również wymagają dowodów zbliżonych do produkcyjnych. Wygenerowana usługa może przejść testy funkcjonalne, a jednocześnie powodować niedopuszczalne opóźnienia, zużycie infrastruktury lub rywalizację o bazę danych przy szczytowym wolumenie.

Odtwarzanie operacyjne zasługuje na taką samą uwagę. Zespoły powinny przetestować ponowienia, częściowe awarie, opóźnione komunikaty, zduplikowane transakcje i procedury wycofania przed przekazaniem odpowiedzialności.

Wreszcie, przepływ pracy nie może zagwarantować ukończenia programu. Przedsiębiorstwo może przygotować doskonałe oceny i prototypy, nie wycofując ani jednego obciążenia mainframe.

Sukces wymaga kryteriów wyjścia dla każdej jednostki migracji. Kryteria te powinny obejmować dowody funkcjonalne, gotowość operacyjną, uzgodnienie danych, zatwierdzenie bezpieczeństwa, oczekiwania kosztowe oraz rzeczywiste wycofanie systemu legacy.

Strategia Google jest bezpieczniejsza, ponieważ wcześniej uwidacznia niepewność. Nie jest bezpieczna wyłącznie dlatego, że uczestniczy w niej AI.

Na co zwracać uwagę, gdy Google Cloud przechodzi od metody do dowodów

Kolejnym sprawdzianem będzie to, czy etapowa metoda zapewnia powtarzalne przejścia produkcyjne, a nie bardziej przekonujący wygenerowany kod.

Pierwszym sygnałem są dowody klientów powiązane z ukończonymi jednostkami migracji. Kupujący powinni szukać nazwanych obciążeń produkcyjnych, które przeszły testy równoległe i przejęły odpowiedzialność systemu referencyjnego.

Przydatne studium przypadku wyjaśniałoby zakres, obsługiwane artefakty, odkryte zależności, czas walidacji, obsługę niezgodności oraz komponenty mainframe ostatecznie wycofane. Ogólne stwierdzenia o szybszej analizie ujawniają mniej.

Powtarzane przejścia wzmacniałyby argument Google, że przepływ pracy skaluje się poza starannie wybraną aplikację. Oceny bez wycofywania systemów produkcyjnych osłabiałyby go.

Drugim sygnałem jest głębsza śledzalność w całym łańcuchu narzędzi. Historia wydań Google release history pokazuje ciągłe prace nad ekstrakcją reguł biznesowych, dostępem MCP, obsługą języków i analizą dużych środowisk.

Istotny postęp połączyłby każdą zatwierdzoną regułę z dowodami źródłowymi, wygenerowanymi komponentami, testami, wynikami porównań i zatwierdzeniami ludzi. Taki łańcuch ułatwiłby przegląd podczas audytów i późniejszego utrzymania.

Pomógłby również zespołom ustalić, gdzie błąd wszedł do procesu. Niezgodność mogłaby wskazywać na wadliwą ekstrakcję, zmienione wymaganie, wygenerowany kod, przekonwertowane dane albo mechanizm walidacyjny.

Jasna śledzalność wzmocniłaby model iteracyjny, ponieważ wiedza kumulowałaby się między jednostkami migracji. Rozproszone artefakty sprawiałyby, że każda jednostka przypominałaby odrębny projekt.

Trzecim sygnałem jest sposób, w jaki IBM i AWS odpowiedzą porównywalnymi dowodami walidacyjnymi. Listy funkcji już się pokrywają, dlatego dostawcy będą musieli pokazać, jak ich metody radzą sobie z rzeczywistymi zależnościami i trudnymi przejściami.

IBM może argumentować, że modernizacja nie wymaga porzucenia IBM Z. AWS może podkreślać śledzalność od źródła do wyniku i automatyczne testowanie. Google musi udowodnić, że ocena kontekstowa połączona z Dual Run zapewnia lepszą granicę ryzyka.

Ta konkurencja powinna przynieść korzyści nabywcom korporacyjnym. Przenosi dyskusję z demonstracji surowego generowania kodu na dowody, zarządzanie, przenośność i ukończone rezultaty.

Dla liderów technologicznych natychmiastowym działaniem nie jest zatwierdzenie migracji całego środowiska. Jest nim wybór jednej znaczącej domeny i przetestowanie pełnego łańcucha.

Domena powinna obejmować rzeczywiste zależności i konsekwencje biznesowe, nie stając się jednocześnie nieodwracalnym pierwszym krokiem. Jej ocena powinna uwzględniać kod, dane, harmonogramy, interfejsy i wiedzę operacyjną.

Zespoły powinny rejestrować, ile wyodrębnionych reguł wymaga korekty, jak często wyniki równoległe się różnią oraz ile czasu zajmuje rozwiązanie każdej niezgodności. Te miary ujawniają więcej niż wolumen wygenerowanego kodu.

Powinny również zdecydować, co kończy się po udanym przejściu. Jednostka migracji jest nieukończona, jeśli oryginalne obciążenie, koszt licencji, proces operacyjny i odpowiedzialność za wsparcie nadal pozostają.

Google Cloud oferuje przedsiębiorstwom drogę między bezterminowym utrzymaniem a ryzykownym podejściem big bang. Ta droga jest wiarygodna, ponieważ traktuje modernizację jako rozpoznanie, rekonstrukcję i dowód.

Jej wartość będzie zależeć od tego, czy klienci zdołają powtarzać ten cykl w złożonych środowiskach bez tworzenia trwałego hybrydowego labiryntu. Kolejne przejścia produkcyjne będą ważniejsze niż kolejna demonstracja wygenerowana przez AI.