白话中台战略2:中台到底长啥样?

在上篇《白话中台战略-1开篇:中台是个什么鬼?》中,我试着依据自己的经验和理解,阐述了中台产生的原因以及最终建设目的,可能会过于抽象,大家听得还是云里雾里,本文就试图通过我的收集和思考,带着大家一起来看看中台到底“长啥样”,以期让大家有个直观的印象。话不多说,咱们直接开讲。

数据业务双中台

提起中台,绕不开也是最先想到的应该都是阿里巴巴的数据业务双中台。毕竟阿里的“大中台小前台”战略人尽皆知,其威力也是显而易见的。

以阿里这么大的体量,经过了这么多年的厮杀,在互联网快速迭代创新的竞争环境中,仍然可以保持快速迭代创新,上演了一场接一场现实版的大象跳舞,中台战略的成功居功至伟。

(摘自《企业核心业务数字化转型最佳实践》)

阿里的数据业务双中台堪称经典,上图摘取自钟华(古谦)于刚刚结束的2018云栖大会《企业核心业务数字化转型最佳实践》分享。

从图中可见,阿里中台主要体现为由业务中台和数字中台并肩构成的双中台,并肩扛起了所有前台业务。

  • 业务中台将后台资源进行抽象包装整合,转化为前台友好的可重用共享的核心能力,实现了后端业务资源到前台易用能力的转化。
  • 数据中台从后台及业务中台将数据流入,完成海量数据的存储、计算、产品化包装过程,构成企业的核心数据能力,为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
  • 业务中台与数据中台相辅相成、互相支撑,一起构建起了战场强大的后方炮火群和雷达阵。

移动中台

同样来自于2018年云栖大会杭州站,在移动研发平台EMAS专场上,阿里巴巴高级技术专家泠茗带来的分享中就为我们揭开了阿里移动中台的面纱。

(摘自《数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器》)

可见阿里的移动中台是构建在业务&数据中台之上,为更好更快的利用中台能力、快速迭代移动端产品,又生生的挤出(或是说沉淀)出了一个新的中台层。

移动中台建立在业务数据双中台之上,更靠近移动前端战场,我们可以类比成战场上的坦克群,近距离支撑一线战场。

技术中台

大中台小前台,并不代表前台不重要,相反,大中台的建设就是为了更好地服务好小前台,大中台的威力也需要靠小前台的引导才能真正发挥和体现出来。

就像是深入敌后的前台特种部队如果定位不到敌人的精确位置,就算有再强大的水陆空中台炮火群,也只是一群废铁而已。

大中台小前台战略,其实是给小前台的构建提出了更高的要求,就像我们对于特种兵的要求也比一般的士兵高出很多一样。

那如何快速构建出短小精悍,武器精良,战斗力十足的特种兵前台应用,充分发挥和释放出中台炮火群的威力,就需要依靠这里提到的技术中台。

(摘自《阿里技术手册-研发篇》)

技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节,提供简单一致、易于使用的应用技术基础设施的能力接口,助力前台和业务中台数据中台的快速建设。

如果将业务数据双中台比喻成强大的中台炮火群,可以直接对敌人进行进攻。那技术中台的作用就有些间接,有点像前台特种兵身上各种先进的武器装备。精良易用的武器装备,可以在大幅缩短前台特种兵的建设周期的同时大幅提高单兵作战能力,令敌人胆寒。

研发中台

软件开发是一项工程,涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”,从而助力创新性应用的快速开发迭代,也是我们看到的很多企业正在做的事情,我们可以管这种关注与开发效能管理的平台叫做研发中台。

如果说技术中台为前台应用提供了基础设施重用的能力,那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。

(摘自《阿里技术手册-研发篇》)

上图摘自阿里的技术手册,展示了阿里的效能事业部一直致力于构建的阿里研发效能平台,有兴趣的同学可以去了解一下阿里自家的云效平台。

(ThoughtWorks帮助客户打造的DevOps云平台)

ThoughtWorks在敏捷与开发效能方面一直走在行业领先,持续总结过去的经验,并基于客户自身的需求和实际情况、结合最新的技术,与客户一起携手成功打造了多个定制化的开发效能平台。

总之,开发效能是构建前中台应用过程中必不可少的重要一环。这方面的实践和能力通过沉淀,结合快速开发框架平台,例如微服务开发平台,就形成了企业的研发中台。

如果将技术中台比喻成前台特种兵的武器装备,那效能中台就是前台特种兵的管理训练基地以及可以快速将战士运送到一线战场的机动运输部队。

组织中台

以上无论是业务中台、数据中台、技术中台、研发中台……都是围绕技术展开的,也是企业在中台建设中最关注的方面。

但真正实际经历过几次企业级中台的建设后,我深刻的体会到:围绕技术展开并不是基于在中台构建中技术的重要性,而是因为技术的改进相对简单。

而中台建设真正困难的是组织上的重构,这往往是大家有意无意避而不谈的。

中台战略的成功、能否实现技术架构与组织架构的匹配,是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部,海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。

举个实际的例子,在很多企业中一个新项目的启动,从筹划到申请经过层层审批和评审短则一两月,多则需要几个月的时间。要知道在当前所处的互联网时代,几个月都够人家App都上线了。

(摘自《释放潜能-平台型组织的进化路线图》)

为了真正解决企业创新在组织层面的摩擦和阻力,构建真正的平台型组织。《释放潜能-平台型组织的进化路线图》提出了上图这样一个平台型组织的组织结构。

组织中台很像企业中的内部风投和创新孵化机构,为前台组织和团队构建创新型前台应用提供类似于投资评估(项目甄别)、投资管理、投后管理(孵化与风控),真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新。

知易行难,ThoughtWorks在科技时代精益企业背景下提出的“价值驱动决策”框架并用“EDGE”命名,主要针对如何在市场高速变化时保证投资有效性,即致力于帮助客户在组织上和投资管理上真正的助力创新,也算是在组织中台建设上迈出的一步。

如果还用前边军队的比喻,那组织中台是什么呢?可能你已经想到了,对,就是战场指挥部。

到底中台长啥样?

列举了这么多各式各样的中台,最后都扯到了组织层面,是不是有种越听越晕的感觉,是不是感觉什么东西加个“中台”的后缀都可以靠到中台上来,估计很快就会看到例如AI中台,VR中台,搜索中台,算法中台……对了,算法中台已经有了……

让我们引用一段阿里玄难在接受极客公园采访时提到对于中台的一段我非常认同的描述:

本文中我们一直提到的一个词就是“能力”,从玄难的这段采访也可以看出,在阿里“能力”也是中台的核心。

甄别是不是中台还要回到中台要解决的问题上,也就是我上篇文章主要关注的问题。我认为一切以”以用户为中心的持续规模化创新”为目的,将后台各式各样的资源转化为前台易于使用的能力,帮助我们打赢这场以用户为中心的战争的平台,我们都可以称之为中台:

  • 业务中台提供重用服务,例如用户中心,订单中心之类的开箱即用可重用能力,为战场提供了强大的后台炮火支援能力,随叫随到,威力强大;
  • 数据中台提供了数据分析能力,帮助我们从数据中学习改进,调整方向,为战场提供了强大及时的雷达监测能力,帮助我们掌控战场;
  • 移动及算法中台提供了战场一线火力支援能力,帮助我们提供更加个性化的服务,增强用户体验,为战场提供了陆军支援能力,随机应变,所向披靡;
  • 技术中台提供了自建系统部分的技术支撑能力,帮助我们解决了基础设施,分布式数据库等底层技术问题,为前台特种兵提供了精良的武器装备;
  • 研发中台提供了自建系统部分的管理和技术实践支撑能力,帮助我们快速搭建项目,管理进度,测试,持续集成,持续交付,是前台特种兵的训练基地及快速送达战场的机动运输部队;
  • 组织中台为我们的项目提供投资管理,风险管理,资源调度等,是战场的指挥部,战争的大脑,指挥前线,调度后方。

所以,评判一个平台是否称得上中台,最终评判标准不是技术也不是长什么模样,最终还是得前台说了算,毕竟前台才是战争的关键,才是感受得到战场的残酷,看得见用户的那部分人。

前台想不想用,爱不爱用,好不好用,帮了前台多大的忙,从中台获得了多大的好处,愿意掏出多少利润来帮助建设中台,这才是甄别中台建设对错好坏的唯一标准。 对于中台来讲,前台就是用户,以用户为中心,在中台同样适用。


参考阅读


更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

Share

Service mesh 服务网格 | 雷达哔哔哔

位置

2018年11月第19期技术雷达,技术象限,建议评估。(最新版技术雷达已经发布,点击这里下载

标签

Microservices,linkerd,Istio

目标受众

系统架构师、开发人员

关注问题

目前的微服务架构大多基于类似于Spring Cloud全家桶的框架构建,尽管这样可以基本满足构建微服务系统架构在技术上的一些基础需求,例如常见的服务发现、配置管理、熔断、跟踪,安全等。但是也同样也带来了一些限制和成本,例如对于代码的侵入性较强、编程语言绑定、学习成本高等。

解决方案

将解决分布式架构下安全、熔断、限流、降级、服务发现、调用链分布式跟踪等功能从业务服务中彻底分离,打包放到Sidecar(边车)中,并挂接到服务上,实现业务逻辑部分与微服务技术架构部分的完全解耦。

解读

近几年微服务热度不减,而构建微服务架构一般要解决两个问题,一个是业务服务划分的问题,一个就是微服务基础技术架构的问题。

在技术架构层面,目前业界可选的通用方案也不多。在Java阵营目前相对主流的方案就是基于Spring Boot+Spring Cloud+Kubernetes来构建微服务基础架构,并辅以ELK,Zipkin,Swagger,Prometheus,Grafana等工具做一些运维监控的工作。

这样虽然可以满足我们在微服务架构(本质上就是一个松耦合的分布式架构)上的一些技术要求,但是也同样也带来了一些新的问题,例如上文提到的代码侵入性强,耦合高,开源框架拼接导致的技术学习成本高,协调配合需要打磨等。

Service Mesh(服务网格)的产生就是为了解决这个问题,而遵循的还是软件行业那句古老的谚语:

“任何软件工程遇到的问题都可以通过增加一个中间层来解决”

Service Mesh就是添加了这么一个中间层,并给他起了个形象的名字:Sidecar。

图片来源于架构之路微信公众号,请参见延展阅读

区分出了这个Sidecar(边车),我们的服务就将精力更多的专注于自身的业务本身。而微服务架构下服务间通讯涉及的所有脏活儿、累活儿就都交给Sidecar去处理。Sidecar和服务是松耦合的,可以挂接上去,也可以分离开。只要接口匹配,对于业务服务完全无侵入,无语言绑定。

Sidecar就像一个一个“助理”一样兢兢业业,而服务则享受老板的待遇,什么事只需要跟Sidecar交代一下,其他就不用管了,而Sidecar也只能通过其他服务的Sidecar与服务交互。 Sidecar之间相互通信,就形成了一张“网格”,这也是服务网格名字的寓意。

图片来源于架构之路微信公众号,请参见延展阅读

是的,Service Mesh添加的这一新的层次,就是我们一直在苦苦追寻的“微服务基础设施层”。这层的沉淀和浮现,让程序员的关注层次又上升了一个抽象,离业务也更近了一步。

顺手抛出个观点:软件开发的演进就是我们程序员所写的程序逐渐靠近业务本身的过程。

其他该抽象的抽象,该沉淀的沉淀:包括操作系统,编译器,开发语言,声明式编程,DSL,各种框架工具,ServiceMesh都是在做这些非业务部分的抽象和沉淀而已。

那再下一步会是什么?按照我上面的观点,目前来看一个很有竞争力的选手就是Serverless architecture,以后我们有机会再聊:)

相关Blip

延展阅读

支持工具

Share

Event streaming as the source of truth——历史永铭记、时间任穿梭 | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(第十九期雷达已发布,可至官网下载

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第六篇,依然关注架构,Blip是Event streaming as the source of truth

位置

2018年5月第18期技术雷达,技术象限,建议评估

标签

Kafka,Event Sourcing,ETL,Integration

目标受众

系统架构师

关注问题

在以微服务架构为代表、分布式系统架构越来越成为主流的当下,“如何保证不同限界上下文中数据的一致性”一直是系统架构设计上的一个主要挑战。尤其是在只留存数据最终镜像(Snapshot)的数据持久化方案下。有没有一种方案可以让数据同步变得简单、可靠且可溯源可重建?这一直是系统架构师在思考和追寻的。

解决方案

将事件(Event)作为主数据源(Single source of truth),在上下文内则可以直接使用事件溯源(Event Sourcing)获取领域对象的最新数据快照,对外则可以直接使用类似于Kafka的工具通过事件的传递和广播进行不同上下文间的同样基于事件溯源(Event Sourcing)的数据同步和转换(ETL)。

解读

可能很多同学看到上述的问题描述和解决方案后,还没看到这就儿就已经走了……

这其实也可以理解,太多术语让人不知所云。什么Event、Sourcing、Source of Truth、Snapshot,感觉这些词就是为了架构师彰显身份创造的……

其实吧,很简单,我们做个比喻大家就都清楚了。就拿大家熟悉的Git举例子,Git就是一个就是基于事件(Commit)和事件溯源(Commit Chain)的好例子:

假设你有一份你的代码(数据),我有一份我的代码(数据),两份代码处理不同的事情。突然有一天我发现你的代码(数据)其中有一块我也能用,在通过一通“亲切友好”的沟(暴)通(揍)后,我把你的最新代码直接拷贝过来,放到了我的代码库里,并定时拷贝这块最新的代码过来,这就叫做同步(Synchronizing)。

后来我发现你的代码和我的代码还有一些不匹配,很多逻辑我并不用,只需要很少一部分,而且还得修改一下才能与我的代码对接,这就叫做ETL(Extract-Transform-Load)。

作为一个有追求的程序员,我为这个拷贝转换的过程(ETL)写了个程序,每天早上7点工作前自动完成。但是这就引入了一个新的问题,这个程序经常出问题(不要问我为什么……),导致我的代码(数据)和你的最新代码(数据)不一致,我需要知道我最新的代码是哪一次同步的、是否完整,以及如何重新同步代码到最新,这个过程就叫溯源(Sourcing)和重建(Rebuild)。

随着我同步的代码(数据)越来越多,如何保证这些来自不同源的代码(数据)始终保持时间一致性,可溯源,可重建就慢慢成为一件比较难的事情,也就是我上面提到的这个Blip关注的问题。

在代码拷贝这个场景里,Git给我们提供了另一种解决问题的思路。即我们不再保存我们的代码在某一个时间点的完整代码即代码镜像(Snapshot),而只是保存Commit信息,而一个Commit可以理解成就是一个事件(Event)。当我们需要最新代码的时候,不是从代码库里直接复制出最新的完整的代码版本,而是通过Commit链,从头开始将一个一个Commmit Apply到一起,最终形成了代码最新的样子,这个过程就叫做事件溯源(Event Souring),这样我们不仅记录了某个时刻的数据,而且记录了整个历史!

Event streaming as the source of truth,所描述的就是将这种基于Event存储方案应用于我们的系统数据管理,即用存储Event来代替存储数据现状快照,这样我们就可以基于Event和Event Souring处理数据的同时,大大简化和增强不同上下文数据同步的能力。

也就具备了Git般的威力,可以在数据的历史中穿梭,可以基于某个时间点做不同数据源的一致性同步,可以溯源,可以回滚,可以重建。而数据同步也会像Fork,Fetch,Merge一样简单。

相关Blip

支持工具

延展阅读


更多精彩洞见,请关注微信公众号:思特沃克

Share

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

从去年开始,好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起,给我带来了很多的困扰和思考与收获。

故事的开始源于去年的技术雷达峰会,我在会上做了一场关于平台崛起的主题分享(《The Rise of Platform》),这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起,以及分享从基础设施到人工智能等各个领域不断涌现的各类平台,以及平台化对于软件开发人员及企业的影响。

(2017技术雷达峰会)

记得当时在做演讲彩排的时候,有同事就提到过,在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空,如果你提“中台”大家会更熟悉一些。

而这也是我第一次听到“中台”这个词,原来除了我们熟悉的“前台”和“后台”外,居然还有个“中台”这样一个神奇的存在。

那…… 中台到底是什么?会不会又是另一个Buzzword呢?这个从名字上看像是从前台与后台中间硬挤出来的新断层,它与前台和后台的区别和界限到底在哪儿?什么应该放到中台,什么又应该放到前台或是后台?它的出现到底是为了解决什么问题呢?

从那时开始,一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天,随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨,终于可以坐下来回顾一下这一年的实践与思考,再次试图回答这些问题,并梳理成文,与大家交流探讨。

中台迷思

到处都在喊中台,到处都是中台,中台这个词在我看来已经被滥用了。

  • 在有些人眼里:中台就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术中台”。
  • 在有些人眼里:中台就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务中台”。
  • 在有些人眼里:中台应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念,这类组织中台在企业中主要起到投资评估与投后管理的作用,类似于企业内部资源调度中心和内部创新孵化组织,人们叫它“组织中台”

看完本篇你就会理解,上边的这几类“中台”划分还是靠谱的,更多我看到的情况是大家为了响应企业的“中台战略”,干脆直接将自己系统的“后端”或是“后台”改个名,就叫“中台”。

中台到底是什么?它对于企业的意义到底是什么?当我们谈中台时我们到底在谈些什么?

想要寻找到答案,仅仅沉寂在各自“中台”之中,如同管中窥豹,身入迷阵,是很难想清楚的。不如换个 ⾓度,从各类的“中台迷阵”中跳脱出来,尝试以更高的视角,从企业均衡可持续发展的角度,来思考中台的价值,来试图反推它存在的价值。

所以,为了搞明白中台存在的价值,我们需要回答以下两个问题:

  1. 企业为什么要平台化?
  2. 企业为什么要建中台?

第一个问题:企业为什么要平台化?

先给答案,其实很简单:

因为在当今互联网时代,⽤户才是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。

不断快速响应、探索、挖掘、引领⽤户的需求,才是企业得以⽣存和持续发展的关键因素。

那些真正尊重用户,甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展;⽽反之,那些在过去的成就上故步⾃封,存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。

很残酷,但这就是这个时代最基本的企业⽣存法则

数字化企业

⽽平台化之所以重要,就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力:⽤户响应力。这种能力可以帮助企业在商战上先发制⼈,始终抢得先机。

可以说,在互联网时代,商业的斗争就是对于用户响应力的比拼。

又有点远大空是不是,我们来看⼏个经典的例子:

1.说起中台,最先想到的应该就属是阿⾥的“⼤中台,⼩前台”战略。阿⾥⼈通过多年不懈的努力,在业务的不断催化滋养下,将⾃己的技术和业务能力沉淀出一套综合能力平台,具备了对于前台业务变化及创新的快速响应能力。

(阿里中台)

2.海尔也早在⼗年前就已经开始推进平台化组织的转型,提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“⼈单合一”、“⽤户付薪” 的创客文化,真正将平台化提⾼到了组织的⾼度。

(海尔组织中台)

3.华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略,“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法,使之可以迅速响应瞬息万变的战场,一旦锁定目标,通过大平台的炮火群,迅速精准对于战场进行强大的火⼒支援。

(⼤平台炮火支撑精兵作战)

可⻅,在互联⽹热火朝天,第四次工业革命的曙光即将到来的今日,企业能否真正做到“以用户为中心”,并不断提升自己的用户响应力来追随甚至引领用户的脚步,持续规模化创新,终将决定企业能否在这样充满挑战和机遇的市场上笑到最后,在商业上长久保持创新活力与竞争力。

(数字化平台战略)

而平台化恰好可以助力企业更快更好的做到这些,所以这回答了第一个问题,企业需要平台化。

第二个问题:企业为什么要建中台?

好,想明白了第一个问题,为什么需要平台化。但是平台化并不是一个新概念,很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起?对于企业来讲,传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?

好,这就引出了我们的第二个问题:企业为什么要建中台?

来,先定义一下前台与后台

因为平台这个词过于宽泛了,为了能让大家理解我在说什么,我先定义一下本篇文章上下文下我所说的前台和后台各指什么:

  • 前台:由各类前台系统组成的前端平台。每个前台系统就是一个用户触点,即企业的最终用户直接使用或交互的系统,是企业与最终用户的交点。例如用户直接使用的网站,手机App,微信公众号等都属于前台范畴。
  • 后台:由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源(数据+计算),例如财务系统,产品系统,客户管理系统,仓库物流管理系统等,这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源,也属于后台的一部分。

后台并不为前台而生

定义了前台和后台,对于第二个问题(企业为什么要建中台),同样先给出我的答案:

因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求,后台更多解决的是企业管理效率问题,而中台要解决的才是前台的创新问题

大多数企业已有的后台,要么前台根本就用不了,要么不好用,要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统,在创建之初的目标,并不是主要服务于前台系统创新,而更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题。这类系统要不就是当年花大价钱外购,需要每年支付大量的服务费,并且版本老旧,定制化困难;要不就是花大价钱自建,年久失修,一身的补丁,同样变更困难,也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”,对业务的响应慢,动不动改个小功能就还要花一大笔钱。

有人会说了,你不能拿遗留系统说事儿啊,我们可以新建后台系统啊,整个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谚语:

软件开发中遇到的所有问题,都可以通过增加⼀层抽象⽽得以解决!

⾄此,⼀声惊雷滚过,“中台”脚踏七彩祥云,承载着SOD(Systems of differentiation) 的前世寄托,横空出世。

中台才是为前台而生

我们先试着给中台下个定义:

中台是真正为前台而生的平台(可以是技术平台,业务能力甚至是组织机构),它存在的唯一目的就是更好的服务前台规模化创新,进而更好的响应服务引领用户,使企业真正做到自身能力与用户需求的持续对接。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”,将前台与后台的速率进行匹配,是前台与后台的桥梁。它为前台而生,易于前台使用,将后台资源顺滑流向用户,响应用户。

中台很像Pace-Layered中的SOD,提供了比前台(SOI)更强的稳定性,以及⽐后台(SOR)更高的灵活性,在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台作为变速齿轮,链接了用户与企业核心资源,并解决了配速问题

有了“中台”这⼀新的Pace-Layered断层,我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应⼒;又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本,从而为前台提供更强大的“能力炮火”⽀援。

所以,企业在平台化的过程中,需要建设自己的中台层(同时包括技术中台,业务中台和组织中台)。

总结

思考并回答了文初提出的两个关于中台价值的核心问题,解决了我对于中台产生的一些困惑,不知道对你有没有启发,让我最后再来总结一下:

  • 以用户为中心的持续规模化创新,是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力,是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段,并不是⽬标本身。
  • 中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境, 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾,提供⼀个中间层来适配前台与后台的配速问题,沉淀能⼒,打通并顺滑链接前台需求与后台资源,帮助企业不断提升用户响应⼒。
  • 所以,中台到底是什么根本不重要,如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化,只是恰巧走在了了这条正确的⼤道上。

PS: 本文是《白话中台战略》的第一篇,后续还打算继续写,总结分享介绍从问题到解决方案,从技术到业务到组织的一些实践经验。会涉及到企业技术中台规划,业务中台规划,遗留系统微服务化改造落地一系列内容,先立个Flag,希望大家看后能给一些反馈,谢谢。


更多精彩洞见,请关注微信公众号:思特沃克

Share

Autonomous bubble pattern | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(第十九期雷达已发布,可至官网下载

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第四篇,依然关注架构,Blip是Autonomous bubble pattern

位置

2018年5月第18期技术雷达,技术象限,建议试验

标签

遗留系统、DDD、Bounded Context、ACL、Eric Evans

目标受众

系统架构师

关注问题

如何在遗留系统上继续保持构建新功能的能力,不受自身的限制与拖累,可以采用全新的架构甚至工程方法,同时保持相对独立的快速演进?

解决方案:

将新的功能和能力封装到新的独立上下文中,建立独立且完全自主控制的数据存储,采用同步的机制保证与其他上下文的数据一致性,形成完整独立的Autonomous bubble,用同步复杂性换取上下文完整性。

解读

之前在介绍Architectural fitness function时,我们谈到无论一个系统初建时多么新潮且纯粹,都会随着时间的洗礼,慢慢成熟,慢慢衰老,就像我在《技术的一生》中描述的场景一样。

碰到这种情况,我们通常会首先想到推倒重建,希望可以重回初生时的美好。但往往斥重金重建系统、短暂享受重获新生的喜悦之后,依然无法逃离时间和需求的侵浊,再一次走向衰老,成为另一个崭新的遗留系统。

有没有两全其美的方法,既能保持对于遗留系统足够敬畏,不用花费大量成本冒风险重建;又能应用新的技术和架构甚至工程方法为系统构建新的功能和能力,在老树上开出“新花”?

我们发现DDD(Domain-Driven Design)的作者Eric Evans早在2012年就提出的一种叫做Autonomous bubble pattern(自治气泡模式)的模式,对于解决这样的问题越来越有其用武之地。

这种模式乍一看,并无新奇之处,无非就是为新的功能或是应用创建一个新的限界上下文(Bounded Context),在新的上下文里采用全新的设计,并通过Anticorruption Layer(ACL:防腐层)匹配旧的遗留系统而已,常见的应用场景就像Eric Evans在视频中展示的一样:

但Eric Evans提出的Autonomous bubble pattern并不止于此。 精妙之处在于,他提出了另一种看似更复杂的解决方式,即为新的上下文提供完整的数据存储能力。并通过同步(Synchronizing)的方式保持新的上下文与遗留系统中的数据一致性,如下图。

Eric Evans在视频中也坦言,这种方式相比与第一个方案会更加“昂贵”,需要一些额外的工作来处理开发者们最为头疼的“同步”问题。

但我们认为由此带来的“上下文自主性”和“对于开发摩擦力(development friction)的减少”,是迈向现代化甚至未来架构的第一步,也是重要且勇敢的一步。

支持工具:

DDD

延展阅读:


更多精彩洞见,请关注微信公众号:思特沃克

Share