江苏龙网

  1. 主页 > 生活百科 > >

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

中台


全局大中台虽未建成，单各个事业部都开始在研发中试着使用中台思维去思考自己的研发体系 。中台的理念一定是没错的，只是要因地制宜，切忌一刀切 。
早期，大家只会思考基础设施的复用性，产品如各种中间件等，现在大家开始关心另外一个问题了：这个业务能不能做成一个通用能力 。
又或者，会先问问其他同学：集团是不是有这样的业务能力可以复用过来?这就是一种良性的影响 。
中台，未必要大 。前台，未必就小 。能避免低水平重复性劳动的研发体系，就是可以被称为优秀的研发模式 。
企业如何建设适合自己的中台
中台建设的通用步骤
①定义需要快速变化、试错的前台业务(业务线、产品线)
如果您都无法清晰的定义自己的业务线，那么可以先内部脑暴一下 。先基于现有的业务线讨论，再继续讨论未来可能发展的业务线 。
②领域分析和模块划分
架构师在充分了解了每个业务线后，梳理出每个业务线所需要的业务领域块 。
这对架构师的要求很高，纯粹的业务架构师可能无法胜任，但是可以参与讨论，因为业务架构师可能对研发细节欠缺考虑，从而做出形而上无法落地的复用设计 。
③识别业务线共性并归类
架构师进行前台业务线归类 。通过上文的讨论我们知道中台的本质是复用性设计，那么业务线分类就是把可以大程度进行复用业务逻辑的业务线放到一起 。这部分需要资深架构师参与，毕竟这很大程度上是一个经验活 。
有些不该放到一类的业务线应当分开，比如金融业务和电商业务大相径庭，硬是搞一个团队同时维护两套系统，甚至揉在一个系统里，结果是不会太好的 。
④画出领域模块(能力)对齐图
由 2、3 步骤可以画出一个各业务线所需的领域能力图 。把名字相同(或者类似)的领域能力对齐 。
如下图所示大致的内容为：

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

文章插图
 
先申明下，该图只是提供一种参考，着重去说明复用设计的通用步骤，不具备实际的参考意义，各企业应当结合自身的具体现状具体分析 。
图中每一列相同的颜色代表它们可以做成一套系统，给各个前台复用 。从图中我们可以看出以下关键信息：
一般来说相同业务类别相同的他们的领域划分也比较类似，但也存在反例，比如本地生活中的外卖和到店 O2O，可能在商品、营销上有着很大的差异 。
用户中心一般不带有具体的业务信息，这部分是可以做成全局统一的，也方便统计用户画像 。
当然了，各个业务线除了对接这个统一的用户中心外，还是要各自记录一些跟自身业务相关的用户信息，比如金融用户的征信信息等，这种信息可能还需要由另外的系统来承载：比如征信中心 。
同样的商家结算，一般都是 B2B 之间的资金往来，业务不同仅仅影响的是交易凭证的描述不同，其他的结算方式等完全可以复用 。
商品中心，看起来各个业务都有商品中心，但是各个业务线的商品结构可能存在差异，比如金融和传统电商的商品中心，其实现逻辑应当是不一样的 。
当然，硬要把金融产品标上价格，打上 SKU 去传统电商前台去卖，也是可以的，只是这种方式带来的问题需要事先想好怎么克服，例如，谁来配置这些 SKU，谁来进行商品售后等等 。
一般涉及货物差异性的业务，都会用到评价中心，这是对商户货物品质的一种用户反馈 。
而在金融行业的贷款业务看来一般不会对不同的资金提供方去做评价，不排除其他业务会有，比如基金业务等 。
而有些领域是业务特有的，比如电商经常需要用到竞价中心，它负责对手商品价格的抓取和匹配等 。
⑤严格遵循开闭原则，从底至上的去实施
针对我们上文找出的存在复用可能性的领域(每一列里颜色相同的领域块)，架构师需要识别出其边界和专注解决的问题，最后安排不同的产研团队去实施 。
各个领域块的研发团队在实施时应当尽可能的抽象公共业务逻辑，并且将无法通用的环节做成开放式的 。
只要按照这个思想创建的系统，即便没有配置后台，上层业务系统对接也是极其轻松的 。
这里推荐另一篇笔者的文章《浅谈微服务体系中的分层设计和领域划分》，它讲述的就是一种搭建通用大后端的系统架构，按照柔性的定义，这也是中台：它可以支撑新业务应用快速研发 。
在完成了通用能力的搭建后，我们还可以为每个通用能力去构建配置后台，这样可以更快的给前台应用研发提速，配置优于研发带来的好处就是不需要走研发流程就可以完成一定的定制逻辑 。


推荐阅读


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

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