Databricks SAP 整合從資料共享擴展至企業 AI
Databricks 與 SAP 於 10 月 30 日宣布擴大合作，為 SAP 客戶帶來更多企業 AI 功能，但尚未公布推出日期。Databricks SAP 整合現時針對更廣泛的工作流程，連接業務記錄、資料準備、AI 輔助、管治及應用程式開發。
核心問題在於，企業能否重用業務含義，而毋須每次啟動 AI 專案時重新建立。訂單記錄需要具備關係、定義及權限，助理才能以負責任的方式解讀。這項合作挑戰了傳統的自訂擷取方式；該方式往往令個別團隊必須自行重建這些細節。
SAP 亦與 Snowflake 合作，讓買家多一種平台合作關係可供考慮。不過，眼前壓力主要落在企業架構團隊身上。他們必須決定哪些整合工作應交由託管平台處理，以及哪些業務責任仍須由自己承擔。
Databricks SAP 整合實際改變了甚麼
這項公布將合作關係的預期範圍，由共享資料擴展至使用資料的應用程式及 AI 系統。
SAP Databricks 將 Databricks 嵌入 SAP Business Data Cloud，後者是 SAP 用作連接業務資料與分析的託管環境。10 月的公布引入 SAP Application Data Foundation，作為存取雲端及本地系統應用程式資料的途徑。
Databricks 指出，Genie、Lakeflow、Unity Gateway 及 Lakebase 將會加入擴展後的方案。其預期角色涵蓋 AI 輔助、資料工程、AI 控制及營運應用程式。
該公司亦提及計劃連接 Genie 與 SAP 的 AI 助理 Joule。關鍵在於，其 SAP Databricks 擴展區分了現有方案與計劃新增的功能，卻沒有提供逐項功能的推出時間表。
這項區分會即時影響採購決策。買家可以評估現有連接，但不應假設整套已公布的工作流程已可在其環境中使用。
SAP 另外發布的企業 AI 公布印證了合作擴展。該公告將有關工作置於一項更廣泛的努力之中，旨在連接 AI 開發、業務脈絡與企業控制。
SAP 將 lakehouse 描述為這項工作的基礎；這是一種結合靈活資料儲存與受管理分析功能的架構。其公告亦在其他 Databricks 功能之中提及 Agent Bricks。
這些描述確立了策略方向，但並不表示每個點名的組件均在 SAP Databricks 內具備相同的可用性、配置要求或支援安排。
實際改變在於所提出的分工。更多整合責任將由平台供應商承擔，而客戶則可在所形成的基礎上建立業務應用程式。
這有別於將 SAP 視為來源系統、由各團隊各自擷取另一份資料集的做法。它讓 SAP 的業務定義持續在下游 AI 工作中發揮作用。
然而，產品公布無法確定可減少多少自訂工作。客戶特定的擴充、組織定義，以及與外部系統的連接，仍需進一步調查。
對於希望透過這次事件了解 SAP Databricks 的讀者，有用的區分在於範圍。現有關係連接平台；這次擴展旨在連接更多在其上進行的工作。
因此，這項公布值得作為架構承諾而受到關注。其營運意義將取決於客戶可部署甚麼、在甚麼條件下部署，以及能取得甚麼可量度的成果。
企業資料團隊面對不同的自建或採購決策
這次擴展令企業須說明，為何仍要重建愈來愈由平台供應商提供託管的整合工作。
自訂擷取有其合理吸引力。團隊可以選擇目的地、控制轉換流程，並圍繞特定報告要求建立資料集。
困難會在資料集成為共用基礎設施時浮現。原本服務單一儀表板的定義，開始影響預測、自動化建議及業務決策。
試想一個用於評估供應商可靠性的採購助理。它需要的不只是一份採購訂單清單，還必須區分要求日期、確認日期、實際收貨日期及其後修正。
即使未能理解這些區分，模型仍可生成解釋。得出的答案可能聽來具說服力，卻是在衡量不同的業務問題。
託管資料基礎會改變企業對這些區分來源的預期。團隊毋須在下游重建每段關係，而可評估受支援的業務資料是否已帶有所需脈絡。
這並不會消除資料工程師的需要，卻會改變他們必須辯護及優先處理的工作。
維護一個擷取指令碼，與驗證交付定義是否符合採購政策，是兩回事。隨着助理直接接觸業務使用者，後者變得更為重要。
壓力亦延伸至 SAP 管理員及業務擁有人。原本僅限於報告用途的資料集，可能成為服務陌生受眾的系統輸入。
存取決策因而不僅涉及技術連接。擁有人必須決定誰可使用某筆記錄、用於甚麼目的，以及依循何種業務詮釋。
對於 SAP 企業 AI 專案而言，這令組織擁有權成為部署架構的一部分。模型團隊無法單靠更佳提示詞解決所有不確定性。
因此，買方面對更具體的自建或採購決策。他們需要區分可重用的平台基礎設施與公司特定的業務邏輯。
當託管連接能減少重複工程、同時不模糊責任時，便具吸引力。若客戶無法解釋定義如何流轉或由誰維護，其吸引力便會下降。
這亦涉及人手配置。將例行整合移至平台，並不會自動釋放人力，除非現有流程確實可以淘汰。
一家同時運行舊擷取架構與新託管途徑的公司，起初可能反而增加複雜度。商業理據部分取決於哪些維護責任得以消失。
這項分析並不表示託管整合在所有情況下都較可取。它指出這項公布所迫使的比較：在整個營運生命週期中，誰擁有整合工作。
更有力的採購問題關乎完整工作流程：一個可用的應用程式需要多少工程、業務審核及持續支援？
這個問題為企業架構團隊提供比一份新公布功能清單更清晰的評估基礎。
業務含義是 AI 論述背後的機制
整合的技術價值，建基於在記錄旁保留可用脈絡，而非僅僅讓記錄可被存取。
Databricks 說明，語意中繼資料——即描述資料含義及關係的資訊——會由 SAP Business Data Cloud 移至 Unity Catalog。Unity Catalog 是 Databricks 的目錄及管治系統。
受支援的資訊包括資料表描述、欄位描述、鍵及 SAP 管治標籤。鍵用於識別記錄及關係；管治標籤則為資訊分類，以配合政策需要。
語意中繼資料文件亦指出限制。不同共享項目中資料表之間的關係不受支援，而已同步的 SAP 中繼資料在 Databricks 中維持唯讀。
這些細節之所以重要，是因為企業 AI 必須先識別正確記錄，才能就資料作出有用推理。
以一個示例性的財務工作流程而言，回答收入問題的助理必須選取適當指標。已預訂訂單、已開具發票及已確認收入，服務的用途各不相同。
描述及關係有助確立問題所指的資料，並可在模型生成解釋前減少歧義。
但中繼資料並非完整的業務規格。收入欄位的描述未必編碼了公司會計政策中的每項例外情況。
這形成清晰的評估界線。買家應檢視哪些含義可自動傳遞，以及哪些仍取決於經整理的定義或人手審核。
這同樣適用於記錄之間的關係。共享資料集內一項受支援的關係，並不代表複雜的跨領域問題已具備所有必要脈絡。
一個比較客戶承諾與供應商表現的助理，可能依賴分布於不同業務領域的資訊。應用程式必須考慮這些界限。
SAP 企業 AI 專案正是在這裏超越示範階段。當業務情況出現例外時，一個具說服力的答案必須維持正確。
已取消訂單、部分交付、變更識別碼及延後調整，均為有用的評估例子。這些是示例性測試條件，而非關於此整合的已報告發現。
這項基本原則亦見於 AI 知識庫：存取資訊與存取可用脈絡，是兩個不同問題。企業交易系統對權限及一致性有更嚴格要求。
對開發人員而言，這意味模型選擇要排在資料詮釋之後。更強大的模型無法可靠地彌補未定義的業務指標。
對業務使用者而言，其含義同樣實際：答案應揭示足夠脈絡，說明它量度了甚麼，以及為何該詮釋合適。
因此，評估 Databricks SAP 整合時，最好透過能揭示含義的問題進行。記錄存取固然必要，但詮釋決定應用程式是否值得獲得營運信任。
這正是合作關係 AI 論述背後的機制，也是技術文件比廣泛轉型聲稱更有用的範疇。
零複製共享改變工作，但不會將其消除
減少複製可簡化資料路徑，但存取、政策及應用程式行為仍涉及大量責任。
OpenSharing 是 Databricks 的資料共享平台。其 SAP 連接器文件描述零複製存取，即共享資料保留在原處，而非透過共享連接被複製。
這項聲稱涉及架構的特定層面，不應被解讀為承諾每個下游應用程式均可避免建立新的資產。
預測、經轉換的資料集或應用程式資料庫，都可能帶來自身的儲存和管理要求。採購方需要評估完整的應用程式，而非從連接方式推斷一切。
SAP BDC connector亦需要 SAP 與 Databricks 管理員協調。存取權限取決於已設定的分享機制及適當權限。
文件還包含另一項營運細節：Databricks 可能會與 SAP 分享若干工作負載使用量及營運資訊，以作帳單處理和管理之用。
該等資訊可以識別某個機構，並描述涉及共享 SAP 資料的工作負載。客戶應在架構和供應商評估中納入這項已記錄的安排。
這些細節並不否定受管理 connector 的價值，而是說明在實際部署中，「受管理」一詞需要涵蓋甚麼。
企業仍然需要有人為存取請求、持續變動的業務定義、應用程式事故及服務延續性負責。較短的資料路徑不會自動分配這些責任。
同樣地，獲准讀取資訊並不代表獲准採取行動。解釋供應商延誤的助手，與更改採購訂單的應用程式，權限層級並不相同。
隨着合作關係延伸至應用程式和 agents——即使用工具完成任務的軟件系統——這項區別變得更重要。
企業可以接受一個起草建議的助手，但要求任何營運變更均須先獲批准。這條界線應納入應用程式的設計和評估。
因此，已公布的平台擴展應分別接受資料存取、答案質素及行動授權的測試。一個範疇的成功，並不代表其他範疇亦會成功。
效能主張同樣需要嚴謹看待。Databricks 在公告中引用了客戶改善案例，但不應將這些例子變成每項計劃整合的隱含基準。
現有客戶採用情況可以證明底層平台服務業務工作負載的能力，卻不能證明尚未公布發布時間表的功能之效能。
因此，審慎的角度很明確：該架構提供一個可信的方法，以減少重複的整合工作，但公告並未量化所有餘下的實施責任。
以採購角度解釋 SAP Databricks，核心提醒是：一併評估支援的工作流程、其限制及其責任歸屬模式。
成功的部署應減少應用程式周邊作業系統中的工作。若把這些工作轉移至較不顯眼的行政流程，實際效益便會減弱。
Snowflake 說明僅有 SAP 存取權並非差異化因素
Databricks 必須在客戶可利用 SAP 資料建立和營運甚麼方面競爭，因為 SAP 已公布其他平台合作夥伴關係。
SAP 於 2025 年 11 月公布與 Snowflake 的合作。該公告描述了 SAP Snowflake 解決方案擴展，以及供現有 Snowflake 環境使用的 connector。
擬議架構包括無需複製的雙向分享，以及可存取具備業務脈絡的 SAP 資料。這些主題與 Databricks 現時強調的核心價值主張有所重疊。
因此，SAP 的 Snowflake 資料協作提供了具參考價值的競爭比較。除非查閱後續文件，否則不應將其最初的可用性目標視為目前已交付的證明。
這項比較之所以重要，是因為它限制了對 Databricks 公告的廣泛解讀。SAP 資料存取並非只透過單一外部分析平台提供。
這使採購方有理由比較實際工作負載，而非假設整合存取權已決定平台選擇。
已建立資料工程實務的企業，可能重視與既有環境的一致性。另一間企業則可能優先考慮特定的應用程式模式或業務使用者體驗。
這些是分析考量，並非任何一個供應商普遍勝出的證據。本文審閱的資料來源未有提供競爭實施方案的受控比較。
有用的競爭問題，是共享資料與一個持續維護的業務應用程式之間的距離。
團隊在獲得存取權後還要完成多少工作？業務使用者可以多容易地檢視答案？當某些事情出現變更時，管理員可以多清楚地追溯責任？
這些問題讓比較聚焦於文章的核心議題：受管理的業務脈絡，與反覆重建的脈絡。
平台可以提供廣泛功能，同時仍令客戶需要管理困難的交接環節。相反，較窄的部署若其界線清晰，也可以帶來可觀價值。
SAP 的多合作夥伴做法亦帶來一個較長期的互通性問題。當工作負載跨越平台邊界時，客戶需要知道哪些定義仍可重用。
開放分享機制有助建立連接性。應用程式邏輯、業務定義及營運程序的可攜性，則需要另行審視。
對企業採購方而言，這代表除了採用條件外，還要評估退出條件。資料連接只是生產應用程式所產生依賴關係的一部分。
對 Databricks 而言，這項擴展提高了市場期望。該公司正將其關係定位為更廣泛的開發及營運體驗，因而引來更廣泛的評估。
對 SAP 而言，挑戰在於其不斷增加的平台合作關係中維持可理解的選擇。採購方需要清晰了解受支援功能和問責範圍的界線。
因此，競爭意義在於實務而非噱頭。更多供應商提供通往業務資料的途徑；差異化轉向客戶能否透過這些途徑完成可靠工作的程度。
下一個訊號是可用性、語義忠實度及營運成果
下一批證據應把已公布的架構，連繫至可部署功能及可量度的業務工作流程。
第一個訊號是功能層面的可用性。未來數月，發布文件應說明客戶可使用哪些擴展功能，以及其支援範圍。
有用的更新應區分正式全面推出與預覽存取，並說明相關依賴條件。它亦應確定計劃中的助手連接之交付狀態。
這些資訊可將架構方向轉化為可評估的部署選項，從而強化公告。持續的模糊性則會限制短期規劃。
第二個訊號是語義忠實度，亦即業務定義和關係在跨系統使用時可準確保留的程度。
客戶需要揭示受支援界線而非掩蓋它們的例子。跨範疇問題及持續變動的業務定義，尤其值得檢視。
能夠透明處理這些情況的應用程式，將支持建立受管理業務基礎的論點。若經常需要人工重建，效益便會收窄。
這並不要求供應商聲稱具備完美理解。清晰的限制和可重複的評估，比起對脈絡智能作出廣泛保證，更能提供有力證據。
第三個訊號，是來自完整客戶工作流程的營運成果。相關報告應區分更快的分析、更快的實施、較低的維護需求或更佳的決策質素。
這些成果回答不同問題。更快的查詢固然有用，但不代表企業已淘汰其自訂整合架構。
同樣地，助手可以為使用者節省時間，同時帶來新的審閱責任。營運評估應包括維持其答案可靠所需的工作。
採購方應尋找已界定的基準、具名的業務流程，以及清楚交代人手參與程度的資料。當這些細節未有說明時，比較便會變得困難。
最有力的客戶證據應說明部署後發生了甚麼變化，指出哪些任務消失、哪些控制措施保留，以及機構如何量度成果。
這亦可釐清誰會最先受惠。資料工程師、管理員、業務分析師和營運使用者，會體驗同一架構的不同部分。
合作關係的重要性取決於能否連繫這些體驗。更佳的開發環境，只有當其優勢能延續至日常業務使用時才更具意義。
Databricks SAP 整合為這種連繫建立了可信的方向。其已記錄的基礎亦令餘下問題足夠具體，讓採購方可以調查。
在作出承諾前，選擇一個團隊現時難以持續一致回答的業務問題。要求供應商透過擬議架構追蹤其記錄、定義、權限及審批界線。要求提供每項所需功能的發布狀態，包括公告焦點以外的依賴條件。然後將所得工作負載與現有流程比較，包括維護和業務審閱。實用的成果，是更清楚了解誰擁有每項決定，以及哪些工作真正消失。對於 Databricks SAP 整合，這些證據將令已公布的擴展對正在評估下一項 AI 投資的企業更具意義。你的機構可利用哪項業務工作流程來測試這些主張？
