下载掌阅APP，畅读海量书库
立即打开
今天是“万物互联”的时代，“用户是上帝”不只是企业的宣传口号，这句话已经是企业生存的关键。快速响应用户、最大化满足用户的个性化需求，是企业在互联网环境中得以生存和持续发展的根本。
我记得小米刚起步时出了一款手机小米2S，这款为“发烧友”而生的手机价格低、配置高、质量好，满足了当时更换智能手机的用户的迫切需求，导致大量用户的“疯抢”。这款手机的核心竞争力之一是操作系统MIUI，用户可以随时通过这个操作系统提出问题和建议，小米能够迅速发布操作系统的版本更新以响应用户的需求。而当年质量做到很好的诺基亚却没落了，很重要的原因就是它对用户的响应能力太弱。
只有尊重用户并满足用户的需求，甚至主动改革自己的企业才能在以用户为中心的互联网时代得以生存和发展。那些坐等用户上门、故步自封的企业，则会被时代抛弃。企业对用户的响应力的比拼是核心中的核心；互联网时代为了快速响应用户的需求，最直接、最快速的方式就是依靠信息和数据。能否建好一个强大的信息数据平台，选择的架构和技术体系是否高效敏捷、有没有持续性与扩展性是最为关键的。作为集团公司的IT架构师，我经常会评审成员企业报上来的信息系统建设方案，当我看到技术组件还是10年前的Struts+JSP时，我就想这个系统上线后该去哪里找运维的人。目前传统企业的IT架构是什么情况，能不能支撑、满足或响应用户的需求呢？
很多传统企业没有自己的研发团队，很多企业的IT系统基本都依靠第三方供应商提供的服务，而且大多是以传统项目制和采购产品的方式经过多年实施逐步形成的。图1-2所示为某机场集团公司IT总体架构示意，简单划分为4个核心域。
图1-2
●生产运行保障域：完成航班在本机场的正常起落保障。
●办公管理域：完成全集团日常办公管理。
●旅客服务域：完成旅客在机场出行全流程服务。
●数据中心从以上3个业务领域获取数据，形成集团最核心的数据资产。
这是非常典型的传统集团企业IT架构，其逻辑关系清晰，层次分明，职责明确。各域内部及域之间的系统采用传统中心化的企业服务总线（Enterprise Service Bus，ESB）中间件进行交互，办公管理域和生产运行保障域的数据通过接口方式沉淀到数据中心，进行主题划分和决策分析。
此架构中的各系统实施过程基本是甲方提出需求，乙方设计实施，甲方验收。这种模式是由业务和职能单位提出自己的问题，然后确定方案，这些单位很难主动去考虑与其他业务实体间的协同交互，这种组织架构形成了“部门墙”，数据和业务也是“烟囱式”的，相互协作困难。
对每位旅客的真情服务，需要机场将所有服务触点串联起来。但目前每年有几千万出行旅客，在系统层面旅客基本都是离线的，出行数据也是离线的，无法利用这些数据。数据不在线就产生不了价值，对于提升旅客服务质量的意义也不大。我们以机场旅客服务域为例，项目系统架构大体如图1-3所示。
图1-3
●企业多年积累了大量的信息系统，每个系统都是独立的一套垂直体系，有自己的网络、数据库、服务器，基础资源投入大，后期统一管理和运维困难，成本高。
●各系统解决方案完全依赖乙方，采购产品或二次开发都依据乙方的标准架构，甲方基本无体系、无标准，IT整体架构混乱，无章可循。
●每个系统都有自己的用户管理、服务产品的提供、订单的流转和聚合支付等功能，系统间通用能力难以共享，存在大量的重复建设和重复运维。集团企业中的很多系统在多个子公司重复建设，例如机场集团公司下属的每个机场公司都按固定资产投资方式各自建设实施了贵宾系统，虽然业务流程基本相同，但也无法复用。
●甲方只参与招标、提出需求和项目管理，IT部门验收后也只负责基础资源的运维，很难有精力和动力去思考业务的创新。
●不同的系统不能共享数据和服务，形成资源信息孤岛，导致业务间协调困难，甚至部门内的系统集成都有各种技术障碍。
●不断的新需求迭代开发，导致系统重构后形成新的烟囱，运行效率低下。
●采用项目制建设方式，审批时间长、业务上线慢，业务在公司和部门内封闭多、变更难、创新少。
假设有以下场景，旅客在集团层面能有一个统一的账号（业界“时髦”叫法为OneID），使它在各业务系统都能在线化。今后汽车、行李、手表等设备都可以在线化，通过OneID对旅客需求在所有出行业务环节自动感知主动响应，这样完全可以将集团的主业和辅业串联起来产生价值。如旅客刚下飞机，机场通过OneID就能实时获取到旅客的行程，旅客刚出航站楼，机场运输公司的专车已经在门口等待，地服公司人员已经将行李从飞机上转运到专车上，机场的酒店也已经提前为旅客预留了房间，机场的旅游公司制定了一份个性化鲜明的游玩攻略推送给旅客，这些个性化的精准服务全靠OneID在各系统进行动态感知。但是按照上面的垂直烟囱式系统架构，各公司是无法使用旅客动态数据资源的。
如果大家能在一个平台上运行，用户数据、产品数据、订单数据、支付数据被统一处理，这样数据就可以在平台上流动起来，实现多业务实体间的协同服务，简化旅客出行的流程。用户每多一个操作步骤，公司就可能多损失一半的用户。但有一个很大的风险是组织结构的适应调整，很多中台项目失败的原因是资源得不到满足。阿里中台战略的成功是因为组织中台的不断调整和完善提供了保障。本书会介级如何从技术、业务和数据层面设计和实现业务中台，也会从中台项目的团队组织结构进行经验的分享。业务中台是需要逐步完善的，甲方不要期望找一家承接中台建设业务的厂商就能把中台建好。如果甲方不主导核心业务流程、不把握架构、没有自有或外包团队进行持续的迭代完善能力，那么实施中台战略的风险极大。