前言
航司的未来，不是一个Monolithic Enterprise，应该是一个Ecosystem，一个内部解决信息孤岛、外部"Connected"的Ecosystem。同时更不仅仅简单是系统的集成、数据的集成、ODS、SOA、BPM等，关键的是全面的“新集成能力”、敏锐的“数字资产产品化能力”、和常态的“持续集成能力”。或者用另外一个概念“Everything as a Service”/EaaS。
“内在能力” - 国内航司企业近10年，其一直解决的是企业信息化和信息孤岛的问题，方向绝对没错。就好比要成为武林高手，必须打通任督二脉。通过SOA，ESB，BPM，ODS等等大家熟识的概念和产品形态，集团军方式的、大刀阔斧的去修炼内功，以期“内在能力”的提升和质变。
“外在能力” - 要是从武林高手变为门派掌门，乃至武林门主，则关键在于你在与外界产生交互，并存在于一个生态系统中，并起到主导作用。有很多弟子或朋友或知己或利益伙伴为你服务。他们就是你的“外在能力”体现，但是你如何让他们跟你产生“Interaction”、产生“Transaction”，这都在于你能够提供哪些Service、哪些Data、哪些API、哪些Capability给这些外部资源，以期扩大你的影响力，以期提高生态环境的活力。
所以航司的角度，不仅仅是需要将生产的核心FltOps与营销打通，更需要在此基础上，将内部各个环节有机的融合或聚合在一起，然后再到机场，再到其外部资源。从而构建服务一体化的“Connected Airline Capability”。航司电商能够收益，旅客用户体验乃至飞行运控等生产环节也会收益。
“Connected”的生命力
举两个简单的例子，让我们一起体会一下“Connected”的市场价值：航旅纵横，ODS。
a) 航旅纵横
航旅纵横将原来离散的碎片的航班进出港数据、航班动态、飞机/机型信息、机场信息等等聚合在一起，提供航空出行的信息发布平台及服务。
不谈其商业模式，盈利模式，以及数据和政府等等因素。只谈“Connected”的生命力。正是这些原来离散在不同地点的数据，被以为了实现某种旅客使用场景的目标，而逐一聚合，所以产生了其存在的价值和用户的交互及体验，创造了全新的“数字化触点”，乃至构建了新的生态系统。
数据的整合，不一定需要EDW和海量数据等等大数据概念，关键是将离散的数据，拼接在一个真正解决最终端用户使用场景的数据展现，也许就是简单的航班进出港两个数据的聚合，也能提高机场旅客对于航班的动态信息的透明度；再加上航司的航班动态，那会是对于机场旅客的数据使用诉求的进一步满足；在机上飞机/机型/乃至机场的数据，那机场旅客更能一目了然的清楚出行的实时状况；再逐步将历史数据叠加和洞察，提供客户各类统计和预测等等，旅客就已经再被逐步“Satisfied”。最终其会有一个满意的用户体验。
看似简单的几个离散的数据源的单纯展示聚合，就已经有塑造了拥有“千万级”用户量的数据信息平台。其足以证明，航司、航企、航空相关团队，一定要不仅仅是抓牢数据，更关键的连结，在连结，让数据活起来，让数据流动起来，让聚合的数据服务于场景。这是创新，这是希望，但是更需要强有力的技术支撑和适应互联网时代的新技术储备及全新的新集成能力的基础。
b) ODS
Operational Data Store/Service其实是一个老生常谈的概念了，但是就近10年的航司及业界情况，其远远比BPM等服务编排或业务流程再造有更强的生命力和切实的落地诉求。
从FOC & SOC，到TAMCC & AOC，OCC，再到HCC等等，其都是关注在亮点：数据的全局视图和任务的协同。而不是系统改造或升级。
协同的目的是让离散的资源有机的、步调一致的为了一个目标进行“流式”的工作。但是其依赖的本质是全局的状态和全局的数据视图：Single View of Operational Data。即ODS的本质及核心能力。只有全局的掌握数据的动态和资源的状况，才能从全局的角度去调度和协同各离散的资源和实体去工作；才能更准确及合理的制定动态的应对方案。
然而ODS的实现，不是简单的离散数据源的copy/paste，其是需要在各种技术融合的前提下，打造流动的数据处理能力，从接入、持久化、分发、服务、日志五个关键环节，构建全局应用的数据基础和协同应用的数据流通渠道。没有这样的流动的Hub，上述各类Center是无从建设的。
Everything as a Service
Connected的目的不是连通，其在于为了找到和掌控更多的数字触点，提升旅客体验和服务品质。数字触点就是航司未来的“产品”，是其关键“实体资产”。
就好比如下的一个简单旅客出行的生命周期，每个环节都需要不同的应用、系统、部门、单位、企业、实体提供或消费相关的数据。这就需要打通，这就需要Connected。排除商务等人为因素，让我们先单纯一点，连结的越多，打通的越多，则获得的触点更多，触点更有生命力，旅客的体验会更好，粘度会更得到保障。
而这样做就势必需要更多的封装和暴露，提供更多的像乐高积木一样的独立模块，从而提供组装和插拔的灵活度。一个标准的做法就是Open APIs：在不触及航司既有业务和系统流程和完整性的前提下，以最小事务单元和最小事务数据的完整性为依据，构建各类面向特定领域的API，从而提供乐高积木似得原材料，以备后续的组装和编排。这些乐高模块可以是数据的封装服务、可以是包含事务完整性前提下的业务实现封装、可以是数据的变更的发布者、也可以是事件订阅的消费者、更可以是特定航司服务或产品的封装、或是航司内容的封装。不管其构成、实现、封装数据、服务对象等等，其都是航司乃至航司之外各类数据、资源，即数字资产的封装和服务化实现。真正的Everything as a Service，任何东西都是可以被用来消费的服务。只有这样，才能保障航司的连接是解耦的、是可编排的、是可复用的。
Everything as a Service是构建航司Connected Airline Capability的关键，更是航司的魄力和综合能力的体现！
新集成能力
面对航司在互联网时代的各类冲击，尤其需要充分利用技术爆发所带来的优势，势必需要将传统的系统集成、数据对接、流程再造等等概念和思路重新梳理，哪些需要破，哪些需要立，哪些需要封装，哪些需要暴露等等一系列问题都需要清晰和抽象的归纳和经验沉淀。
a) 集成的本质
终究“Connected”还是落地到“集成”这个概念上，但是对于集成，需要首先明确集成的本质诉求，是数据方面还是业务方面。因为其依赖的和投入的均不一样。对于Open APIs这样的基于Service理念的架构思路，其本质还是数据的集成，或者说数据的协同。
b) 常规集成方式
归纳整理起来眼花缭乱的集成工具和手段，无外乎如下三类：基于数据的集成，面向服务的集成，消息驱动的集成。
基于数据的集成 (Data-Based Integration)
传统的集成方式更多是赖于DBA的关系型数据库的定时任务的批量抽取、转换、加载，和基于聚合后的关系型数据库使用的诉求。然而随着数据源的多样化、数据格式的多样化、数据使用的实时性诉求等等一系列意思，都必须要求从传统的模式中和工具中走出来解放出来，用全新的技术栈和理念去处理“流动”的数据，和提供更宽泛的数据使用诉求。
面向服务的集成 (Service-Oriented Integration)
再好的SOA都需要服务治理，即Service Governance或Service Management。否则只能像如下图所示，从一种“蜘蛛网”变为基于另外一种实现方式的“蜘蛛网”。躲在Open APIs之后的Microservices美其名曰是取代或升级之前SOA架构体系的，但是如果航司在过往建设SOA的道路上还没有显著成效和沉淀坚实的经验及团队，Microservices的架构体系只能让原来乱的更乱，原来缺乏生机和活力的更疲态。如果Microservices是势在必行的立刻工作，则航司缺的是对于航司业务有全面掌握且技术出色的Enterprise Architect。
消息驱动的集成 (Message-Driven Integration)
真正的解耦和内聚的Best Practice就是消息驱动的集成和串联。但是正因为好，所以才难实现，才难梳理，才难维护。这里需要的Enterprise Architect更偏技术和消息契约的定义及规划。所以消息队列不是目的也不是所有，他就好比是一门开发语言和工具，用的好与坏还是在于人，在于规范和业务。
c) 新数据集成的蓝图
首先航司或航企必须根据自身能力量身定制，而不是一味追求“大而全，精而强”。但是其必须拥有如下两个Pipeline的实现和其上的6个关键环节。
同时一定需要Metadata的环节，即可以采用IATA的Airline Industry Data Model，实现和规整数据契约。然后在此基础上强化审计及跟踪，和可视化能力。更关键的是将数据的处理阶段化，即Staging，提高可控性和解耦能力。
待续：
数字资产产品化能力
a) 智能动态场景投放
b) Open APIs
持续集成能力
a) 云计算
b) 专人专责
网友评论