博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
系统一定要做成中台吗?
阅读量:3594 次
发布时间:2019-05-20

本文共 2015 字,大约阅读时间需要 6 分钟。

中台这两年很火,很多系统负责人做系统规划时或多或少会想让系统有中台的影子,那是不是一定要把系统做成中台呢?

结论是:肯定没有必要。

但是我们可以借鉴中台的思路去谈系统的设计与演进。

系统的演进本质是对于业务在技术上的映射,所以合适很重要。我之前的文章也多次提到过一个系统大致的业务演进脉络,以及所映射的技术实现方式。

  • 比如早期为追求快,all in one可能是很好的选择。

  • 业务发展快了,基于DDD或SOA的服务划分与团队组织可能是最有交付效率的方式。

  • 随着业务规模的爆发增长,我们需要过渡到服务化、分布式阶段,做开发一些独立的服务沉淀通用能力,比如中间件去做分布式的一些通用实现。

  • 发展到后期业务规模庞大且相对稳定,这个阶段需要投入到技术方向的工作是应对多活、中台、全面云化等动作,一步步推向落地。

回到中台来,中台优先侧重于解决组织上的分工和重定义上,优先解决生产关系的问题,所以才有“小前台、大中台”的说法。

所以在中台推进过程中肯定会伴随着新组织的设计,技术团队想要做好中台,单纯靠理念和共识是远远不够的,需要通过组织自上而下的推进,如果是自下而上去推进的话,成功率则大大降低。

很多人知道中台是从SuperCell开始的,但当进一步了解SuperCell的公司文化和工作机制之后,才知道创造“中台奇迹”的原因,比如SuperCell鼓励庆祝失败,最大程度授权,追求好玩而非赚钱。在SuperCell内部追求小而精的业务开发团队(前台团队)和提供强大的工具与服务中台(通用能力沉淀与复用)。

前者追求麻雀虽小五脏俱全,小道足以灵活并沟通成本最低。后者追求足够强,而不是足够广(不是什么都需要做到中台)。

所以如果没有组织或文化上的自上而下的推进,而单纯的技术中台是非常难以落地的。

目前大家对于中台的参与主要有两种角色:中台的打造者和中台的使用者。

很多人错误的认为中台是一个开箱即用的解决方案,但其实如果你真正参与中台建设之后你会有不同的感受。

首先是中台离业务很远,你很难直接感受到前台业务的业务价值,因为中台做的是抽象,反而是弱化了对于个性化业务的感受。

在整个架构中,中间件可以帮助我们解决10%~20%的底层通用问题,而中台系统建设就需要去解决那些业务复用的问题。但是由于很多中台同学离业务太远,想要对业务有足够的抽象和沉淀就比较困难,所以中台对于业务的抽象就有一定的滞后性,对业务快速开发支持作用有限。

以阿里为例,中台最早要解决的也不是业务的快速支持问题,而是不同业务的打通问题,只不过通过中台打通业务后,中台本身也会变成一个单点瓶颈,然后才考虑如何解决瓶颈带来的开发效率和新业务的快速支持问题。

很多时候我们做一件事情的出发点往往决定了最终的走向和结果。所以如果考虑的是能力复用的需求,那么中台更适合沉淀已有的能力,对于全新业务如果和之前沉淀的业务关联不大,中台支持并不好。

还有就是中台团队对于前台业务支持的资源有限,中台团队和前台团队有不同的KPI,比如前台业务是快速交付业务的,如果老板不能很好的做好前台业务的快速迭代,而想过分依赖于中台团队资源支持往往不太现实,因为过分依赖会导致链路过长、协作周期长、参与人员多、定制开发多,看起来效率也提升不起来,整体的交付周期不够理想。

中台做需求的沉淀和通用,但是由于中台的滞后性,中台本身对业务的抽象和开发定制支持是有限的,因为不能做到完全灵活组合与配置,过度的灵活与配置其实是无意义的。所以在中台设计时,需要考虑到变与不变,比如支付是交易流程不能省略的步骤,但是交付流程可以配置成到店交付、到家交付等方式。但不管如何,都要在中台定义的框架内去设计,这就导致了有些业务其实是无法100%适配的。

上面提了几点打造中台或使用中台过程中的一些感受,但是对于中台肯定不是完全否定的。中台体现了很强的技术属性(抽象、沉淀、复用、打通),某种程度上说是将这些技术属性进一步延伸到业务上,当业务体量达到一定规模后就会实现利大于弊。

如果说技术属性沉淀的是技术组件,那么中台沉淀的是业务组件。但是我们需要意识到企业数字化需求是千差万别的,难以一招鲜吃遍天。能不能做出技术中台很大程度上受限于业务形态、业务发展阶段的影响。如果业务阶段和业务规模没有发展到这个阶段,大张旗鼓搞中台ROI其实可能非常低。

那么中台对于系统演进是否有借鉴意义呢?

意义肯定是有的,比如我们对系统的演进转移到关注于抽象和共性的沉淀,尽可能保持系统灵活多支撑相似的业务形态。

比如订单就需要考虑如何支持多品类的商品或营销、支付等,每次做设计时需要想下如果多一个业务形态你需要怎么支持。

所以如果想要搞中台可以先从一个系统入手,不要直接想着把所有的中台都往系统里面放,如果一个中台系统又大、又厚、响应又慢,其实没什么存在的价值。

如果你的系统实现了对于多品类业务的灵活支持,叫不叫中台有什么关系呢?

转载地址:http://uszzn.baihongyu.com/

你可能感兴趣的文章
Java 方法(方法重载)与数组
查看>>
Java 类、对象和构造器
查看>>
Java 三大特征:封装、继承(方法覆盖,this,super)和多态
查看>>
Layui 栅格系统、常用表单和校验与监听
查看>>
Java 抽象方法、final与static、代码块和内部类
查看>>
Java 接口与枚举
查看>>
Java System与Runtime类常用方法
查看>>
Java 进程/线程与线程同步/死锁
查看>>
Java Math、BigDecimal和BigInteger类常用方法
查看>>
Java Random、ThreadLocalRandom和UUID随机数类
查看>>
Java 线程通信与线程的生命周期
查看>>
Base64加密和解密JDK8
查看>>
AOP + Redis实现防止表单重复提交(注解方式)
查看>>
java对象转JSONObject、JSONObject转java对象及String转JSONObject
查看>>
JdbcTemplate.query返回list
查看>>
一条sql语句的一生
查看>>
MySQL中的锁及MVCC机制
查看>>
ACID
查看>>
MongoTemplate 使用or查询
查看>>
java生成图片,添加水印
查看>>