论系统通用化的边界

2023-12-29 14:21:37

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 的情况下,业务需求差异越来越大,实现业务中台的可能性及收益就非常小。

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

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

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

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

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

5、通用化的选择

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

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

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

6、总结

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

阶段3更适合超级公司。

文章来源:https://blog.csdn.net/u013252773/article/details/135271346
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。