中台|啥都复用不了，还谈什么狗屁中台( 四 )

1）对于小团队而言，统一架构体系，单体应用一样很美
我们一贯的常识就是，越是独立的，没有太多耦合关系的组件越容易复用，过去烟囱似的单体系统难以复用就是模块和系统本身耦合太深而造成复用改造的成本很大。这个理论是对的，但我认为不全面，完全去除耦合是不现实的，只是耦合的深浅和范围是需要管理的，如果复用组件的使用者一样耦合在同样一个环境中，其实也是可以复用的。这就像A系统要复用B系统的模块其实是很困难的，因为耦合的环境不一样，依赖的基础不同；但是A系统内要复用自身系统的某模块却非常容易，因为依赖环境是一样的。所以，小团队如果在代码层级能够统一成一个应用，然后通过插件化、代码级的组件化对业务模块进行抽象和管理，单体系统依然是很美的。
我在七八年前带一个小型互联网团队，自己花了两三个月时间写了一套基于JFinal（当时刚开始推出的小众框架，现在已经非常流行了）插件化的脚手架系统作为我们团队所有业务开发的载体，这么多年过去了，这个系统依然在健壮的运行，业务也在不断持续的开发着。我们实施的泛微最新一代的OA系统，如此庞大的系统，通过部署结构来看，其实也是一个大单体应用。所以，不是单体系统不好，只是当它太大以后，我们没有能力管理好它而已。
2）有一定规模的技术组织，构建统一平台底座
复用的成本以及难度往往都是组织规模扩大，尤其分化后才迅速提升的。在一个多组织中实现组件的复用需要建立统一的标准，也不要完全去除依赖，而是尽可能依赖单一，大家都依赖这个单一的东西，这个依赖对复用的影响就会降低，所以一定规模的技术组织，要通过构建统一的平台底座，将共享组件沉淀在平台底座上，让不同的业务共同依赖同一套底层的环境，通过平台底座的共享能力，实现各垂直业务的横向交流和协同。
这种模式特别适合软件产品研发的企业，构建在厚实的平台之上的产品研发，既高效又善于组合和扩展，产品的边界不会因为系统的隔离而变的僵化。
而且构建平台底座既适合单体架构的应用也适合分布式的微服务架构，平台底座其实一个组织有规划的复用的体系建设。下图是笔者团队建设的平台体系，后台引擎由架构团队主要负责建设，业务组件（属于中台范畴）由各研发团队根据业务领域分别负责构建，供做参考。

3）企业级的复用体系–中台架构
中台的广义上的定义：企业级能力复用平台。
虽然我们的一体化平台涉及到中台服务部分，但是作为研发企业，我们的中台架构和服务是面向客户去交付的，帮助甲方客户构建中台能力。一般情况我们所说的中台，不是厂商的中台解决方案，而是一个互联网企业或者一个传统企业为了满足自身数字化转型的需要而构建的中台体系，它是面向企业运营的中台体系而不是面向项目交付的中台服务。
广义上的中台范围是非常大的，涵盖了企业运营的方方面面，而我们更关注的是企业中台的载体即数字化运营中台。企业首先通过信息化建设，将企业内在业务从线下搬到了线上，这个阶段我们构建了一个个的单体系统，这些系统集成都不容易，复用几乎就更没可能。最终导致大量的重复开发建设，同时还带了更大的系统治理的成本。
进入数字化时代，甚至是智能化时代，面对激烈的市场竞争，企业降本增效的需求愈发迫切，更好的复用，更敏捷的建设是企业迫切的愿望，中台体系的提出，是顺应这个时代的产物，所以企业关注中台，尝试中台是对的，至于为什么会失败，后面的文章再去探讨。