基於AI的資料架構:業務在前,協作在後
來源:資料驅動智慧
當我們談論資料倉儲問題時,常見的反應之一是“那麼你會推薦什麼”,所以在這裡我將把它們整合到一個新的架構中,我將其稱為“基於AI的資料架構”。我將介紹您需要如何思考未來,為什麼我們已經知道目標架構,以及為什麼這種方法可以極大地改善現有資料人員的資料環境。
這裡的考慮是,我們需要一種資料驅動而不是跟隨的架構,一種支援而不是對抗資料反轉的架構。
基於AI的資料架構——目標
未來資料架構的想法非常簡單:
未來的商業優勢來自於資料和人工智慧,有效的業務領域必須掌控資料和人工智慧,這意味著它的目標非常明確:
反映組織的運營和責任邊界
以確保人工智慧決策可信的方式將人工智慧嵌入到運營中
確保企業對資料準確性負責
透過人工智慧和資料實現業務領域之間的協作
實現與合作伙伴和市場的外部協作
在人工智慧對業務至關重要並將改變業務運營方式的世界中,我們需要一種包含這種轉變及其含義的方法。這也意味著,如果您不願意接受這種變化,那麼您還沒有準備好迎接基於AI的資料架構。
基於AI的資料架構——原則
有效的人工智慧是必選項
商業的未來是由人工智慧驅動的,沒有一個商業領域不受影響,也沒有一個成功的商業領袖不接受這一現實。如果人工智慧是可選的,那麼變化也是可選的,如果你所在的企業認為人工智慧是可選的,那麼你應該尋求的是領導層的改變。
資料控制是一個操作問題
這意味著該架構必須關注元映象(數字現實)的控制理念。
合作就是未來
沒有一個業務領域,或者實際上沒有一個企業能夠擁有確保最有效結果所需的全部資訊。您需要外部資訊,無論是來自其他業務部門、合作伙伴、市場還是現實。這意味著合作是未來的基礎。
本地思考,全球行動
該架構必須支援業務的本地操作控制,它不能強迫每個人都有單一的檢視,它不能要求一個區域以限制該業務區域的方式受到另一個區域的視角的限制。因此,該本地區域需要對更廣泛的業務負責,以提供有關其他區域所需的資訊子集的準確業務檢視。
歷史很重要
該架構的最終原則是歷史很重要,歷史是支援下一代人工智慧的因素,它為您提供未來的基礎。如果你對自己的歷史沒有準確的瞭解,那麼你就沒有準確的能力來實現你的未來。
我們並不擁有現實的全部
加倍努力“全球行動”,我們的架構必須處理這樣一個事實:外部工作存在而我們無法控制它。這意味著我們的架構必須基於AI的資料架構。
好的,讓我們進入基於AI的資料架構本身。
基於AI的資料架構著眼於兩個不同的挑戰,並將它們合併到一個架構中。第一個挑戰是執行速度,第二個挑戰是在交易後資訊上進行協作。它們與外部世界(市場)互動,但以兩種不同的方式進行互動,因此基於AI的資料架構既有操作速度互動、資料驅動業務,也有交易後協作部分。基於AI的資料架構的頂部是操作速度挑戰,使用嵌入操作流程中的人工智慧來調整和決策。基於AI的資料架構的背後重點是確保業務領域可以在內部和外部進行協作,並且可以正確共享實現協作的資料子集。
在基於AI的資料架構中,資料網格不會消失,它會成為新資料基礎設施的後端和工程部分,但我們更加關注特定業務領域內的資料驅動業務,同時資料網格可能是業務範圍的,它僅在這些業務上下文中提供資訊並從資料驅動業務領域接收資訊。
業務在前端
該架構的前端是業務,即當前以應用程式、事務和流程為中心向資料和人工智慧驅動的轉變。正是在這個領域,我們期望企業能夠實際控制,不是資料產品,而是其運營現實。我們並不期望它為它所做的一切生成資料產品,而只是為跨業務協作所需的那些子集生成資料產品。
這個業務重點領域的要點是,當企業依賴人工智慧時,它必須控制這些人工智慧的決策環境,這意味著操作檢視、元映象必須反映現實,而人工智慧的治理則與該準確性相關。
這裡的目標是使企業能夠控制人工智慧並對其準確性負責,因此我們正在考慮改變企業文化。這實際上並不是架構中的技術變革,而是支援組織變革所需的架構。
跨越業務方面的是新環境的治理,這是管理人工智慧風險的機制,並確保人工智慧的執行符合整體業務戰略。這包括新設施以及更重要的商業文化和治理變革,以確保成功的業務採用。
協作在後端
在業務範圍資料網格中,我們專注於兩個核心挑戰
基礎要素產業化
實現圍繞資料的協作
為什麼這是一個協作?因為從歷史上看,我曾經將一些東西描述為資料質量中最大的謊言:
“我們應該從源頭上解決這個問題”
但後來因為我們專注於報告,而報告團隊對應用程式團隊的權力為零,所以---。我們基本上建立了管道來處理這個問題,並因這些問題而受到指責。
在人工智慧驅動的未來,企業必須掌握控制權,並且必須切實確保其運營現實是準確的。這意味著我們的資料網格突然不再是一個擁有零權力改變生產的“資料產品負責人”,而是擁有基於KPI的理由來確保其準確性的實際業務領導者。
這意味著我們可以更少地專注於清理垃圾,而是專注於機制和工程的標準化。我們可以專注於建立資料網路基礎設施基礎,將資料轉化為組織的發令槍。我們不僅可以利用它來提供一種可能由GenAI支援的單一方式來攝取、釋出、請求和委託資料,還可以提供“萬物的歷史”的基礎來推動資料研發和創新。
在由於文化發生變化而導致業務被迫掌控的世界中,我們的架構可以專注於機制,而不是DQ管道和審查委員會。這並不意味著中央資料團隊不重要,而是意味著它們更重要,因為企業現在實際上關心資料。這確實意味著中央團隊在治理或執行神話般的單一規範形式檢視方面並不那麼明顯,但您真的希望在失敗的資訊治理嘗試中變得可見嗎?或者您想成為魔術師,確保資料是系統中執行的血液,負責保持資料驅動業務的執行,並在需要的時間和地點交付資料以推動業務成果?
基於AI的資料架構提供與市場的協作
下一代架構要做的部分工作是實現業務的外部協作,並使業務能夠對市場中的外部因素做出反應。有兩種明確的方法可以做到這一點。首先,透過使用協作人工智慧,兩個組織將在純人工智慧或人工智慧輔助流程中進行互動,例如採購;其次是協作,在其生態系統的背景下實現業務的端到端願景。
當採用以業務為中心的方法時,這是相當明顯的,需要一個資料架構來支援與合作伙伴和消費者的運營速度協作,並且需要一種方法來構建完整的端到端圖片來支援策略。您需要一個能夠以業務方式擁抱和參與市場的架構。
在基於AI的資料架構中,執行速度協作是內部人工智慧協作的延伸,除了超出界限工作時圍繞安全性的額外挑戰。
生態系統協作往往在交易後的意義上發揮作用(比如AppleWatch跟蹤鍛鍊並在完成後向AppleHealth報告),它是協作資料市場的一部分,同樣,圍繞安全性的新挑戰也隨之而來。在聯邦世界中運作。
有了基於AI的資料架構,將開始迎接新的挑戰,您可以將自己的人工智慧部署到其他人的基礎設施中,處理他們的資料,但與您進行通訊。例如,消費品製造商派遣員工與零售商合作,以最大限度地提高銷售額並減少庫存。這些人工智慧是運營業務挑戰的一部分,但現在遠端部署,從技術上講,這對我們來說是一個奇妙的新挑戰,但它首先需要業務合作伙伴同意應該這樣做,並且認為這樣做是有價值的正在做。先業務,再協作。
基於AI的資料架構—專為人工智慧成為商業優勢的世界而設計
基於AI的資料架構的原因與技術無關,而是與資料透過人工智慧對業務的影響的轉變有關。如果企業對在運營中使用人工智慧不感興趣,或者樂於在不準確和不一致的資料上使用人工智慧,那麼他們還沒有準備好接受基於AI的資料架構。基於AI的資料架構適用於已經認識到需要擁有資料的企業,因為該企業的競爭優勢及其業務領導者的職業發展與他們如何有效地利用人工智慧以及利用人工智慧的方式息息相關您必須能夠有效地建立準確反映業務現實的決策環境。
基於AI的資料架構需要新的資料文化
這是採用基於AI的資料架構所需的元映象心態,希望在其資料中反映業務的運營情況,這是一種新的資料文化,其中“資料質量”並不真正存在,因為“資料準確性”才是真正存在的很重要。在這種文化中,企業不再將資料視為報告或電子表格中的內容,而是將其視為業務的生機勃勃的基礎。這種文化認為人工智慧不僅是一種業務資產,而且實際上是業務團隊的一部分。在這種文化中,確保您的團隊(尤其是人工智慧)對您的業務現實有準確的瞭解是一個安全問題,是一個業務關鍵問題,不存在與業務分開的“資料團隊”之類的東西。由於質量問題而受到指責,但有高管負責確保其準確性。
在這個世界上,企業的首要任務是控制資料,而不是把垃圾扔到牆上讓IT來清理。
基於AI的資料架構讓資料工作變得更有趣
這種新文化意味著下游我們面臨著一個非常不同的挑戰,我們聘請了想要操作準確性的高管,我們不需要花很長時間在會議上爭論模式、企業資料模型或交易後資料質量規則。相反,我們可以專注於有趣的事情:讓事情發生。這意味著要關注使這一切發生的資料網路基礎設施,並將其設計成為一種美麗的工業化商品。這意味著制定讓企業對準確性負責的指標和措施,意味著建立協作人工智慧的新方法,意味著提供一種機制,透過該機制可以將內部和外部協作交付給資料驅動型企業。
當然感覺比除錯DQ管道有趣得多,因為有人在SAP中輸入了無效的國家/地區程式碼。
改變文化,採用架構
當資料文化發生變化時,其業務處於領先地位,這意味著資料準確性成為基礎,治理成為標準操作程式的一部分,這將顯著簡化資料網格的挑戰,並允許資料人員專注於圍繞資料和人工智慧的協作,讓人們共同推動新業務優勢。
如果你不能改變文化,那麼架構的改變就不能解決問題,但如果你能做出改變,那麼架構就會將這種文化帶入業務。
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70024923/viewspace-3007287/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 按照業務領域畫資料架構圖 業務架構 資料架構架構
- 阿里架構師,講述基於微服務的軟體架構模式(附資料)阿里架構微服務模式
- 基於 RocketMQ 的 MQTT 服務架構在小米的實踐MQQT架構
- 關於軟體架構和業務架構的思考架構
- 基於SpringCloud的微服務架構設計SpringGCCloud微服務架構
- 基於hyperf架構的後臺骨架系統架構
- 微服務下的資料架構微服務架構
- 在微服務架構中的資料一致性微服務架構
- ASQuery:基於Query的時序動作分割新架構架構
- 基於大中臺架構的電商業務中臺最佳實踐之一:業務中臺總體架構介紹架構
- 基於Redis構建微服務的反應式架構 - bitsrcRedis微服務架構
- mysql資料庫的基礎架構MySql資料庫架構
- 招商證券業務系統基於OceanBase完成架構升級架構
- 業務架構架構
- C# 搭建一個 基於ISqlSugarClient 三層架構框架 涉及資料庫倉儲 然後中間又有業務邏輯層 案例C#SqlSugarclient架構框架資料庫
- 微服務架構 | 4.2 基於 Feign 與 OpenFeign 的服務介面呼叫微服務架構
- 微服務架構 | 5.2 基於 Sentinel 的服務限流及熔斷微服務架構
- 大資料元件-Hive部署基於MySQL作為後設資料儲存大資料元件HiveMySql
- 微服務業務架構的探索微服務架構
- 基於Go語言構建的萬億級流量大資料平臺架構Go大資料架構
- 基於 Hyperf 的 RPC 簡單微服務架構試探RPC微服務架構
- 新核心業務系統資料架構規劃與資料治理架構
- 基於 Echarts 的資料視覺化在異構資料平臺的實踐Echarts視覺化
- 【Gator Cloud】架構篇 - 提供基於雲原生的資料安全保護Cloud架構
- QToss:基於.NET架構的跨境電商的工具,助力企業實現智慧資料營銷QT架構
- 微服務架構在阿里的演化微服務架構阿里
- 大資料基礎架構Hadoop,終於有人講明白了大資料架構Hadoop
- 作業幫:探索多雲架構下的資料庫叢集解決方案架構資料庫
- 微信後臺基於時間序的海量資料冷熱分級架構設計實踐架構
- 基於SpringCloud的Microservices架構實戰案例-架構拆解SpringGCCloudROS架構
- 基於 dubbo 的分散式架構分散式架構
- 介紹基於事件的架構事件架構
- [雲原生微服務架構](十)微服務架構的基礎知識微服務架構
- 基於雲服務的個人網站架構設計網站架構
- 微服務架構 | 4.1 基於 Ribbon 的負載均衡詳解微服務架構負載
- 微服務架構 | 7.1 基於 OAuth2 的安全認證微服務架構OAuth
- 基於 K8S 構建資料中心作業系統K8S作業系統
- 資料治理實踐:後設資料管理架構的演變架構