Integracja Databricks z SAP wykracza poza udostępnianie danych i obejmuje AI dla przedsiębiorstw

Databricks i SAP ogłosiły 30 października rozszerzenie partnerstwa, zbliżając więcej możliwości AI dla przedsiębiorstw do klientów SAP, choć nie podano terminów udostępnienia. Integracja Databricks z SAP obejmuje teraz szerszy przepływ pracy, łącząc rejestry biznesowe z przygotowaniem danych, wsparciem AI, zarządzaniem i tworzeniem aplikacji.

Kluczowe pytanie brzmi, czy firmy mogą ponownie wykorzystywać znaczenie biznesowe zamiast odtwarzać je przy każdym projekcie AI. Rekord zamówienia wymaga relacji, definicji i uprawnień, zanim asystent będzie mógł odpowiedzialnie go interpretować. Partnerstwo podważa podejście oparte na niestandardowym wyodrębnianiu danych, w którym poszczególne zespoły odtwarzają te szczegóły.

SAP współpracuje również ze Snowflake, co daje nabywcom alternatywną relację platformową do rozważenia. Jednak bezpośrednia presja spoczywa na zespołach architektury przedsiębiorstwa. Muszą one zdecydować, które prace integracyjne powinny należeć do zarządzanej platformy, a które obowiązki biznesowe pozostają po ich stronie.

Co faktycznie zmienia integracja Databricks z SAP

Ogłoszenie rozszerza zamierzony zakres partnerstwa poza udostępnianie danych — na aplikacje i systemy AI, które z nich korzystają.

SAP Databricks osadza Databricks w SAP Business Data Cloud, zarządzanym środowisku SAP służącym do łączenia danych biznesowych i analityki. Październikowe ogłoszenie wprowadza SAP Application Data Foundation jako drogę do danych aplikacyjnych w systemach chmurowych i lokalnych.

Databricks wskazuje Genie, Lakeflow, Unity Gateway i Lakebase jako możliwości, które mają trafić do rozszerzonej oferty. Ich zamierzone role obejmują wsparcie AI, inżynierię danych, mechanizmy kontroli AI i aplikacje operacyjne.

Firma opisuje także planowane połączenie Genie z Joule, asystentem AI SAP. Co istotne, jej rozszerzenie SAP Databricks rozróżnia istniejące oferty od planowanych dodatków, nie przedstawiając harmonogramu udostępniania funkcji po funkcji.

To rozróżnienie ma natychmiastowy wpływ na proces zakupowy. Nabywcy mogą ocenić istniejące połączenie, ale nie powinni zakładać, że cały ogłoszony przepływ pracy jest dostępny w ich środowisku.

Oddzielne ogłoszenie SAP dotyczące AI dla przedsiębiorstw potwierdza rozszerzenie partnerstwa. Umieszcza ono tę pracę w szerszym wysiłku na rzecz połączenia rozwoju AI, kontekstu biznesowego i mechanizmów kontroli przedsiębiorstwa.

SAP opisuje lakehouse — architekturę łączącą elastyczne przechowywanie danych z zarządzanymi możliwościami analitycznymi — jako podstawę tych działań. W ogłoszeniu wymieniono także Agent Bricks obok innych możliwości Databricks.

Opisy te wyznaczają kierunek strategiczny. Nie dowodzą, że każdy wskazany komponent ma identyczną dostępność, wymagania konfiguracji lub warunki wsparcia w SAP Databricks.

Praktyczna zmiana polega na proponowanym podziale obowiązków. Większa odpowiedzialność za integrację spoczywałaby na dostawcach platform, podczas gdy klienci tworzyliby aplikacje biznesowe na powstałym fundamencie.

Różni się to od traktowania SAP jako systemu źródłowego, z którego każdy zespół wyodrębnia kolejny zestaw danych. Nadaje definicjom biznesowym SAP trwałą rolę w dalszych pracach z AI.

Ogłoszenie produktu nie może jednak przesądzić, ile pracy niestandardowej zniknie. Rozszerzenia specyficzne dla klienta, definicje organizacyjne oraz połączenia z systemami zewnętrznymi nadal wymagają analizy.

Dla czytelników szukających wyjaśnienia SAP Databricks w kontekście tego wydarzenia użyteczne jest rozróżnienie zakresu. Istniejąca relacja łączy platformy; rozszerzenie ma połączyć większą część pracy wykonywanej na tych platformach.

Ogłoszenie zasługuje zatem na uwagę jako zobowiązanie architektoniczne. Jego znaczenie operacyjne będzie zależeć od tego, co klienci mogą wdrożyć, na jakich warunkach i z jakimi mierzalnymi rezultatami.

Zespoły danych w przedsiębiorstwach stają przed inną decyzją „budować czy kupić”

Rozszerzenie wywiera presję na firmy, by uzasadniały odtwarzanie prac integracyjnych, których zarządzanie ich dostawcy platform coraz częściej oferują.

Niestandardowe wyodrębnianie danych ma zrozumiały urok. Zespół może wybrać miejsce docelowe, kontrolować transformacje i kształtować zestaw danych wokół konkretnego wymagania raportowego.

Trudność pojawia się, gdy taki zestaw danych staje się wspólną infrastrukturą. Definicje, które wcześniej służyły pulpitowi raportowemu, zaczynają wpływać na prognozy, zautomatyzowane rekomendacje i decyzje biznesowe.

Rozważmy przykładowego asystenta zakupowego oceniającego wiarygodność dostawcy. Potrzebuje on czegoś więcej niż listy zamówień zakupu. Musi rozróżniać daty żądane, daty potwierdzone, faktyczne przyjęcia i późniejsze korekty.

Model może wygenerować wyjaśnienie bez zrozumienia tych rozróżnień. Powstała odpowiedź może brzmieć przekonująco, choć mierzy inne zagadnienie biznesowe.

Zarządzany fundament danych zmienia miejsce, z którego firmy oczekują pochodzenia tych rozróżnień. Zamiast odtwarzać każdą relację w dalszych etapach, zespoły mogą ocenić, czy wspierane dane biznesowe już zawierają niezbędny kontekst.

Nie eliminuje to potrzeby zatrudniania inżynierów danych. Zmienia jednak zakres pracy, którą muszą oni uzasadniać i priorytetyzować.

Utrzymywanie skryptu do ekstrakcji różni się od sprawdzania, czy definicja dostawy odpowiada polityce zakupowej. To drugie staje się ważniejsze, gdy asystenci trafiają bezpośrednio do użytkowników biznesowych.

Presja dotyczy również administratorów SAP i właścicieli biznesowych. Zestaw danych, który wcześniej był ograniczony do raportowania, może stać się wejściem dla systemów obsługujących nieznane wcześniej grupy odbiorców.

Decyzje dotyczące dostępu wymagają wówczas czegoś więcej niż łączności technicznej. Właściciele muszą ustalić, kto może korzystać z rekordu, w jakim celu i zgodnie z jaką interpretacją biznesową.

W projektach SAP AI dla przedsiębiorstw oznacza to, że własność organizacyjna staje się częścią architektury wdrożenia. Zespół modelowy nie może rozwiązać każdej niepewności lepszym promptowaniem.

Nabywcy stają więc przed bardziej konkretną decyzją „budować czy kupić”. Muszą odróżnić wielokrotnie wykorzystywalną infrastrukturę platformową od logiki biznesowej specyficznej dla firmy.

Zarządzane połączenie jest atrakcyjne, gdy ogranicza powtarzalną pracę inżynieryjną, nie zaciemniając odpowiedzialności. Staje się mniej atrakcyjne, gdy klienci nie potrafią wyjaśnić, jak przemieszczają się definicje lub kto je utrzymuje.

Istnieje także konsekwencja kadrowa. Przeniesienie rutynowej integracji do platformy nie uwalnia automatycznie zasobów, jeśli istniejących procesów nie da się faktycznie wycofać.

Firma obsługująca jednocześnie stary stos ekstrakcyjny i nową zarządzaną ścieżkę może początkowo zwiększyć złożoność. Uzasadnienie biznesowe zależy częściowo od tego, które obowiązki utrzymaniowe znikają.

Ta analiza nie dowodzi, że zarządzana integracja jest zawsze lepsza. Wskazuje porównanie, które wymusza ogłoszenie: własność integracji w całym okresie jej działania.

Silniejsze pytanie zakupowe dotyczy pełnego przepływu pracy. Ile inżynierii, przeglądu biznesowego i bieżącego wsparcia wymaga użyteczna aplikacja?

To pytanie daje zespołom architektury przedsiębiorstwa wyraźniejszą podstawę oceny niż lista nowo ogłoszonych funkcji.

Znaczenie biznesowe jest mechanizmem stojącym za argumentem dotyczącym AI

Wartość techniczna integracji opiera się na zachowaniu użytecznego kontekstu wraz z rekordami, a nie jedynie na udostępnieniu rekordów.

Databricks dokumentuje przenoszenie metadanych semantycznych — opisowych informacji o znaczeniu i relacjach danych — z SAP Business Data Cloud do Unity Catalog. Unity Catalog to system katalogowania i zarządzania Databricks.

Obsługiwane informacje obejmują opisy tabel, opisy kolumn, klucze i tagi zarządzania SAP. Klucze identyfikują rekordy i relacje; tagi zarządzania klasyfikują informacje na potrzeby polityk.

Dokumentacja metadanych semantycznych określa również granice. Relacje między tabelami w różnych udziałach nie są obsługiwane, a zsynchronizowane metadane SAP pozostają w Databricks tylko do odczytu.

Szczegóły te mają znaczenie, ponieważ AI dla przedsiębiorstw musi zidentyfikować właściwe rekordy, zanim będzie mogła użytecznie na ich podstawie wnioskować.

W przykładowym przepływie pracy finansowej asystent odpowiadający na pytanie o przychody musi wybrać odpowiednią miarę. Zamówienia zaksięgowane, wystawione faktury i przychody rozpoznane służą różnym celom.

Opisy i relacje pomagają ustalić, których danych dotyczy pytanie. Mogą ograniczyć niejednoznaczność, zanim model wygeneruje wyjaśnienie.

Metadane nie są jednak kompletną specyfikacją biznesową. Opis kolumny przychodów nie musi koniecznie kodować każdego wyjątku z polityki rachunkowości firmy.

Tworzy to wyraźną granicę oceny. Nabywcy powinni analizować, które znaczenie jest przenoszone automatycznie, a które nadal zależy od starannie opracowanych definicji lub ludzkiej kontroli.

To samo dotyczy relacji między rekordami. Obsługiwana relacja w ramach współdzielonego zestawu danych nie dowodzi, że złożone pytanie między domenami ma cały niezbędny kontekst.

Asystent porównujący zobowiązania klientów z wydajnością dostawców może zależeć od informacji rozproszonych między odrębnymi domenami biznesowymi. Aplikacja musi uwzględniać te granice.

W tym miejscu projekty SAP AI dla przedsiębiorstw wykraczają poza demonstracje. Przekonująca odpowiedź musi pozostać poprawna, gdy warunki biznesowe wprowadzają wyjątki.

Anulowane zamówienia, częściowe dostawy, zmienione identyfikatory i późne korekty stanowią użyteczne przykłady do oceny. Są to przykładowe warunki testowe, a nie zgłoszone ustalenia dotyczące tej integracji.

Podstawowa zasada pojawia się również w bazach wiedzy AI: dostęp do informacji i dostęp do użytecznego kontekstu to odrębne problemy. Systemy transakcyjne przedsiębiorstw nakładają dodatkowo surowsze wymagania dotyczące uprawnień i spójności.

Dla deweloperów oznacza to, że wybór modelu następuje po interpretacji danych. Silniejszy model nie może niezawodnie zrekompensować niezdefiniowanej metryki biznesowej.

Dla użytkowników biznesowych konsekwencja jest równie praktyczna. Odpowiedź powinna ujawniać wystarczający kontekst, aby ustalić, co zmierzyła i dlaczego taka interpretacja jest właściwa.

Integrację Databricks z SAP najlepiej zatem oceniać poprzez pytania, które ujawniają znaczenie. Dostęp do rekordów jest konieczny, ale to interpretacja decyduje, czy aplikacja zasługuje na zaufanie operacyjne.

To mechanizm stojący za argumentem partnerstwa dotyczącym AI oraz obszar, w którym dokumentacja techniczna staje się bardziej użyteczna niż szerokie twierdzenia o transformacji.

Udostępnianie zero-copy zmienia pracę, ale jej nie eliminuje

Ograniczenie replikacji może uprościć ścieżkę danych, pozostawiając istotne obowiązki związane z dostępem, politykami i działaniem aplikacji.

OpenSharing to platforma Databricks do udostępniania danych. Dokumentacja jej konektora SAP opisuje dostęp zero-copy, co oznacza, że współdzielone dane pozostają na miejscu, zamiast być replikowane przez połączenie udostępniające.

Twierdzenie to dotyczy konkretnej warstwy architektury. Nie należy go interpretować jako obietnicy, że każda aplikacja działająca dalej w przepływie nie tworzy nowych zasobów.

Prognoza, przekształcony zbiór danych lub baza danych aplikacji mogą wprowadzać własne wymagania dotyczące przechowywania i zarządzania. Nabywcy muszą oceniać całą aplikację, zamiast wyciągać wnioski na podstawie samego połączenia.

Łącznik SAP BDC wymaga również koordynacji między administratorami SAP i Databricks. Dostęp zależy od skonfigurowanego udostępniania i odpowiednich uprawnień.

Dokumentacja zawiera jeszcze jeden szczegół operacyjny: Databricks może udostępniać SAP określone informacje o wykorzystaniu obciążeń i operacjach na potrzeby rozliczeń oraz administracji.

Informacje te mogą identyfikować organizację i opisywać obciążenia związane ze współdzielonymi danymi SAP. Klienci powinni uwzględnić ten udokumentowany model w swoich przeglądach architektury i dostawców.

Szczegóły te nie podważają wartości zarządzanego łącznika. Pokazują, co w rzeczywistym wdrożeniu musi obejmować słowo „zarządzany”.

Firma nadal potrzebuje osoby odpowiedzialnej za wnioski o dostęp, zmieniające się definicje biznesowe, incydenty aplikacyjne i ciągłość usług. Krótsza ścieżka danych nie przypisuje tych obowiązków automatycznie.

Również uprawnienie do odczytu informacji nie oznacza uprawnienia do działania na ich podstawie. Asystent wyjaśniający opóźnienie dostawcy ma inny poziom uprawnień niż aplikacja zmieniająca zamówienie zakupu.

To rozróżnienie nabiera większego znaczenia, gdy partnerstwo rozszerza się na aplikacje i agentów, czyli systemy oprogramowania korzystające z narzędzi do wykonywania zadań.

Przedsiębiorstwo może zaakceptować asystenta przygotowującego rekomendację, jednocześnie wymagając zatwierdzenia przed każdą zmianą operacyjną. Ta granica powinna należeć do projektu i oceny aplikacji.

Zapowiedziane rozszerzenie platformy powinno zatem przejść odrębne testy dostępu do danych, jakości odpowiedzi i autoryzacji działań. Sukces w jednym obszarze nie oznacza sukcesu w pozostałych.

Podobna dyscyplina jest potrzebna przy deklaracjach dotyczących wydajności. Databricks przytacza w swoim komunikacie usprawnienia osiągnięte przez klientów, lecz przykłady te nie powinny stać się domyślnymi punktami odniesienia dla każdej planowanej integracji.

Istniejące wdrożenia klientów mogą potwierdzać, że bazowa platforma obsługuje obciążenia biznesowe. Nie mogą jednak potwierdzać wydajności funkcji, które nie mają opublikowanego harmonogramu wydania.

Sceptyczne spojrzenie jest zatem konkretne. Architektura oferuje wiarygodny sposób ograniczenia powtarzalnej pracy integracyjnej, ale komunikat nie określa ilościowo wszystkich pozostałych obowiązków wdrożeniowych.

W ujęciu zakupowym najważniejsza przestroga dotycząca SAP Databricks brzmi: oceniaj razem obsługiwany przepływ pracy, jego ograniczenia i model odpowiedzialności.

Udane wdrożenie powinno ograniczać pracę w ekosystemie operacyjnym wokół aplikacji. Przeniesienie tej pracy do mniej widocznych procesów administracyjnych osłabiłoby praktyczne korzyści.

Snowflake pokazuje, dlaczego sam dostęp do SAP nie jest wyróżnikiem

Databricks musi konkurować tym, co klienci mogą zbudować i obsługiwać na danych SAP, ponieważ SAP ogłosił inne partnerstwa platformowe.

SAP ogłosił współpracę ze Snowflake w listopadzie 2025 roku. Komunikat opisywał zarówno rozszerzenie rozwiązania SAP Snowflake, jak i łącznik dla istniejących środowisk Snowflake.

Proponowana architektura obejmowała dwukierunkowe udostępnianie bez replikacji oraz dostęp do danych SAP z kontekstem biznesowym. Te elementy pokrywają się z główną propozycją wartości podkreślaną obecnie przez Databricks.

Współpraca SAP w zakresie danych Snowflake stanowi zatem istotny punkt odniesienia dla konkurencji. Jej pierwotnych celów dostępności nie należy traktować jako dowodu obecnego wdrożenia bez sprawdzenia późniejszej dokumentacji.

Porównanie ma znaczenie, ponieważ ogranicza zbyt szeroką interpretację komunikatu Databricks. Dostęp do danych SAP nie jest przedstawiany wyłącznie za pośrednictwem jednej zewnętrznej platformy analitycznej.

Daje to nabywcom powód, by porównywać rzeczywiste obciążenia, zamiast zakładać, że dostęp integracyjny rozstrzyga wybór platformy.

Firma z ugruntowanymi praktykami inżynierii danych może cenić spójność ze swoim istniejącym środowiskiem. Inna może priorytetowo traktować określony wzorzec aplikacyjny lub doświadczenie użytkownika biznesowego.

Są to kwestie analityczne, a nie dowody na to, że którykolwiek dostawca wygrywa w każdym przypadku. Przeanalizowane tutaj źródła nie oferują kontrolowanego porównania konkurencyjnych wdrożeń.

Użyteczne pytanie konkurencyjne dotyczy dystansu między współdzielonymi danymi a utrzymywaną aplikacją biznesową.

Ile pracy wykonuje zespół po uzyskaniu dostępu? Jak łatwo użytkownicy biznesowi mogą analizować odpowiedzi? Jak jasno administratorzy mogą ustalić odpowiedzialność, gdy coś się zmienia?

Pytania te utrzymują porównanie w związku z główną kwestią artykułu: zarządzanym kontekstem biznesowym kontra wielokrotnie odtwarzanym kontekstem.

Platforma może oferować szerokie możliwości, a mimo to pozostawiać klientom zarządzanie trudnymi przekazaniami. Z kolei węższe wdrożenie może dostarczać znaczną wartość, jeśli jego granice są dobrze rozumiane.

Wielopartnerskie podejście SAP rodzi także długoterminowe pytanie o interoperacyjność. Klienci muszą wiedzieć, które definicje pozostają możliwe do ponownego wykorzystania, gdy obciążenia przekraczają granice platform.

Otwarty mechanizm udostępniania pomaga ustanowić łączność. Przenośność logiki aplikacji, definicji biznesowych i procedur operacyjnych wymaga odrębnej analizy.

Dla nabywców korporacyjnych oznacza to ocenę warunków wyjścia obok warunków wdrożenia. Połączenie danych jest tylko częścią zależności tworzonej przez aplikację produkcyjną.

Dla Databricks rozszerzenie podnosi oczekiwania. Firma pozycjonuje swoją relację wokół szerszego doświadczenia programistycznego i operacyjnego, co zaprasza do szerszej oceny.

Dla SAP wyzwaniem jest utrzymanie zrozumiałych wyborów w ramach rosnącej liczby relacji platformowych. Nabywcy potrzebują jasnych granic wokół obsługiwanych funkcji i odpowiedzialności.

Znaczenie konkurencyjne ma więc charakter praktyczny, a nie teatralny. Więcej dostawców oferuje ścieżki do danych biznesowych; wyróżnikiem staje się zakres niezawodnej pracy, którą klienci mogą wykonać za ich pośrednictwem.

Kolejnymi sygnałami będą dostępność, wierność semantyczna i wyniki operacyjne

Kolejne dowody powinny połączyć zapowiedzianą architekturę z możliwościami gotowymi do wdrożenia i zmierzonymi przepływami pracy biznesowej.

Pierwszym sygnałem jest dostępność na poziomie funkcji. W nadchodzących miesiącach dokumentacja wydań powinna wyjaśnić, z których rozszerzonych możliwości klienci mogą korzystać i gdzie są one obsługiwane.

Przydatna aktualizacja rozróżniałaby ogólną dostępność od dostępu w wersji zapoznawczej oraz opisywała istotne zależności. Ustaliłaby również status realizacji planowanego połączenia asystenta.

Informacje te wzmocniłyby komunikat, przekształcając kierunek architektoniczny w możliwą do oceny opcję wdrożenia. Utrzymująca się niejednoznaczność ograniczałaby planowanie krótkoterminowe.

Drugim sygnałem jest wierność semantyczna, czyli stopień, w jakim definicje i relacje biznesowe zachowują dokładność podczas wykorzystania w różnych systemach.

Klienci potrzebują przykładów, które ujawniają obsługiwane granice, zamiast je ukrywać. Szczególnie przydatne do analizy są pytania międzyobszarowe i zmieniające się definicje biznesowe.

Aplikacja, która przejrzyście radzi sobie z tymi warunkami, wspierałaby argument za zarządzanym fundamentem biznesowym. Częste ręczne odtwarzanie zawężałoby korzyści.

Nie wymaga to od dostawców deklarowania doskonałego zrozumienia. Jasne ograniczenia i powtarzalne oceny mogą stanowić silniejszy dowód niż szerokie zapewnienia o inteligencji kontekstowej.

Trzecim sygnałem są wyniki operacyjne z kompletnych przepływów pracy klientów. Istotne raportowanie powinno odróżniać szybszą analizę od szybszego wdrożenia, ograniczonego utrzymania lub lepszej jakości decyzji.

Wyniki te odpowiadają na różne pytania. Szybsze zapytanie może być użyteczne, nie dowodząc jednak, że firma wycofała własny stos integracyjny.

Podobnie asystent może oszczędzać czas użytkowników, jednocześnie tworząc nowe obowiązki kontrolne. Ocena operacyjna powinna uwzględniać wysiłek niezbędny do utrzymania wiarygodności jego odpowiedzi.

Nabywcy powinni szukać zdefiniowanego poziomu bazowego, nazwanego procesu biznesowego oraz jasnego opisu zaangażowania ludzi. Porównania stają się trudne, gdy te szczegóły pozostają nieokreślone.

Najsilniejsze dowody od klientów wyjaśniałyby, co zmieniło się po wdrożeniu. Wskazywałyby, które zadania zniknęły, które mechanizmy kontroli pozostały i jak organizacja zmierzyła wynik.

Wyjaśniłoby to również, kto odnosi korzyści jako pierwszy. Inżynierowie danych, administratorzy, analitycy biznesowi i użytkownicy operacyjni doświadczają różnych elementów tej samej architektury.

Znaczenie partnerstwa zależy od połączenia tych doświadczeń. Lepsze środowisko programistyczne ma większe znaczenie, gdy jego zalety utrzymują się w codziennym użyciu biznesowym.

Integracja Databricks SAP wyznacza wiarygodny kierunek ku temu połączeniu. Jej udokumentowane podstawy sprawiają również, że pozostałe pytania są wystarczająco konkretne, aby nabywcy mogli je zbadać.

Przed podjęciem zobowiązania wybierz pytanie biznesowe, na które zespoły w Twojej firmie już teraz mają trudność odpowiadać konsekwentnie. Poproś dostawców o prześledzenie jego rekordów, definicji, uprawnień i granic zatwierdzania w proponowanej architekturze. Poproś o status wydania każdej wymaganej funkcji, w tym zależności spoza głównego komunikatu. Następnie porównaj wynikający z tego nakład pracy z obecnym procesem, uwzględniając utrzymanie i ocenę biznesową. Użytecznym rezultatem będzie jaśniejszy opis tego, kto jest właścicielem każdej decyzji i która praca faktycznie znika. W przypadku integracji Databricks SAP takie dowody nadadzą ogłoszonemu rozszerzeniu znaczenie dla przedsiębiorstwa oceniającego kolejną inwestycję w AI. Który przepływ pracy biznesowej może wykorzystać Twoja organizacja do sprawdzenia tych twierdzeń?