Żadne przedsiębiorstwo nie buduje celowo chaotycznego krajobrazu technologicznego. Zjawisko to zazwyczaj pojawia się niepostrzeżenie w wyniku przejęć, kupowania przez zespoły własnych narzędzi oraz niespójnych, często częściowych migracji do chmury. Rezultatem jest architektura „hybrydy z przypadku” – środowisko IT zbudowane na przestrzeni lat w oparciu o reaktywne wybory, a nie celowe działania. Co gorsza, nikt nie ma realnego planu, aby to naprawić.
W miarę jak AI w przedsiębiorstwach przechodzi z fazy eksperymentów do fazy produkcyjnej, hybryda z przypadku staje się czymś więcej niż tylko niedogodnością techniczną – stanowi strategiczne obciążenie. Aby zachować suwerenność danych i uniknąć gwałtownego wzrostu kosztów AI, organizacje muszą przyjąć architekturę hybrydy z założenia. Organizacje, które dokonają tej zmiany w sposób świadomy, uwolnią pełną wartość swoich zasobów danych. Te, które tego nie zrobią, przekonają się, że ich dług architektoniczny będzie narastał z każdym mijającym rokiem i każdą nową inicjatywą AI.
Był to temat mojej niedawnej rozmowy z gościem specjalnym Noelem Yuhanną, VP Principal Analyst w firmie Forrester, w trakcie webinarium Cloudera „Witamy w erze hybrydy z założenia”.
W tym wpisie rozwijam ten temat i przedstawiam, jak Państwa organizacja może stworzyć architekturę hybrydy z założenia, wykorzystując ujednolicone zarządzanie, otwarte standardy oraz mając jasną mapę wymagań dotyczących cyklu życia AI.
Poza aktywnością w zakresie M&A, wdrażaniem odizolowanych narzędzi oraz blokowaniem preferowanych dostawców przez poszczególne linie biznesowe, głównym winowajcą jest gwałtowne dążenie do chmury w ostatnich dekadach. Wiele organizacji przeprowadziło szybką i szeroko zakrojoną migrację, a teraz wahadło wychyla się w drugą stronę. Repatriacja danych to realny i coraz częściej poruszany temat.
Liczby mówią same za siebie: plany dyrektorów ds. informatyki (CIO) dotyczące repatriacji obciążeń do infrastruktury lokalnej wzrosły z 43% w 2020 r. do 83% w 2024 r.. Nie jest to odrzucenie chmury, lecz dojrzałe zrozumienie, że nie każde obciążenie powinno się w niej znajdować. W rzeczywistości, jak zauważa Yuhanna, około 80% przetwarzania transakcyjnego w bankowości i opiece zdrowotnej nadal odbywa się lokalnie. Wczesne błędne przekonanie, że „chmura jest tania”, ustąpiło miejsca trudnym pytaniom dotyczącym optymalizacji architektury, nadmiernej alokacji zasobów oraz kosztów transferu danych na zewnątrz, które osłabiają propozycję wartości.
Kwestie zgodności wymuszają natychmiastowe działania w obszarze, który dawniej był powolnym problemem IT. Regulacje takie jak RODO, unijny akt o danych, oraz HIPAA wymagają ścisłego przestrzegania suwerenności danych. Tymczasem amerykańska ustawa US CLOUD Act, która umożliwia władzom USA dostęp do danych na całym świecie, jest sprzeczna z przepisami o ochronie prywatności w UE i regionie APAC, co aktywnie skłania przedsiębiorstwa do korzystania z suwerennych dostawców chmury spoza USA. W sektorze finansowym rozporządzenie DORA nakłada obowiązek posiadania strategii wyjścia od dostawcy ponieważ zbyt duże poleganie na jednej chmurze stanowi obecnie ryzyko systemowe.
W obliczu nowych przepisów dotyczących AI, wymagających ścisłej identyfikowalności, presja ta będzie tylko rosła w 2026 roku i w przyszłości. Zarządzanie i AI łączy się w jedną ogromną przeszkodę w zakresie zgodności; firmy nieposiadające odpowiedniej architektury czeka bolesna i kosztowna modernizacja.
AI w skali przedsiębiorstwa przekształca przewlekły problem infrastrukturalny w problem krytyczny. Cykl życia AI ma skrajnie różne potrzeby na każdym etapie: trenowanie i kontekstualizacja wymagają skokowej mocy obliczeniowej na dużą skalę, co może predysponować te procesy do chmury, podczas gdy wnioskowanie w stanie ustalonym jest często bardziej ekonomiczne na własnych zasobach. „Przemyślana hybryda” oznacza dopasowanie każdego etapu do infrastruktury, która faktycznie mu odpowiada, zamiast domyślnego korzystania z jednego środowiska i ponoszenia negatywnych konsekwencji.
Inercja danych dodatkowo to komplikuje. AI wymaga ogromnych ilości rozproszonych danych, a przenoszenie ich między środowiskami wiąże się z rzeczywistymi opóźnieniami i kosztami transferu wychodzącego. Sytuacja ta wymusza trudny wybór: ograniczenie modeli do ograniczonego zbioru danych (poświęcając jakość) albo poniesienie ogromnych opłat za centralizację danych (niwecząc uzasadnienie biznesowe).
Agentowa AI znacząco zaostrza to wyzwanie. Ponieważ systemy te wymagają zaufanych danych w czasie rzeczywistym, aby móc podejmować działania, wsadowe potoki danych dostępnych z opóźnieniem po prostu nie przetrwają. Jak zauważa Yuhanna, adopcja agentowej AI wynosi obecnie około 24% i oczekuje się, że do końca 2026 roku wzrośnie dwukrotnie. Organizacje, które już dziś budują aktywną architekturę dla tej rzeczywistości, jutro osiągną korzyści.
Uzależnienie od jednego dostawcy to nie tylko teoretyczne ryzyko; to realny koszt zarówno na poziomie infrastruktury, jak i oprogramowania. Gdy Państwa zastrzeżone narzędzia do obsługi danych działają tylko w określonej chmurze, pojawia się problem narastającego „podwójnego uzależnienia”. Daje to dostawcy pełną przewagę, tworząc poważne wąskie gardło w momencie, gdy obciążenie musi zostać przeniesione – niezależnie od tego, czy przenoszą Państwo ukończony projekt pilotażowy w chmurze, aby uruchomić go na wolnych zasobach centrum danych, czy migrują Państwo do nowej suwerennej chmury w celu zapewnienia zgodności z przepisami. Organizacje odzyskują tę przewagę dzięki przenośności obciążeń i otwartym standardom.
Umożliwiają to dwa kluczowe standardy:
Kubernetes działa jako uniwersalna warstwa abstrakcji dla Państwa podstawowej infrastruktury. Dzięki zapewnieniu spójnego, natywnego dla chmury modelu operacyjnego — niezależnie od tego, jaki sprzęt lub dostawca chmury znajduje się u podstaw — eliminuje „koszt przejścia między platformami”, czyli narzut związany z przeprojektowywaniem, który narasta za każdym razem, gdy obciążenie przekracza granicę infrastruktury.
Apache Iceberg wykonuje równoważne zadanie na warstwie danych. Nie chodzi tylko o abstrahowanie od tego, gdzie znajdują się Państwa dane; chodzi o rozszerzenie grona osób, które mogą uzyskiwać do nich dostęp. Otwarty format tabel i katalog Apache Iceberg REST umożliwiają organizacjom udostępnianie danych w miejscu ich przechowywania dowolnemu systemowi innej firmy. Oznacza to, że mogą Państwo pozostawić nadzorowane dane dokładnie tam, gdzie się znajdują, jednocześnie umożliwiając zewnętrznym platformom analitycznym bezpośrednie wykonywanie na nich zapytań. Dzięki całkowitemu oddzieleniu danych od silników obliczeniowych specyficznych dla dostawcy organizacje zyskują rzeczywistą, przyszłościową elastyczność w zakresie sposobu i miejsca uruchamiania AI.
Warto zastanowić się, jak skala wygląda w praktyce. Yuhanna niedawno spotkał klienta, który łączył 50 000 baz danych z 1000 różnych systemów źródłowych. Przy takiej skali złożoność nie rośnie liniowo, lecz narasta wykładniczo. Otwarte standardy to nie tylko miły dodatek; to sposób, w jaki przedsiębiorstwa zachowują kontrolę nad własnymi środowiskami.
Pofragmentowana infrastruktura nieuchronnie prowadzi do fragmentarycznego zarządzania danymi. Jak podkreśla Yuhanna, około 70% danych w przedsiębiorstwach nie posiada odpowiednich metadanych ani skatalogowania; oznacza to, że tylko 25% jest faktycznie wykorzystywane do celów analitycznych, a większość danych w przedsiębiorstwie pozostaje całkowicie nietknięta! W 2006 roku brytyjski matematyk i pionier data science, Clive Humby, wypowiedział słynne zdanie „dane to nowa ropa naftowa”, zauważając, że surowe dane muszą być przetwarzane przez AI i analitykę, aby generować realną wartość. Jeśli każdy element danych zawiera potencjalną wiedzę, dlaczego mieliby Państwo akceptować architekturę, która aktywnie uniemożliwia wykorzystanie wszystkich danych?
Konsekwencje dla bezpieczeństwa są równie konkretne. Według 2025 Data Breach Report opublikowanego przez IBM naruszenia obejmujące wiele środowisk kosztują średnio ponad 5 mln USD (znacznie powyżej globalnej średniej wynoszącej 4,44 mln USD) i obecnie stanowią około 30% wszystkich incydentów. Powód jest prosty: do naruszeń dochodzi w punktach integracji, a każda granica środowiska jest punktem integracji.
Odpowiedzią jest ujednolicona warstwa zasad: pojedyncza, sfederowana płaszczyzna kontrolna obejmująca klasyfikację, kontrolę dostępu, pochodzenie danych, audyt i zgodność. W tym modelu zasady podążają za danymi i są stosowane spójnie oraz w czasie rzeczywistym w całym ekosystemie.
Pod wpływem rzeczywistych wymagań związanych z wdrażaniem AI w środowiskach produkcyjnych, zaostrzających się wymogów dotyczących suwerenności danych oraz większego nacisku na to, ile infrastruktura faktycznie kosztuje, organizacje muszą przejść od architektur hybrydowych z przypadku do architektur hybrydowych z założenia. Oto jak zacząć:
Należy określić jasny cel. Przed wdrożeniem jakiejkolwiek technologii należy opracować 18-miesięczną mapę drogową opartą na konkretnych wynikach biznesowych, takich jak wzrost przychodów, optymalizacja kosztów czy cele w zakresie odporności.
Należy przeprowadzić audyt inercji danych. Mapowanie miejsc rzeczywistego przechowywania danych, uprawnień dostępu oraz ekspozycji na opóźnienia i koszty transferu danych na zewnątrz. Pozwala to skutecznie ujawnić zapomniane obciążenia, zduplikowane dane i luki w zakresie zgodności.
Należy przeprowadzić przemyślaną racjonalizację. Usprawnienie nakładających się narzędzi, konsolidacja relacji z dostawcami, standaryzacja zarządzania i budowa rozwiązań pod kątem przenoszenia obciążeń.
Aby dowiedzieć się więcej, warto obejrzeć ponownie moją rozmowę z Noelem Yuhanną i zagłębić się w temat dzięki raportowi branżowemu „From Chaos to Control: Why ‘Hybrid by Design’ Is the Future of Enterprise Data Strategy”.
This may have been caused by one of the following: