第2章 建立基于大資料的高階數字化戰略
第1章介紹了ABC及其内在技術關聯，重點強調了雲計算在最近10年的發展給大資料系統帶來的算力方面的巨大優勢，進而使得機器學習與人工智能有更好的效果。雲計算的按需收費特性使得普通企業也能參與到大資料和人工智能的工作中。本章中，我們繼續讨論企業如何抓住大資料發展在量變到質變的階段中的機會，建立應用、大資料和AI模型互動的高階數字化戰略。本章的讨論還是着重于商業理論層面，考慮到實際案例對于企業實戰的參考意義，讀者可将作者的譯著《The Mathematical Corporation: Where Machine Intelligence and Human Ingenuity Achieve the Impossible》作為本書伴侶。原著的兩位作者為世界頂級咨詢公司博思艾倫（Booz Allen Hamilton）的高管，他們在實踐過程中搜集和整理了大量出色的案例，可供讀者參考。
在《Cloud Foundry：從數字化戰略到實作》一書中，我們談到了建立在P層雲基礎上的初始數字化戰略。本章将深入讨論為何需要在大資料和AI上更新數字化戰略以及企業如何落地基于大資料的高階戰略。
2.1 基于雲原生應用的數字化戰略
在《Cloud Foundry：從數字化戰略到實作》一書中，我們詳細讨論過計算技術中以大型機為代表的第一代平台、以PC為代表的第二代平台和以雲計算為代表的第三代平台，以及三代平台的變遷之路。三代平台的技術創新催生了不同的企業數字化商業模型。PC時代和雲時代的數字化商業模式的特點如表2-1所示。
三代平台各自有其代表性技術以及背後的技術支撐公司，這些公司在時代的變遷中大浪淘沙，有成功過渡的，也有退出曆史舞台的，還有正在從第二代平台向第三代平台轉型的，當然還有很多後起之秀（比如，在幾年前，作者所在的Pivotal公司還是一個獨角獸企業，而現在已經成功登入紐約證券交易所上市，從建立到上市隻用了5年時間）。對第三代平台，我們解釋了I層雲、P層雲和S層雲的定義和意義，着重強調了以Cloud Foundry為代表的P層雲（亦叫作雲作業系統）提出的必要性，以及如何幫助企業極大地降低雲原生應用的準入門檻。
在企業數字化轉型的實踐方面，福特公司是一個典型代表。數字原生戰略的第一個階段是通過數字應用實作數字世界和實體世界的無縫互動。第一階段的數字化應用強調對企業的傳統業務進行數字化，進而建立在數字應用上的使用者互動體驗。這個階段的主要目标是快速疊代開發應用，一方面使用者通過各種APP和企業互動；另一方面，企業通過應用收集營運資料和使用者的資料。應用和資料之間的關聯關系如圖2-1所示。
這類應用的互動方式表現為雲原生應用，即後端運作在雲端，前端表現為iOS程式、Web程式或者微信小程式等。後端的資料層設計也相對簡單，通常為單節點的MySQL或者Post-greSQL系統管理的資料庫。
随着資料量的積累，企業開始進入以資料為中心的戰略。按照傳統方法，企業開始建立資料倉庫并把業務資料拷貝到資料倉庫，在資料倉庫中做統計報表或者資料挖掘。資料倉庫的使用者通常是企業本身的決策者而非終端使用者。企業決策者根據報表或者用資料挖掘所獲得的洞察來判斷企業産品的改進點，然後将改進後的産品和服務傳遞給消費者。這樣一個長鍊式的回報機制，不僅因為周期長而導緻回報延遲，鍊中各個環節都可能因資訊丢失而導緻機會錯失甚至決策錯誤。為此，企業需要建立一個新型的以大資料為基礎、AI驅動的數字應用開發方式。
在AI驅動的開發模式下，企業會進入如圖2-2所示的應用、大資料和模型的“鐵三角”營運方式。通過在應用和資料之間引入模型，可以在應用的營運過程中，讓企業根據累計的資料随時進行數學模型的建立和疊代。這些模型包括高階的分析（Analytics）模型，甚至AI模型。模型産生的智能直接輸入到應用裡，給使用者帶來更加智能的體驗。例如，現在的新聞閱讀終端會根據使用者閱讀的内容實時推薦新的閱讀内容，是以每個讀者看到的内容清單是不一樣的。而傳統的新聞用戶端則是由編輯決定内容編排，編排後的内容也是“一刀切式”地推送給所有使用者。
更加進階的例子就是無人駕駛等自治應用，在這類應用裡，模型根據收集的資料，結合曆史的标簽資料，實時判斷、決定應用的輸出，進而呈現出智能的效果。
這其實就是數字原生戰略的第二個階段—通過大資料平台實作資料積累，并通過數學模型支撐運作，進而實作AI驅動的開發。後面我們将着重讨論這個階段。
2.2 大資料和AI：企業未來的終極競争點
Gartner釋出的2019年十大戰略性技術趨勢的前三項包括自主裝置、增強分析和AI驅動的開發。雖然這三個趨勢看上去不盡相同，但仔細分析，它們的交集就是大資料。自主裝置是AI應用的展現，現在熱門的自主裝置包括機器人、無人機和自動駕駛汽車等，它們都建立在AI模型之上；AI驅動的開發是指企業高階應用融合了AI模型，應用的開發是軟體開發人員和資料科學家（Data Scientist）不斷互動的過程。軟體開發人員負責數字化應用的疊代開發，而資料科學家負責AI模型的疊代開發。根據第1章的讨論，大資料的使用對于所有AI模型的成功都是一個極其重要的因素。是以，對于企業而言，建立一個全局性的大資料戰略是在數字化世界占據一席之地的必要條件。這就像建立健康的生活習慣，雖然效果無法在一朝一夕顯現出來，但長遠來看一定是大有益處的。
設想在20年以後，所有企業都完成了數字化轉型，建立了數字化基礎設施，資料的協作方式也更加合理。那時，企業核心能力就建立在高階資料分析能力或者建立更加精準的AI模型的能力上。
仍以我們熟悉的汽車和金融行業為例。在汽車行業，面對無人駕駛，使用者不再圖新鮮感，而是要切實地比較安全性。這時，即使一個車企的安全系數比另一個車企高一點點，就可能獲得極大的優勢。而在智能養護方面，汽車保養的報警誤報率下降一點點就可能令車企占據市場先機。作為一個客運公司，能夠第一時間滿足使用者的用車請求将成為企業的核心競争力，排程算法不僅要在排程請求進來以後發揮作用，更要根據人群的密集度實時調配自己的車隊。
金融行業在大資料和AI方面的競争其實早就廣泛展開了。對金融企業來說，由于各種投資機會稍縱即逝，是以券商和投行很早就有雇傭大量實體、數學博士作為量化分析師（Quant）的習慣。現在，通過大資料和AI，金融企業可以利用金融模型時刻計算各個公開市場資産的投資機會，獲得更多收益。大資料和AI也在影響傳統銀行業務，例如小額貸款業務。傳統的商業銀行一般提供固定利息來吸引儲戶存款，然後利用和大企業的關系擷取将貸款投資給對方的機會，并從中獲益。在吸引使用者儲蓄方面，傳統的商業銀行能夠成功主要是政府擔保，例如在美國主要是FDIC擔保。在貸款方面，傳統的商業銀行一般有專員進行風險評估。這種人力稽核成本對于大額貸款是可以接受的，但是對于小額貸款而言是無法承受的。是以，中小企業或者個體工商戶要獲得傳統商業銀行的貸款是非常困難的，反而是存儲有大量使用者交易、購物和社交資料的網際網路企業，通過利用大資料和機器學習模型，很容易對小額使用者貸款請求進行風險評估，進而快速放款投資。另外，随着知識密集企業的興起，傳統的資産抵押融資慢慢轉變為股權融資，大量的私募投資的興起，也給商業銀行獲得儲蓄帶來挑戰。大型的私募基金通常有大量的行業分析師，他們逐漸建立起一個行業知識系統，對于股權融資企業的風險模型建構得越發精準。作者也曾給一些商業銀行提過戰略建議，建議它們圍繞現有的使用者（存方和貸方）資料的動态來外推那些需要股權融資的企業的風險分數，進而獲得低風險投資機會，在投資有效的情況下募資也必然容易。本質上說，金融機構的主要職責是資源配置設定，它要獲得競争優勢，勢必要從上遊擷取資金機會并從下遊獲得投資機會。根據現有的使用者資料，做出精度高于競争對手的模型就可以更好地捕捉這些機會。國内不少知名的商業銀行已經認識到數字化、大資料和AI帶來的機會，紛紛成立科技公司從事小額貸款和私募市場投資業務。
汽車行業和金融行業因為在數字化的過程中積極建立大資料和AI戰略，提供更好的産品和使用者體驗而為人們津津樂道。讀者不妨對比一下10年前汽車沒有導航和金融業沒有網上銀行的體驗。建立在大資料和AI之上的創新是真正的技術提供生産力的代表，它帶來了更多、更加公平的紅利。在數字化出現之前，很多企業和個人通過資訊壟斷獲得套利。就像熒幕上塑造的傳統西方銀行家的形象：一邊說服VIP客戶存錢，一邊與VIP客戶社交以擷取項目投資機會。雖然我們認為這些商人通過投機取巧獲得财富是不公平的，但從通過資訊流動達到資源優化配置的角度上來說，這種做法似乎無可厚非。深究一下，這裡的不公平實際上來自于資訊擷取的不對等，因為這些商人利用掌握的資訊為己牟利，而非創造更好的模型來為投資方和貸款方提供更好的服務。随着數字化程度的加深，資訊擷取、流通和使用将不斷改善，企業獲得的資料更多地被提供給資料科學家用于改善企業的服務。這就是Eric Schmit在《How Google Works》一書中提到的：“以前在離交易越近的地方擷取的報酬越多，現在慢慢轉變為離産品越近的人擷取的報酬更多。”因為前者的優勢建立在資訊壟斷上，後者的優勢建立在資訊的處理和再加工上。
2.3 大資料戰略的落地
如果企業在雲原生數字化應用營運一段時間後，建立了持續創新的文化并積累了一定數量的資料，就可以考慮建立基于大資料且由AI驅動的高階數字化戰略。在第二代平台時代，企業部署IT系統的時候通常會有咨詢公司提供同行的成熟案例。企業隻要把同行成功實施的軟體大體不變地安裝下來，再加入少量定制功能即可。而在基于大資料和由AI驅動的高階數字化戰略中，不能照搬同行的成熟案例和經驗。首先，行業領袖的數字化軟體基本上是在PaaS平台自主開發的，它的軟體不能被拷貝。即使可以拷貝，它的軟體的更新速度也使得拷貝版本很難跟上。其次，企業的高階數字化戰略的輸出通常是訓練過的并且符合自身需要的數學模型的參數。即使将這些模型和參數拷貝到自己的企業，也與企業的核心優勢不比對。那麼，成功地将高階數字化戰略落地的企業案例是否可以被學習呢？答案是依然可以，但需要進行更高層次的抽象，學習這些大資料企業高階數字化戰略成功背後的“中繼資料”。所謂中繼資料，是資料庫裡面描述其他資料的資料。本節将讨論高階數字化戰略成功背後的中繼資料：
- 大資料和AI人才
- AI驅動的開發方法和文化
- 大資料基礎設施
一旦企業建立了基于這些中繼資料的數字化戰略，就能在基于大資料的智能應用上推陳出新并持續創新。
2.3.1 大資料和AI人才
第一階段的數字化應用開發的主角是軟體工程師。他們可以根據數字化業務的需求，在PaaS雲上采用雲原生的方式持續疊代應用開發。進入基于大資料和AI的高階數字化階段以後，企業需要引入兩個新的角色：資料工程師（Data Engineer）和資料科學家（Data Scientist）。
資料工程師主要負責企業大資料基礎設施的建設以及企業内部資料的收集。這個角色和傳統的DBA角色類似，但是比起傳統的DBA，他們管理的資料基礎設施的規模更大，采集的資料量更大。更明确地說，傳統DBA一般管理Oracle、MySQL和PostgreSQL等關系資料庫系統下的事務型資料庫，而資料工程師不僅要管理這些關系資料庫，還要建立和管理Hadoop或者Greeplum等系統下的分析型大資料系統。在這些大資料系統裡，還需要建立一定的資料模型來存儲和管理企業的資料。這類分析型資料模型也與傳統事務型資料模型有很大差别。以使用者的收貨位址為例，傳統事務型資料模型隻需捕獲到使用者的目前位址，而分析型資料模型通常需要捕獲使用者曆史中所有更新過的位址。作者所在公司就有一個專門的資料工程師團隊，他們幫助企業建立基于Greenplum的大資料系統，建立分析型資料模型，收集企業營運産生的資料。資料工程師的教育背景通常是計算機專業，或者受過計算機專業教育訓練。
資料科學家對于大部分管理者而言是個全新的職能崗位。相比軟體工程師和資料工程師，他們未必需要有計算機專業背景，而是可能來自于數學、統計和實體專業。其實，華爾街早年的量化分析師就算得上資料科學家，他們的主要工作就是建立各種數學模型。早期的數學模型主要建立在統計方法上面，現在的機器學習模型主要建立在大資料上。因為AI驅動的數字化戰略的崛起，使得資料科學家的人才缺口急劇擴大。資料科學家作為正式的工種與大資料的概念同時産生。《哈佛商業周刊》在2012年的10月刊上曾發表過一篇名為《資料科學家：21世紀最性感的工作》的文章。文章給出了一個例子：斯坦福大學實體學博士畢業生Goldman通過自己建立的資料模型來給領英使用者推薦可能認識的朋友。這個模型給出的推薦相較其他來源的内容在領英同一個頁面位置的點選率要高出30%。IBM在2017釋出的報告中曾預測美國的資料科學相關的崗位數量到2020年将增加364?000個，總數将達到272萬以上。可見，工作崗位需求的增長速度遠高于人才供給增長速度。這也使得資料科學家的薪水漲幅驚人。
對于企業而言，建設資料工程師和資料科學家團隊可以從以下兩方面努力：
1）選擇好的大資料和AI平台，盡量平民化資料模型，降低人才的進入門檻。
2）選擇合作夥伴，在實踐中培養人才。作者所在公司的資料科學家團隊會通過結對方式，在實踐中幫助轉型企業建立他們的資料科學家團隊。從供給端看，高等教育機構和産業領袖應重視資料科學人才的培養，并從産業和教育的角度共同促進人才培養。
因為資料工程師和資料科學家崗位的出現，企業通常會設定首席資料官（Chief Data Off?icer，CDO）來代表資料科學家出席公司執行層的圓桌會議。CDO在公司的戰略建議權很大程度上能夠反映該企業所處的數字化轉型的階段。如果CDO的決策影響力很大，通常意味着該企業已進入AI驅動的階段。後面我們将在AI驅動的公司文化中深入讨論這個問題。
最後要強調的是，這三類人才不是互斥的。優秀的軟體工程師通常具有紮實的計算機科學知識的功底，他們也可能同時擅長資料工程和資料科學。但是企業要同時在這三方面下功夫。原因有以下兩方面：一是這類“三位一體”的通才可遇不可求；二是即使有這樣“三位一體”的人才團隊，也會因為工程量巨大而不得不分而治之。是以，作者建議，在人才培養方面，團隊的每個成員都要有兩方面知識的重疊。例如，軟體工程師要懂得資料模型，資料工程師要懂得資料科學，資料科學家要懂得應用開發。這樣的配置有助于提高團隊的溝通效率，也能增強團隊成員之間的同理心。
2.3.2 AI驅動的開發方法和文化
AI驅動的開發方法要求應用、資料和模型三位一體地螺旋疊代上升。《Cloud Foundry：從數字化戰略到實作》一書中提到的測試驅動和持續傳遞的方法對此同樣适用。這種情況下對于産品經理的要求比較高，他需要和各個團隊的技術負責人一起協調建立産品開發的任務清單（Backlog）。為了確定靈活性，在人才配備方面，應盡量確定人才具備應用、資料和模型這三種技能中的兩種。各個團隊在接口方面要保證一定的穩定性，例如，在模型團隊的輸入/輸出比較明确的情況下，應用開發團隊隻要根據模型的輸出來決定應用的輸出即可。這樣使用者看到的應用輸出就是穩定的，随着模型團隊的改進，使用者會感覺到應用的輸出越來越智能。比如，前面提到過的新聞閱讀終端的例子，使用者會看到内容的版式相對穩定。同時，因為模型團隊的精度提高，每個版面的内容将越來越精準地反映使用者偏好。這裡提到的方法聽上去不難，但是要順利實施，讓這些方法發揮出最大的效用，企業的文化土壤也需要做出相應的調整。
AI驅動的開發文化要求企業在戰略決策層面加入一個新的次元，即考慮如何将建立在大資料之上的模型智能第一時間通過數字應用回報給使用者。比如，新聞閱讀終端的決策者要考慮如何根據使用者的曆史通路資料建立模型，以通過模型在第一時間把相關的内容推薦給讀者；視訊内容網站也要考慮同樣的問題，因為準确的内容推薦會讓使用者消費更多的視訊。
加入一個新的次元到決策過程中聽上去很容易，但實施起來卻非常困難。反過來考慮，如果這個事情很容易推進，那麼傳統的新聞浏覽終端早就自動進化到類似于頭條新聞這樣的新一代新聞閱讀終端。傳統新聞閱讀終端和現代應用終端的差别就在于我們所說的新次元：新的新聞終端從創立第一天就把競争屬性建立在使用者内容推薦模型上。讀者可以想象一下，假設一個提供傳統新聞閱讀服務的公司的董事長将一個知名的資料科學家引入公司擔任首席資料官，讓他幫助公司建立AI驅動的新聞閱讀終端。很可能他進公司的第一天就要對各個業務部門提出各種要求：
- 新聞采編部門要對内容進行更加精細的标注。
- 應用開發團隊需要注入大量的代碼來擷取使用者閱讀行為習慣資料。
- 資料工程團隊要建立大資料基礎設施以收集使用者資料。
- 資料科學家團隊要建立模型對内容進行推薦，應用開發團隊要根據推薦呈現内容。
這個過程不是一次性完成的，而是螺旋性疊代的。更為糟糕的時候，在看到産出之前會經曆一段時間的投資，甚至影響原有新聞終端釋出内容的速度。用不了多久，原有的采編部門、開發團隊和資料團隊就開始向董事長抱怨，一次兩次董事長可能堅持下來，但如果抱怨次數太多，董事長就可能放棄AI優先的戰略。然後，得出一個錯誤的結論：現在實施AI驅動的戰略為時過早。而事實上，AI驅動的戰略是正确的，隻是沒有落地到對應的文化土壤。
在這樣一種AI驅動的文化裡面，CDO要從一開始就在公司執行層的圓桌會議中有一席之地，而且其他功能的主管（CIO/CTO）一開始就要習慣照顧到CDO的訴求。從公司戰略層面，如果認為大資料和AI戰略是突破性創新，按照《創新者的窘境》一書中的理論，最好還是成立一家新的機構。CDO成為那家新機構負責人，和現有的高管以業務關系合作，進而保持一定獨立性。如果公司從戰略層面認為大資料和AI還處于連續性創新階段，那麼CDO一開始就要避免設定過高的目标。在實施深度學習之前，可以利用進階分析功能找出一些小的改進點，采用持續改進的方法讓其他高管看到效果。按照《Cloud Foundry：從數字化戰略到實作》的方法論，其實軟體應用開發的成功率已經非常高。但是相比軟體應用開發，大資料和AI項目的失敗率要高很多。
2.3.3 大資料基礎設施的建設
前面提到，在大資料和AI驅動的企業數字化戰略中，應用、資料和模型是螺旋式上升的。在企業實施大資料和AI戰略之前，還有一項必要的前期工作，那就是大資料基礎設施建設。通常，企業進入第一階段的數字化轉型以後，已經有了一些雲上IT基礎設施，包括一些簡單的應用開發運維（DevOps）環境。這裡将讨論建立第二階段的大資料基礎設施的必要性和實際選型中的考慮。
1. 必要性
在讨論大資料基礎設施的建設之前，我們先看看其他的實體基礎設施。2008年，作者從美國回國度假，看到國内正在飛速建設高速公路和高鐵的基礎設施。當時正值美國房産泡沫危機，雷曼兄弟公司倒閉。作者在想：“國内這些設施的建設是以刺激經濟為目标呢？還是以應用（例如電子商務和春運）需求滿足為目标，或者兼而有之？”經過10年的建設，我們看到很多不可能成為可能：遊客乘坐高鐵可以在10個小時内從一個城市到達國内的大部分其他城市，電商的物流可以在12小時内完成産品投遞（美國的亞馬遜需要24～48小時）。10年前一個經營生鮮産品的企業無法想象如何線上上進行交易，而今天，生鮮産品也面臨線上的激烈競争。
在我國基礎設施蓬勃發展的時候，美國的雲計算基礎設施也在蓬勃發展。2006年，谷歌提出雲計算的概念以後，亞馬遜推出了第一款公有雲計算服務AWS，雖然分析界對其并不看好，但是矽谷公司确實看到了一個基礎設施帶來的時代變更。作者當時在甲骨文公司（Oracle）的伺服器技術部門從事網格計算的資源調控（Grid Control）工作。2007年，甲骨文公司看到了時代變更，它的網格計算部門也開始大規模部署到雲計算，為甲骨文雲計算奠定基礎。2010年，阿裡雲已經在虹橋機場附近樹立起雲計算的廣告牌。現在，騰訊雲、阿裡雲和華為雲将中國雲基礎設施建設推向新高潮。筆者在2008年做企業調研，了解企業對于雲計算的接受度時，大家普遍的觀點是不會把自己的軟體運作在外部。到2017年，阿裡雲的營收額達到了66億人民币（美國的亞馬遜雲更達到了180億美元之巨），公有雲已經成為企業的影子IT部門（換言之，如果企業自己的IT部門做得不好的話，業務部門就會采購公有雲）。
如果感覺現在談公有雲基礎設施和交通基礎設施有些事後諸葛亮的話，那麼我們回歸到大資料正題，它是當今世界正在發生的一場如火如荼的數字化基礎設施的建設。在交通基礎設施的建設上，美國的高速公路建設領先于中國，但是中國的高鐵網通過躍背（leapfrog）效應領先美國；在雲基礎設施方面，中國的雲供應商緊跟美國；而在大資料基礎設施的建設上，中國則和美國齊頭并進。
在前面關于ABC關系的讨論中提到過，機器學習和AI模型是一個特定類型的數學模型。這些模型随着資料量的上升，精度會相應提高。可以預見，未來企業的競争要麼基于模型，要麼基于資料，要麼兼而有之。一般企業不具備模型的基礎理論研究能力，而且學術機構一旦在模型上有所突破就會很快向所有機構開放。是以，企業要想在機器學習的競争中獲得優勢，大資料基礎設施更為關鍵。大資料基礎設施建設是企業可以操作且必須操作的。進取型企業為了在未來競争中獲得優勢，已經開始腳踏實地建設大資料基礎設施，這不僅有利于支援現有的機器學習應用，也為現在尚未知道的未來模型做好準備。就好像從前建設高鐵和高速公路的時候，雖然沒有預見到今天蓬勃發展的物流業，但是卻為今天的物流創新做好了準備。
在作者接觸過的中國500強企業中，大部分企業在大資料的基礎設施中投入了千台以上的伺服器，并且設有專門的資料基礎設施團隊。這些基礎設施上一般運作了Greenplum和Hadoop等多個現代大資料平台軟體，支援着企業業務團隊的各種請求。同時，大資料基礎設施也遵循獨立原則，以保證資料的完整性和安全性。
2. 選型
在今天五花八門的産品和技術當中，商業決策者選擇一個适合自己的技術作為基礎來投資十分重要。作者在為大型公司戰略層提供咨詢的過程中，通常建議它們從以下幾個次元考慮：
- 硬體标準開放性
- 軟體源代碼開放性
- 原創技術團隊穩定性
- 雲化
（1）硬體标準開放性
雖然技術提供方可以直接提供生産好的硬體，但是企業應該考慮是否可以獲得硬體配置規格，并且這個配置規格需要建立在商品化的硬體元件上面。所謂商品化，就是可以從市場上直接購買，而非定制生産和研發。這個考量可以幫助企業避免被鎖定在特定的硬體上而失去自主可控的創新能力。
（2）軟體源代碼開放性
這是指技術提供方給出的基礎源代碼是否對外開源，而且是否建立在Apache許可等比較好的開源許可上面。通常，技術提供方的興趣主要在于獲得軟體許可收入，是以他們提供的服務數量有限。基于開放源代碼的技術一般有龐大的服務社群，企業能夠獲得更加豐富的第三方支援管道。另外，開源也能避免企業被鎖定在閉源軟體上，進而喪失自主可控創新能力。
（3）原創技術團隊穩定性
這一點可能是當今最重要的一個考量因素。在開源和開放經濟學的理念下，企業支付的軟體許可費最終是為了獲得原創技術團隊的創新能力，或者說是企業分攤原創技術團隊需要獲得市場定價的成本和合理利潤。但市場上的開源技術有諸多誤區：
第一種誤區是繼承技術供應商放棄開發的開源産品。市場上的很多開源軟體産品是技術供應方不再想維護，從公益的角度将源碼開放出來的。這意味着原創技術團隊不再持續投入。繼承這樣的開源代碼和自己從頭開發的成本幾乎等同乃至更高。
第二種誤區是認為知名企業的團隊建立的開源項目就是好技術。很多網際網路公司本身的利潤來源不是軟體收入，是以為了提高技術團隊的實力，公司會鼓勵技術團隊寫出好的開放性代碼并提供給社群。這樣的産品和代碼很難長時間保持熱度，随着主業産品方向的改變，代碼的原創團隊很可能被配置設定到其他項目上而不再對源代碼進行維護和改進。
第三種誤區就是使用社群業餘愛好者發起的開源産品。大家都希望看到興趣愛好支撐的創新，這也是一個好的起點。如果社群團隊不能探索出一套穩定的自治模式，最終會失去原創團隊。在一個好的自治模式下，通常會出現一個持續穩定的商業公司來支撐對應的開源産品。舉個例子，Redhat和Linux社群就是一個非常健康的關系。相比之下，OpenStack技術和Hadoop技術在多年之後還沒有形成一個維系原創團隊持續投入的模式。
（4）雲化
目前主流的大資料技術都可以直接運作在實體硬體上，而且它們通常也實作了《Cloud Foundry：從數字化戰略到實作》中定義的雲計算的基本功能。例如，它們實作了軟硬體分離、橫向水準擴充等。具體來說，像Greenplum這樣的大資料系統中的任何一個實體機器故障，插入新的硬體系統都可以重構這個故障的硬體，同時業務的增長也可以通過加入更多的伺服器來滿足。它的缺點是企業要維護兩套系統：大部分數字化應用運作在一套基于I層雲和P層雲的雲計算系統上；大資料系統運作在幾百台伺服器的實體裸機上面。這種配置會導緻管理成本上升。現在的主流技術供應商都把大資料系統加入雲計算的PaaS層雲服務裡面，例如AWS的Redshift和Alibaba基于開源Greenplum的HybridDB。截至本書完稿時，這個技術變遷還在進行中。
這裡作者想強調的是，不要等待技術供應商把運作在實體機器上的大資料系統向I層雲上遷移而成為PaaS雲技術的一部分，作為數字化轉型高階階段的管理者要關注把PaaS雲的雲原生應用遷移到PaaS雲的大資料上。也就是說，不是從數字化應用的需要來考慮大資料的建設，而是要考慮大資料的建設能夠為應用提供的可能，進而實作從滿足需求到創造需求的觀念轉變。
2.4 大資料和AI的展望
AI驅動的數字化文化和戰略才剛剛起步，我們要清醒地認識到，現在報以重大期望的AI應用還需要一個漫長的逐漸改進的過程。但是，這種文化下驅動的大資料基礎設施的建設，就好像高鐵網的建設，會帶來很多意想不到的驚喜。
大資料基礎設施用來存取企業和使用者資料。企業會使用Greenplum等軟體把企業的營運資料和産品服務相關的使用者資料存儲起來；使用者個人免費或者付費使用郵件、社交和網盤等應用的時候，直接或者間接地使用了網際網路公司提供的共享基礎設施。當資料基礎設施越來越完善，企業和使用者不必再定期删除資料，也不用擔心資料丢失。哪怕遇到火災或地震這樣的天災人禍，資料都有異地災備能力。資料的組織更加便于通路，資料的通路速度也在繼續提高。消費網際網路的崛起創造了大量的應用，誕生了一批新的公司，投資圈通常将其稱為“網際網路的上半場”。但是，地球上70%以上的資料還在各行業的企業手中，這些企業因為大資料基礎設施的建設也具備了實施AI驅動的戰略和文化的基礎。投資圈把這個機會叫作産業網際網路，也就是“網際網路的下半場”。
大資料基礎設施的建設不僅帶來了各種AI應用的可能，也對企業文化乃至社會的生産合作方式産生了巨大的影響。讀者不妨想象一下一個未來機構因為資料基礎平台完善而擁有的問題求解方式和招聘方式的變化。假設一個國家的城市規劃相關部門進行招聘，它可以利用大資料完成簡潔而高效的面試：把一個關于城市擁堵資料模型的實際項目釋出在網上，讓應聘者根據現有的資料找到改善城市擁堵的方法。如果那時已經通過各種應用實作了數字世界和實體世界的數字化互動，例如紅綠燈的等待時間、地鐵網的車次排程、雙向車道動态調配、無人公共汽車的時間和路線都可以通過APP設定，而資料已為政府機構所掌握。通過這些資料，面試者會發現無人駕駛車的排程總是落後于城市人群擁擠，例如淩晨兩點因某個大型演出結束導緻擁堵，這時調車過去就會因落後于擁擠事件而造成惡化。此時，面試者可以設計一個人群熱度預測模型，提前排程無人駕駛汽車在即将發生擁堵的地方等候，進而及時疏散人群。規劃部門就可以利用這個模型把大型活動和無人駕駛公交系統進行關聯，進而改進交通系統。試想，能提供這種模型的應聘者還會被拒嗎？而且新的模型送出到大資料基礎設施平台後，交通部門可以看到立杆見影的效果。
資料基礎設施的完善帶來的創新靈活性也會影響生活的方方面面。與寫5萬文字的文檔來解釋一個商業機會相比，數字工作者可以直接将5000行代碼和模型加載到大資料基礎設施上展現結果。大資料基礎設施支撐着模型和人的協作互動，擁有資料和模型的人可以快速創造價值。