中台的概念从阿里17年开始提出来就快速成为了年度IT热词。阿里这样体量的企业的成功无疑论证了中台建设的正确性，让大家对于中台这样的解决方案跃跃欲试。而阿里顺理成章成为了中台的最好代言人，大家学习中台的榜样。那么什么是中台？事实上，对于中台的定义大家也一直在探讨中。阿里内部业务系统有其独有的特点，诞生其中的中台自然也带着阿里独有的特征，这一点从《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书中我们也能读出来。直接复制阿里的中台方案真的能解决广大企业中的共性问题吗？可能未必，这应该也是当前大家关于数据中台有着各种各样的解读的原因。
什么是中台
关于阿里的中台我们可以找到非常多的内容，下面我尝试将当前基本上成为大家共识的理解概括一下。
中台包括两部分，即数据中台和业务中台。数据中台以数据平台技术为基础，解决数据孤岛、数据标准化、数据存储、数据泛滥等数据管理问题。业务中台提供多种多样的数据分析、数据挖掘、机器学习服务，为快速业务响应、快速业务创新提供支持。从建设方式上看，数据中台的建设应该站在公司战略高度，从顶层着手，自上而下的驱动完成，这样便于统筹规划，避免来自各个业务部门的阻力。同时建设数据中台应该改革组织结构，独立一个中台部门来专门从事中台建设工作。
从这些理解来看，中台建设是个大工程，其针对的企业也是成熟的大型企业。这样一个大工程，投入量也相应是巨大的，资金投入，人员投入，时间成本都非常高昂。如果中台能解决上面提到的数据管理和数据服务问题，那它确实能带来可观的价值。但对于这样一个看似庞大的方案，我们要如何去落地呢？以我们当前的精益敏捷认知来看，是不是顶层设计、组织结构变革这些都过于重量级了呢？事实上这个问题也就是当前中台方案落地的主要问题。
再次思考中台业务价值
虽然从上面对于中台的阐述中，我们能感受到中台带来的潜在的巨大价值，但是回到企业的具体场景中，似乎这些又都是漂浮在空中，优先级不高的事物。在企业在广泛发展自己的主营业务时，其实我们已经有大量的业务人员在思考和尝试创新，他们已经或正在基于自己的分析提出很多新的观点。比如现在我们的应用都会集成数据统计分析平台，在进行迭代优化决策的时候，我们往往使用已有的数据工具就能得出结论。中台真的能比我们现在做的好得多吗？或者说我们一次性花很大力气去建设一个大而全的中台，投入产出比真的高吗？
中台究竟如何产生价值呢？事实上这里价值产生的基础是数据共享。企业中，我们一般按照业务线将公司组织成不同的部门，不同的部门相互之间是相对隔离而自治的团体。如果没有共享的数据支撑，各业务部门将各自按照自己的方式发展，能利用的资源也限制在部门内部，这样就容易错过一些潜在的机会。比如，如果没有淘宝的数据，想必天猫的发展速度会大大减慢。也就是说，当我们有了多条成熟的业务线时，中台可以以资源整合的优势辅助各个业务线相互促进，联合创新。
如何共享数据
既然共享数据是中台的核心，那么我们会以什么样的途径去共享数据呢？
分析使用共享数据的过程可以发现，一种情况是我们可以分析其他相关业务线共享的数据，从而产生新的理解来支持本业务线的发展。这里我们一般以原始数据的形式共享，以各种报表的形式产生价值。第二种情况是，我们以原始数据或者加工过的数据分析结果作为数据源，使用API的方式供业务消费。
通常情况下，企业会单独设立一个大数据部门，这个部门会汇总来自多个业务线的数据，同时这个部门会重点培养大数据处理相关技能，以承载来自各个业务线的数据分析需求。这就支持了上述第一种情况。如果企业里面已经是这样的组织架构，看起来是已经走在中台建设的路上了。但是情况也不总是这样，一般而言，当多条业务线都足够庞大时，为提高业务响应力，我们通常也会将这个大数据部门按照业务去拆分，从而形成多个大数据部门的现实。这同时又导致了数据共享的问题。
为什么总是会存在这样的情况呢？因为业务是最具有内聚性的，共享的数据其实都是一定程度的耦合，而我们为了提高效率总是会尝试提高内聚降低耦合。在中台实施的过程中，我们要如何降低耦合呢？用上述第二种方式是我们常用的手段。不同的部门以公开API的形式来共享自己的能力，如果我们要访问其他业务线的能力，使用该部门公布出来的稳定API即可。即便是数据分析的需求，其实我们也可以用这样的方式实现。这里可以分两步完成，一是各个业务线要公布足够多的数据以便数据分析时可以有一个全局的视角，二是在分析时需要访问API获取数据形成一个支持分析的数据集，再进行分析。
以敏捷精益的方式实现中台价值
基于上面的分析，我们来尝试以更轻量级的方式思考如何实现中台价值。
其实通过API的形式公开业务能力，我们已经在实践了，而且可能已经做得不错了。举一个典型的例子，比如我们企业中很多业务需要支付能力，我们一般会建设一个专门做支付业务的部门，那么对于一个新的需要支付能力的业务，他只需要对接已有的支付业务部门的API就好了。这里我们避免了各个业务部门去做能力的重复建设，节省了资源，各个部门工作也相对顺畅。这是一种通过API的形式公开业务能力的典型形式。但是中台价值实现要求我们做得更多，因为中台除了希望我们共享业务能力，还希望我们共享数据。比如，作为业务部门，我们不仅希望分析支付过程的流畅程度，我们还可能希望和其他业务的支付过程进行比较和借鉴。对于这样的需求，通常当前的业务能力共享还有所不足。
综合这里的分析，我们可以发现一种更敏捷和精益的中台建设思路。我们无需购买大数据中台产品，也无需对现有的组织结构进行调整，我们要做的是一步一步推进各个业务线去共享数据，同时一步一步推进各个业务线去挖掘其他业务线可能带来的潜在价值。从这里起步，如果我们能找到共享数据里面的巨大价值点，那么我们可以建立独立的部门把这个价值点当做新的业务来开拓。这里的思路是否可以用于中型或者小型企业呢？答案看起来是显然的，这是一种从小到大，是一种更自然的方式。
产品化
更进一步，我们可能需要这样的一个产品，它可以方便的以API的形式将某条业务线的数据能力公布出来，可以方便的设置权限以防止数据泄露，可以方便的找到其他业务线的数据API，可以做一定的API使用统计和监控。有了这样一个产品，我们将能快速的促进数据共享，推进价值发现和业务创新，中台的核心价值将得到实现。
以上就是我们的一些想法，看起来可以以更敏捷更精益的方式落地中台。想打造这样的一个产品看起来也不难，不知道你们的企业里面是否会愿意做这样的尝试呢？
参考
https://zhuanlan.zhihu.com/p/53843604
https://yq.aliyun.com/articles/630211
https://www.infoq.cn/article/4PXxXJ*ZOmPVlAtB2Ttb
https://book.douban.com/subject/27039508/