前言

        如前篇所述，航司的数字化转型是一个综合的体系工程，不能简单的通过增加销售量来拉动，也不能简单的通过提升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因素解决好。