“忽如一夜春风来，千树万树梨花开”，中台的概念就如这句诗所描述得一样一瞬间在IT圈里火了起来，好像不讨论中台就任何解决方案就黯然失色了。中台(数据中台、业务中台、技术中台、AI中台……)的概念可谓漫天飞舞，我希望在下面的文章中结合真实的实践案例，就大家最关心的问题从概念到实践层面做一些解读。
- 中台是什么
在解读中台的概念之前我们先看一下“中台”这个词的来源。中台很早的时候由美军作战体系演化而来。通过中后台的强大炮火能力支持前线小团队的快速判断，引领整个进攻的完成。意味着让听得到炮火声的人能及时呼唤到炮火。
对于“中台到底是什么”这个问题，不同的人不同的理解。有的人认为是增加部分业务功能，或者基于场景的业务微服务集聚中心，也叫API Center，如用户中心、订单中心、产品中心等，也称之为“业务中台”。有的人认为中台就是各种技术组件的堆积，如Spring Boot，Devops, 微服务开发框架，Docker等，也称之为“技术中台”。
要搞清楚中台到底是什么，必须追本溯源，回归初心。得从各类“中台”概念中抽出来，以更高的视野和视角来看，中台到底能给企业带来什么价值?
经过30年的信息化建设，制造业积累了无数的企业管理信息系统，如ERP, MES, PLM, SRM, CRM等。所有这些信息系统都是以流程驱动为核心，解决企业各类管理效率问题。经过多年的开发和建设，这些系统变得臃肿不堪，总结起来就是又慢又贵。就如下图的大齿轮。
而随着科学技术的发展，企业面临的不确定性越来越高，产品复杂性逐步增加，生产过程复杂性逐步增强，客户定制化需求逐步增多，供应链协同复杂性逐步增高。企业的竞争本质上演变为优化资源配置效率的竞争，或者理解为以数据服务业务化来响应瞬息万变的市场变化。前台应运而生，就如同下图中的小齿轮，专注于小而美，快速创新迭代，快速响应用户需求。内部用户要访问多个系统才能获取诸如产品图纸、 供应商信息、 库存等数据，导致其无法快速变化和直接被使用，以支持前台快速的创新需求。管理层也难以依据营销、研发、制造、服务等各系统间大数据整合进行实时分析和决策洞察。
而这两个不同速度齿轮的驱动就去需要一个耦合的齿轮：中台。它可以快速聚合后台的数据与能力，通过平台的快速开发、分析、服务编排等能力，提供前台更多的创新能力、试错能力。
举个例子：比如采购给供应商下发一张图纸这个非常小场景。采购就得先学会PLM去搜索一张图纸，同时要学会ERP去看看图纸对应的原材料的库存情况，甚至要学会使用SRM系统看一下供应商给的采购价格。简单的一个场景，由于后台系统的复杂性，以及部门的局限性导致数据无法形成及时性和协同性给终端用户，也就是无法真正做到以用户为中心。
如果一定要给一个定义，我愿意总结为：“中台是一种思想，是一种体系”。这种思想主要是为了加速数据驱动价值的过程。
- 中台与SOA/ESB的区别?
那中台这个概念和我们以往企业在架构信息化系统过程中经常提到的SOA/ESB又有什么区别呢?
SOA更多的是一种软件架构设计的模型和方法论，它的主要特性是面向服务的分布式计算，服务的重用，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。
而ESB则更容易理解，它是中心化SOA的具体实现，主要是解决异构系统间整合的常见问题，比如服务连通、路由、消息丰富、服务的注册/查找/发布等服务的管理、服务监控和质量保证等。
再回顾一下中台，中台是因前台的敏捷性而生，是将后台系统中需要被前台调用业务能力、数据通过模型聚合的方式关联到中台，同时通过Service API的方式供前台快速调用，以响应前台的快速创新与变化，为前台提供更强大的炮火支援。
SOA/ESB与中台相比主要面向系统集成，项目实施平均成本高昂，牵涉大量的协同开发，无数据分析能力，面临性能和扩展性的风险。无论从成本还是效率的角度，都体现了传统项目建设方式带来的业务迭代能力不足。
所以中台不等于SOA更不等于ESB，虽然在理念上和SOA一脉相承，从技术角度来看，也可以作为SOA中开发集成模式的一种演化变形，但中台显然是从更高的战略角度进行考虑的。
- PTC的实践与案例
1) 使能平台能力简介：
PTC的ThingWorx平台作为制造业企业最合适的中台使能平台，含有数据连接、模型聚合、服务注册与编排、数据分析、前台应用构建等端到端使能技术。下面一一简单介绍。
- 数据连接
支持Connector方式将各个不同系统中的3D数据、图纸、库存、供应商等数据连接汇聚到ThingWorx平台，自带的Kepware组件可以将符合OPC协议的工厂设备、机器人、AGV等连接至平台，同时支持SDK等多种方式将产品实时运营数据连接至平台。
图形化模型聚合
基于连接的数据，我们认为中台最核心的思想是使用ThingModel的机制聚合模型项与模型项之间管理关系以构建一个完整的产品全量数据模型。如下图我们构建一个A型号洗衣机全量数据模型(属性、服务、时间、订阅)的完整逻辑展示。
而这个过程完全可以通过ThingWorx的图形化方式完成，不需要编写代码。
并且模型项之间的管理关系追溯性可以直接在平台上查询，下图完整展示了ECN、Part以及需求之间的追溯性和关联。
PTC全球资深副总裁兼大中华区总裁刘强先生表示：“基于ThingModel机制的图形化方式产品全量数据模型构建是PTC ThingWorx平台的核心，它使得我们可以使能用户快速聚合后台慢且贵的系统业务及数据，提高数据对前台用户的及时性、一致性、协同性，加速数据到价值的过程。”
服务编写、注册与编排
客户IT或SI可以使用Java及JavaScript编写复杂业务逻辑的聚合服务，利用ThingWorx快速开发与部署能力，对服务进行修改验证，并注册发布API Center，在API Center中的所有Service API，其它前台应用、系统甚至微信小程序均可以访问。
同时如下图所示，支持已注册服务傻瓜式、拖拽式编排。
数据分析
同时平台自带的分析组件，自带线性回归、逻辑回归、决策树等7种经典机器学习算法，可以帮助用户快速构建机器学习算法模型，用以预测设备故障概率，提升工艺水平，找到产品故障模式等，使终端用户可以真正地基于后台系统数据进行快速决策。
前台应用构建
ThingWorx平台的拖拽式开发体验可以使前台开发速度提升10倍以上，通过开箱即用的控件以及积累多年的控件市场(MarketPlace)，所见即所得的布局，数据绑定式服务调用等开发出聚合不同数据及业务的混搭页面(Mashup)。而这些页面既可以嵌入原来的前台页面，也可以适合单独的Web浏览器访问甚至移动终端访问。
同时，ThingWorx平台的AR开发组件，可以结合聚合的3D数据、实时数据等給用户不同的数据体验方式。
2) 场景及案例：
下面通过一些常见的制造业场景及案例来看看PTC ThingWorx如何作为中台来加速我们说的数据到价值的过程。
采购图纸下发供应商：
PTC Navigate就是基于ThingWorx开发的应用程序框架，完全基于用户角色的APP式体验。APP与臃肿前台界面或后台系统的最大区别是， APP是不需要培训的，是面向特定角色的解决特定场景“小程序”。
采购人员只需要选择其中的View Drawing APP，输入图纸编号，图纸即可展示在APP中，甚至图纸对应的零件在ERP中的库存及单位，在PLM中的状态及版本都可以呈现在一个APP中，大大提升跨系统数据业务化的及时性和一致性。
数字化质量追溯：
众所周知，质量在制造业企业是企业的生命线。但是质量的相关数据都被存储在各个相关的后台系统中。一般通过检查的方式来提升。而我们欧洲的某个客户就在所有相关后台系统(System of Record)基础上架构了一层ThingWorx，基于ThingWorx开发了一系列Connected Quality的Apps(System of Innovation)。
其最核心的思想也是通过ThingModel的机制建立需求、验证、FMEA、变更、工艺路线、客户反馈、NC及CAPA等所有质量数据的模型项以及模型项之间的关联关系。从而使能前台的质量规划、关键控制参数、可预测的工艺质量等基于场景的活动。
结论
PTC全球资深副总裁兼大中华区总裁刘强先生认为：“随着中台的兴起，的确为企业带来新的数据服务化及支撑业务创新的方案，企业根据自身业务发展构建中台从方向来说无疑是正确的，但要适合行业的最佳实践，根据自身当前的业务成熟度、技术成熟度、理论成熟度来引入具有技术领先性、案例领先性、架构领先性、以及性能领先性的相关商用产品。”
从实施模式上，我们建议遵循Think Big，Start Small，Scale Fast的原则。 基于一定场景快速开始，逐步沉淀，快速复制，最终形成自己的中台实力，以支撑企业的业务转型和提升企业竞争力。
