论系统通用化的边界

1、背景介绍

是个研发人员都知道通用化，通用化是提升复用能力的重要手段。

通用化有没有止境，通用化的边界在哪里，本文就该话题进行讨论。

2、通用化的发展过程

如上图所示，系统通用化，按照由简到繁的过程，可以分成3个阶段：

• 阶段1：所有功能都放在业务系统中，一般出现在新系统。
• 阶段2：与业务无关的组件进行拆分，形成基础功能库。一般出现在有多个系统共存，且都有公共的功能要求。大多数软件公司处在这个阶段，既能保证公共组件的复用、稳定，又能保证业务系统的快速发展，且对研发人员的能力要求不高。
• 阶段3：把几个系统中公共的业务功能拆分出来，形成业务通用功能库。在此基础上进行业务功能的开发。这个阶段，建立在业务抽象层次较高，技术人员抽象能力较强，团队协作较顺滑的前提上。处于这个阶段的公司，都是实力比较雄厚，业务规模比较大的公司。

3、通用化的优缺点分析

阶段	优点	缺点
阶段2	1、实现难度低 2、能保证基础功能稳定，与业务隔离 3、业务定制灵活，响应效率高 4、团队内部闭环：业务开发，基本上自己团队就能搞定，降低沟通成本	系统间无法复用
阶段3	1、业务中台层稳定 2、业务定制效率、质量高	1、需要保证业务稳定，业务中台稳定。 2、团队内部无法闭环，每次需求需要多个团队参与，增加沟通协调成本 3、业务中台团队会成为瓶颈，业务需求串行排队 4、不支持系统个性化诉求

4、通用化的实现方式

4.1 阶段2的实现方式

分层。

把通用功能进行拆分，单独抽取出来形成基础功能层。

在基础功能层上构建业务实现。

业务实现根据领域、功能进行模块划分。

整个过程，基本上研发人员就能搞定，不需要业务介入。

4.2 阶段3的实现方式

阶段3涉及到多个系统通用功能的抽象，与业务紧密关联。

图1 的情况下，需求的差异在缩小，需求相似度在增加，这样的情况下，实现业务中台就水到渠成。

图2 的情况下，业务需求差异越来越大，通用性变的越来越低，实现业务中台的可能性及收益就非常小。

所以，实现业务中台的第一个条件是：多个系统的业务需求向着一致性发展。

不能仅仅看到两个系统都有产品、授信、融资，就认为两个系统是类似的。而是要了解每个需求的细节、业务流程再下结论。

假设第一个条件满足了，接下来就是研发如何对系统进行抽象，使业务中台能支持各个系统的个性化需求了。这个抽象过程，对研发人员的要求很高，与做一个系统不一样，业务中台需要足够通用、足够抽象，能满足多个系统的要求，所以如果一个系统都搞不定的研发人员，不用期待着能做出业务中台来。

所以做中台的人，既要求对每个业务系统的需求深刻理解，又需要有高超的抽象能力，如果没有这样的人才，那还是等一等吧。

第三个点，业务中台是需要随着业务发展不断优化的，优化过程中需要考虑对当前各个系统的兼容情况，难度也是比较大的。

4.3 基础架构的职责

实现通用化，一个不可回避的团队就是：基础架构团队。

基础架构团队，作为基础架构、通用化能力构建的责任部门，在通用化实现过程中有着不可替代的作用。

那什么工作应该由基础架构做，什么工作应该由业务团队做呢？

我理想中的基础架构团队应该是这样的：

分类	正例	反例
有目标	明确知道做什么，做成什么样子，未来要做成什么样子	没有目标，业务要啥做啥，满足当前业务需求即可。 没有规划，不进行深入研究、优化。不想办法提升公共组件的易用性、稳定性，提供给业务研发人员使用，而是自己使用公共组件，忙于业务功能开发。
能营销	把基础组件当成一个产品进行营销，明确基础组件给业务研发带来的好处，让业务研发主动去使用。	1、不对外介绍基础架构组都有哪些组件，每个组件的优势是什么，能带来什么收益 2、以公司规章逼迫使用
可闭环	1、不断收集业务诉求，与基础组件的规划融合在一起，不断进行优化	不关注使用是否便捷，不关注业务方提出的优化诉求

5、通用化的选择

通过第4节的分析可以看到，阶段2投入少，对业务人员、研发人员要求较低，投入产出比较高。

阶段3实现难度较大，需要业务、研发人员紧密配合，并具备高超的专业素养，才有可能做到。

其实，也可以看看周边，有哪些公司实现了业务中台就明白了。

6、总结

普通公司建议阶段2上进行强化就够了。

阶段3更适合超级公司。