航司數字化轉型的重點投放及IT要素 (2)

來自專欄 Airline Data+

前言

如前篇所述，航司的數字化轉型是一個綜合的體系工程，不能簡單的通過增加銷售量來拉動，也不能簡單的通過提升IT技術和管理水平。必須有的放矢的投放在幾個關鍵IT環節。DevOps、雲計算、迭代、數據處理、集成平台是前篇介紹的思路。下面就針對另外幾個IT因素闡述一下個人理解。

IT因素

那對於航司的數字化轉型，其關鍵的幾個IT方面的因素，是需要航司結合自身條件和規劃，逐步建立從戰略到投放的長久方案，並構建專業性的團隊逐步推進。最關鍵的構建一個團結一致、數據過硬、業務精通、思維開拓、動作敏捷的團隊，尤其是電商中後台團隊。

精準

精準營銷，千人千面，旅客個性化，A la carte等等，都是要構建針對單一個人的產品和服務。但是談何容易。

a) 數據

最關鍵的是構建數據，基於人的Single Customer View，以及相應的Behavior Data。航司往往要麼沒有還沒有起步，要麼局限於數據來源。數據又不能買賣，大量的旅客數據來源於常旅客、電商會員、高質量的乘機記錄或銷售信息、電子客票、預訂信息、或再來自中航信的離港等數據。有些航司也在開始考慮收集電商直銷平台的互聯網數據。但是這些只能對高頻和忠誠用戶，有更好的收集效果。但是對於航司擴展客戶群體，吸引那些低頻客戶或潛在客戶還是微乎其微。所以我接觸民航總局的時候，就曾經考慮，是否真正有一個全國性的旅客信息平台，甚至中航信的數據是否真正能發揮價值。

b) 來自於資深行業專家的模型/演算法

數據的缺失，是可以通過特徵工程和數學模型乃至特定的演算法去彌補的。但是一定有行業的背景的資深人士，而不是BAT等IT領域的團隊。最近接觸過Baidu的AI團隊。確實其能夠提供資深的工程師、強大的技術支撐等，但是關鍵的是行業業務的領悟和多年的掌握。

所以一定要有資深的行業專家來參與，利用IT公司的計算支撐，協同實現一些突破。

同時航司的參與也無與倫比的重要，誰能比其自己更懂自己的產品和客戶呢？看過很多案例，自己也親身經歷過幾個不成功的案例。行業專家及我們確實想的很超前，但是投放到航司等領域，其就是缺乏說服力和生產力，甚至跟現實脫節太多。

c) 元數據

這是此主題的關鍵，精準在與航司內部對於數據的描述的精準和一致。為了後續敏捷的實現各類對接、系統融合及編排、內部更順滑的「流轉」。其關鍵是必須制定一套規範性的數據模型，數據契約。

往往只有生產環節、系統、大後台，才去考慮Metadata。但是航司的營銷領域，我認為是必須構建其必須貫徹執行的。從數據的命名、類型、精度、長度、Mandatory/Optional、等等構建完整的數據字典、數據規範模型、基礎數據契約、SimpleType、ComplexType。即一整套基於XSD的Schema契約規範。】

各個航司領導和產品技術團隊核心人員，其實都不敢拍著胸脯說：我們下面的團隊，有一整套符合英文標準命名規範，層層一致，里外一體的數字契約和數據字典。我見過太多讓人「蛋疼」的數據契約命名和使用。而且大量過時和不匹配的介面文檔。而且隨著大量低水平外包人員的引入，那些欄位命名和使用，會讓我這樣有潔癖的人自殺很多次。

正如AIDM（Airline Industry Data Model）及航司電商熟之不能再熟的NDC，其都是在規範數據契約。再或者Sabre及LH的Open API等，其都是在自身業務的基礎上，抽象出一整套數據契約規範。同時在建設新系統，尤其Open API的時期，將這套元數據貫徹到中後台的各個環節。

近期正在給一個大航司建設類似的功能，所以技術細節不便公開。但是此流程必須從XSD出發，從DTO、Domain Entity（POJO/POCO）等、乃至DAO、Data Model逐級認真貫徹。這個是航司企業的關鍵數字資產的基礎。更是讓後人能夠收益的關鍵。

微模塊

大家大量聽說「微服務」/Microservices，同時也聽過SOA。但是何為微模塊？

a) LEGO積木

我們的系統，尤其是電商的系統，不是必須全部要服務化，把SOA力度增強後轉變為Microservices，這樣要求極大的投入和對於設計的極高要求。但是也不能置之不理，讓一個系統一個系統的羅列在哪裡，最後變成end-to-end的系統對接網路。

所以最合適的方式，就是將自身的業務、系統、應用，按照水平和垂直的兩種不同思路，以FR和NFR的特徵，拆解為各個能夠獨立運轉「自運行」 & 「自維持」的微小模塊。可以是Microservices的表現，也可以是非服務的形態，乃至Jar/Dll方式。

航司電商，尤其是營銷口，可以充分利用這些模塊化的LEGO積木，組建全新的業務形態和流轉。重新建一所漂亮的房子自然美好，但是投入精力和未來的變化是不可預知的。業務LEGO的房子有些稜角，但是其結構是堅固的（由於你有一致的數據契約，精準的介面規範），業務也是完整的。更難能可貴的是隨時可以打散為可復用的模塊搭建你新的房子。

b) Microservices

微服務不是簡單的RESTful Service，也不就是JSON。其是代表一整套架構設計思路。更關鍵的是，且也必須有契約，有規範，有體系。

航司要推進直銷，採用NDC，關鍵是中後台要有一套強而有力的模塊化的服務介面。這個時候微服務就是最好的技術實現方案和體系設計思路。同時對於航司推進Open API也是最好的技術實現。從Edge Service到Internal Service，從API Gateway到Registration中心，從Configuration到Distribution，從熔斷到鏈路跟蹤，乃至邊緣計算等等，都是更高效和輕量化的服務技術實現。更關鍵的必須要將數據契約，服務企業，操作契約，也就是SOAP Web Service的ABC的概念投放到RESTful Service。這個不是倒退，而是人們的思索及改進。將yml等為基礎的Swagger等有機的融入體系建設中，更尤其是技術架構開發規範中，勢在必行。更是電商中後台的一個關鍵任務。

c) DDD

https://en.wikipedia.org/wiki/Domain-driven_design

https://baike.baidu.com/item/DDD/3539802

這裡不介紹這個概念了，但是其是對於Microservices設計及開發的一個關鍵概念。要想構建好航司的核心微模塊化能力，必須從業務上把控，用Domain-Driven Design的設計思維去構建服務。「Monolithic」化業務、數據和實現。

但是這正是航司人才儲備比較缺少的一個環節，沒有資深的行業背景的架構師，尤其是企業架構師，很難構建一個體系化的微服務體系和平台。單純的堆積技術，是徒勞的。

「花非花、霧非霧」

技術是為了服務於業務的，但是很多技術的出現是單純為了革新而產生的。那如何高效精準的使用技術，服務於日常工作，服務於產品建設，服務於數字化轉型。則必須Open Mind。

舉個例子：之前一個德國廠商有大量後台作業需要業務流程編排，而且是必須的，也是業務要求及技術無法規避的。那德國廠商的建議是一系列Workload Scheduling & Distribution產品，例如UC4等。這些產品軟體確實好，不考慮價格的化，能夠極大提升生產力。但是在有限的經費和人員素質的前提下，我的方案是使用Jenkins。當我說出Jenkins的時候，老外們的下巴已經掉在地上了，眼睛圓圓的獃滯了大幾秒鐘。但是回過神來的時候，他們的回復是：Brilliant！

所以每個技術、框架、產品等，都是工具，人不能淪為工具的奴隸，要主宰工具。所以要深究其解決怎樣的問題，抽象其解決問題的思路。而不是看他們的代碼，看他們怎麼實現的（這是大量應用開發工程師會幹的一個事情，我不認為不對，但是有多少人能從看他們的代碼，學到或掌握些什麼呢）。還不如多體會體會其思路，好好「用」好它們，畢竟他們是工具，是被用來「用」的，而不是「拆」的。擁抱技術，將會面對更多的新穎的工具，以及日新月異的革新和衝擊，對於「中年油膩」的人們，重點是思路和抽象。

對於航司電商等，其一定要Open Mind，用開發的心態去接觸新技術，去摸索和分析它，去用心抽象它，用更開放的思路去融合它，善用它。

總結

航司的數字化轉型大量取決於營銷等部門，更是「吃力不露臉」的電商中後台的必須投入。如何將人財物及時間有機的融合在一起，構建高價值及高效的核心動力引擎，及電商中後台引擎能力的提升，將是這個長期戰略規劃成功的一個重點。讓航司尤其電商中後台，擁抱新技術，接受新理念，必有開放的思維。真真正正的將如上IT因素解決好。