中台是个什么鬼|白话中台战略( 三 )


我们看到的很多企业的后台系统 , 在创建之初的目标 , 并不是主要服务于前台系统创新 , 而更多的是为了实现后端资源的电子化管理 , 解决企业管理的效率问题 。这类系统要不就是当年花大价钱外购 , 需要每年支付大量的服务费 , 并且版本老旧 , 定制化困难;要不就是花大价钱自建 , 年久失修 , 一身的补丁 , 同样变更困难 , 也是企业所谓的“遗留系统”的重灾区 。
总结下来就两个字“慢”和“贵” , 对业务的响应慢 , 动不动改个小功能就还要花一大笔钱 。
有人会说了 , 你不能拿遗留系统说事儿啊 , 我们可以新建后台系统啊 , 整个2.0问题不就解决了 。
但就算是新建的后台系统 , 因为其管理的是企业的关键核心数据 , 考虑到企业安全、审计、合规、法律等限制 。导致其同样往往?法被前台系统直接使用 , 或是受到各类限制?法快速变化 , 以?持前台快速的创新需求 。
此时的前台和后台就像是两个不同转速的?轮 , 前台由于要快速响应前端用户的需求 , 讲究的是快速创新迭代 , 所以要求转速越快越好;?后台由于?对的是相对稳定的后端资源 , ?且往系统陈旧复杂 , 甚至还受到法律法规审计等相关合规约束 , 所以往往是稳定至上 , 越稳定越好 ,  转速也自然是越慢越好 。
【中台是个什么鬼|白话中台战略】所以 , 随着企业务的不断发展 , 这种“前台+后台”的?轮速率“匹配失衡”的问题就逐步显现出来 。
随着企业业务的发展壮大 , 因为后台修改的成本和?险较? , 所以驱使我们会尽量选择保持后台系统的稳定性 , 但还要响应用户持续不断的需求 , 自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中 , 引入重复的同时还会致使前台系统不断膨胀 , 变得臃肿 , 形成了一个个?泥球的“烟囱式单体应用” 。渐渐拖垮了前台系统的“?户响应?” , 用户满意度降低 , 企业竞争力也随之不断下降 。
对于这样的问题 , Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中 , 给出了一种解决方案 , 即按照“步速”将企业的应用系统划分为三个层次(正好契合前中后台的三个层次) , 不同的层次采用完全不同的策略 。
而Pace-Layered Application Strategy也为“中台”产生的必然性 , 提供了理论上的支撑 。
Pace-Layered Application Strategy

中台是个什么鬼|白话中台战略

文章插图
(Gatner: Pace-Layered Application Strategy)
在这份报告中Gatner提出 , 企业构建的系统从Pace-Layered的?度来看可以划分为三类: SOR(Systems of record ) , SOD(Systems of differentiation)和SOI(Systems of innovation) 。
处于不同Pace-Layered的系统因为?的不同 , 关注点不同 , 要求不同 , 变化的“速率”自然也不同 , 匹配的也需要采?不同的技术架构 , 管理流程 , 治理架构甚至投资策略 。
?前面章节我们提到的后台系统 , 例如CRM、ERP、财务系统等 , 它们?多都处于SOR的Pace-Layered 。这些系统的建设之初往往是以规范处理企业底层资源和企业的核?可追溯单据(例如财务单据 , 订单单据)为主要?的 。它们的变更周期往往比较? , ?且由于法律律审计等其他限制 , 导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求 , 这就导致了它们往往变化频率低 , 变化成本高 , 变化?险高 , 变化周期? 。?法满?由?户驱动的快速变化的前台系统要求 。
我们又要尽力保持后台(SOR)系统的稳定可靠 , ?要前台系统(SOI)能够?而美 , 快速迭代 。就出现了上文提到的”齿轮匹配失衡“的问题 , 感觉鱼与熊掌不可兼得 。
正当陷入僵局的时候 , 天空中飘来一声IT谚语:
软件开发中遇到的所有问题 , 都可以通过增加?层抽象?得以解决!


推荐阅读