中台vs平台 区别与联系

Posted 2021-09-03 董月

  我们都知道中台和平台都是企业通用能力的抽取与沉淀这是毋庸置疑的，那两者之间的区别又是什么呐？为何在平台之上又提出中台概念呐？笔者最近在拜读欧创新大神大作《中台架构与实现---基于DDD和微服务》偶有感悟暂且大胆一说如有谬误及误人子弟之处望各位读者不吝赐教，轻拍轻拍。
  首先中台与传统平台的的区别就是中台提供的的是企业级的解决方案更加贴近业务一线而平台一般来说提供的都是非企业级解决方案其定位更多是通用功能并且有远离业务的倾向以期提供更大的通用性，其造成两者区别的本质原因在于两者的定位和owner不同。具体来说平台只提供了企业级的功能或者解决方案的一部分需要前台部门在此基础上做额外大量开发才能提供用户面向用户的完整功能。这会造成两个问题一个是前台部门还需要花费额外的人力开发，如果功能相似则势必造成重复开发的人力浪费再一个就是由于各前台都在平台基础上做二次开发势必造成用户体验在相似功能上的不一致。
  举例笔者公司微信平台为例说明：
  背景就是微信平台提供的前台调用方可通过openId换取user id功能。但是微信绑定时候是可以绑定多个用户id的，平台在返回时候会把这个openid对应的所有绑定的user id都返回给调用方甚至包括解绑的user id，并加上绑定状态作为区分。
  从平台的角度来说这个设计没有问题基本提供了所有调用方可能用到的所有数据提供了最大的通用性因为他无法确定各个调用方是如何使用这个openId的但是这里就会有前面提到的两个问题比如线下购物团队需要通过微信open id来确认用户身份发现绑定了多个可能会觉得该账号存在问题则直接拒绝认证。而另外团队可能觉得绑定都需要经过非常严密的步骤，安全行都是可以保证的不如每次都取最新的好了。这样两个团队都需要额外开发自己的认证功能并且给用户体验是不一致的，用户在一个功能上可以绑定成功换个功能点竟然怎么绑定都不行肯定会非常的confused。
  如果是最为一个微信认证中台来说设计可能是这样的：他提供一个通用的用户微信平台认证功能，如果open id绑定了多个则比如直接返回最新的user id这样一个企业级的解决方案（为甚说是企业级的因为这个功能对用户来说就是一个完整的功能）。这样不同团队在使用时候就直接拿到了user id不需要额外开发并且对用户来说体验也会非常的一致。
  大家看出两者实现上的背后的原因了么？那就是两者背后的定位和owner不同，作为微信平台来说他只是微信相关功能的一个汇聚他并不了解具体的使用场景是什么样的因为他的owner够不到前台，而后者作为中台他的定位和owner就是用户认证说白了他的owner够的到前台他说了能算。
  所以说如果企业要做中台转型肯定不仅仅是IT部门一帮程序员闷头梳理模型闭门造成就能做成的这个涉及到公司整体组织架构调整以及思路上的一个转变。一个是业务部门要认同这个事情业务部门本身就要界定好那些功能是中台care的那些功能是前台care的，另外一个是中台的演进上中台要作为一个企业级方案提供团队去演进和迭代当然是也可以接受前台部门提供的需求。

中台结构与实现 基于DDD和微服务