江苏龙网

  1. 主页 > 生活百科 > >

上“中台”，是送分，还是送命？( 六 )

中台


需要注意，图中的每个域不代表只有一个服务，服务数量可以是多个 。
从底而上是要求我们优先实现那些被广泛依赖和公用的通用领域能力，然后再去实现被依赖较少的那些通用领域能力，最后基于这些能力可能还会继续抽象出一些更具有具体业务含义的领域能力 。
比如资源库存中心搭建好之后，还可以基于它去搭建商品库存中心 。这样不仅可以实现效能最优化，也可以避免由于上层抽象不合理带来的重构成本 。
想象一下，如果我们先竖烟囱，再去抽象他们的公共部分，是不是会带来巨大的重构成本和重构风险 。
万能工厂要不得
“一个强大的集中的流程定制配置后台”是不是企业中台必须要有的部分?
个人理解不是必须的，因为互联网业务复杂度规模很大，涉及各种细节，花大代价去整合一个这样的流程配置中台对中小型公司来说是不可取的 。
前两年阿里内部很火的 NBF、TMF 框架[6]，可以快速的通过配置和少量研发帮助阿里集团内的其他 BU 搭建业务项目，说的神乎其神 。
除了一两个用来打广告的案例之外，真实用的 BU 并不多，文献[7]对应的知乎回答中也有表达类似看法的 。
为什么?笔者的答案是“极端陷阱”，只要路子够极端，必定会遇到新的问题，在这一点上，苍天饶过谁?
本以为只要把“开闭原则”用到极致，提供通用配置之外，允许需求方编写很多插件接口实现定制化业务，就可以解决任何问题，其实不然 。
由于要保证灵活和个性化，配置会呈爆炸式增长，多到理解它学习它使用它的成本也到了一个不小的量级，这时候大部分研发会想：还不如我写代码了 。
而且一旦遇到某些功能不满足业务需要，业务也不想迁就，那么还得依赖这样一个框架去发起新的迭代，这是业务方不想看到的 。
代码是一种逻辑语言，本质上和配置一样，只是为了保证代码的正确性，需要经过合理的研发环节，比如研发、自测、测试、灰度、上线验证等，这才是让我们抵触研发的根本原因 。
而一旦配置复杂了，笔者认为一样一套配置实例仍然需要经过一定的验证流程才能上线，而为这样的一套大型配置系统去编写在线测试机制，又是一大坨工作量 。
所以笔者建议，中台的建设应当围绕单一职责的领域能力去构建，单一能力又可以提供一些简单配置来实现定制化使用(就像一款款的中间件那样)，比如我们只需要申请好支付账号和密钥，就可以在系统里集成支付宝了 。
在这些可以复用的系统能力至上，我们再去定制化构建自己的前台业务系统 。如果前台产品明确的话，我们甚至可以搭建自己的产品工厂，专门生产某一商业模式下的产品 。
这些产品也代表了小前台中的更小前台，也可以反应框定范围内业务模式的不同，业务们也是可以基于这个工厂去玩不同的花样的，只是这样的工厂不能用来生产其他商业模式的产品 。
反过来说，本来就没啥关系，为啥要管别的商业模式呢?管的越多，工厂本身越复杂，越耽误事，折射到现实中，一般一个工厂只会生产某一种类的产品，但是产品系列可以有多个 。
折射到超级细胞，它的那套游戏工厂，生产游戏自然没问题，非得让它生产贷款产品，这得多无聊 。
所以号称自己可以快速搭建某行业任何业务系统的“万能工厂”，多半是陷入了“极端陷阱”，最后只能是庸人自扰，舍本逐末 。
记得《最强大脑第七季》的某一场比赛，娄云皓对宋佳昌，单位时间内根据解开的“异形谜盘”数量来得分，娄云皓选择了低阶的盘面，而宋佳昌选择的是高阶的盘面，最后娄云皓大获全胜 。
这个例子告诉我们，过于追求更大复杂度的成功，很可能陷入自己跟自己过不去的尴尬境地 。
笔者不否认理论上是存在一套全能的系统，仅通过配置就可以完成各类电商的业务系统定制，但也别忘了，当配置足够复杂时，也许写写代码更容易解决问题，毕竟底层通用能力有的话，已经可以极大的提高研发效率了 。
中台建设本质是复用能力的建设，能力系统的建设应当聚焦某一领域，切实的去解决众多前台业务的某一类复杂性子问题，并封装出简洁的接口提供给前台业务开发使用 。
万能工厂的做法不可取，这种方法的本质是简单问题复杂化，分布式前台业务的集中式抽象，若是前台业务逻辑本身就相似，那么不用系统工厂也能做的很通用;若是差异很大的前台业务，用了系统工厂可能更难如期交付 。


推荐阅读


上一篇：杜冷丁属于什么类型的毒？

下一篇：乐轩道茶业加盟信息,正皓茶业全国招商火热进行中