建立自己的网站平台的好处,网站域名怎么做分录,宁波好的seo外包公司,上海城乡建设管理局网站戳蓝字“CSDN云计算”关注我们哦#xff01;来源#xff1a;健荐作者#xff1a;王健从去年开始#xff0c;好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起#xff0c;给我带来了很多的困扰和思考与收获。故事的开始源于去年的技术雷达峰会… 戳蓝字“CSDN云计算”关注我们哦来源健荐作者王健从去年开始好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起给我带来了很多的困扰和思考与收获。故事的开始源于去年的技术雷达峰会我在会上做了一场关于平台崛起的主题分享《The Rise of Platform》这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起以及分享从基础设施到人工智能等各个领域不断涌现的各类平台以及平台化对于软件开发人员及企业的影响。记得当时在做演讲彩排的时候有同事就提到过在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空如果你提“中台”大家会更熟悉一些。而这也是我第一次听到“中台”这个词原来除了我们熟悉的“前台”和“后台”外居然还有个“中台”这样一个神奇的存在。那…… 中台到底是什么会不会又是另一个Buzzword呢这个从名字上看像是从前台与后台中间硬挤出来的新断层它与前台和后台的区别和界限到底在哪儿什么应该放到中台什么又应该放到前台或是后台它的出现到底是为了解决什么问题呢从那时开始一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨终于可以坐下来回顾一下这一年的实践与思考再次试图回答这些问题并梳理成文与大家交流探讨。一、中台迷思到处都在喊中台到处都是中台中台这个词在我看来已经被滥用了。在有些人眼里中台就是技术平台像微服务开发框架、Devops平台、PaaS平台容器云之类的人们都叫它“技术中台”。在有些人眼里中台就是微服务业务平台像最常见的什么用户中心订单中心各种微服务集散地人们都叫它“业务中台”。在有些人眼里中台应该是组织的事情在释放潜能平台型组织的进化路线图豆瓣中就提出了平台型组织和组织中台的概念这类组织中台在企业中主要起到投资评估与投后管理的作用类似于企业内部资源调度中心和内部创新孵化组织人们叫它“组织中台”。看完本篇你就会理解上边的这几类“中台”划分还是靠谱的更多我看到的情况是大家为了响应企业的“中台战略”干脆直接将自己系统的“后端”或是“后台”改个名就叫“中台”。中台到底是什么它对于企业的意义到底是什么当我们谈中台时我们到底在谈些什么想要寻找到答案仅仅沉寂在各自“中台”之中如同管中窥豹身入迷阵是很难想清楚的。不如换个 ⾓度从各类的“中台迷阵”中跳脱出来尝试以更高的视角从企业均衡可持续发展的角度来思考中台的价值来试图反推它存在的价值。所以为了搞明白中台存在的价值我们需要回答以下两个问题企业为什么要平台化企业为什么要建中台第一个问题企业为什么要平台化先给答案其实很简单因为在当今互联网时代⽤户才是商业战场的中心为了快速响应用户的需求借助平台化的力量可以事半功倍。不断快速响应、探索、挖掘、引领⽤户的需求才是企业得以⽣存和持续发展的关键因素。那些真正尊重用户甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展⽽反之那些在过去的成就上故步⾃封存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。很残酷但这就是这个时代最基本的的企业⽣存法则。⽽平台化之所以重要就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力⽤户响应力。这种能力可以帮助企业在商战上先发制⼈始终抢得先机。可以说在互联网时代商业的斗争就是对于用户响应力的比拼。又有点远大空是不是我们来看⼏个经典的例子:说起中台最先想到的应该就属是阿⾥的“⼤中台⼩前台”战略。阿⾥⼈通过多年不懈的努力在业务的不断催化滋养下将⾃己的技术和业务能力沉淀出一套综合能力平台具备了对于前台业务变化及创新的快速响应能力。海尔也早在⼗年前就已经开始推进平台化组织的转型提出了“平台⾃营体⽀撑⼀线⾃营体”的战略规划和转型⽬标。构建了“⼈单合一”、“⽤户付薪” 的创客文化真正将平台化提⾼到了组织的⾼度。华为在几年前就提出了“⼤平台炮火支撑精兵作战”的企业战略“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台⽀撑下小前台的作战策略。这种极度灵活又威力巨⼤的战法使之可以迅速响应瞬息万变的战场一旦锁定目标通过大平台的炮火群迅速精准对于战场进行强大的火⼒支援。可⻅在互联⽹热火朝天第四次工业革命的曙光即将到来的今日企业能否真正做到“以用户为中心”并不断提升自己的用户响应力来追随甚至引领用户的脚步持续规模化创新终将决定企业能否在这样充满挑战和机遇的市场上笑到最后在商业上长久保持创新活力与竞争力。而平台化恰好可以助力企业更快更好的做到这些所以这回答了第一个问题企业需要平台化。第二个问题企业为什么要建中台好想明白了第一个问题为什么需要平台化。但是平台化并不是一个新概念很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起对于企业来讲传统的“前台后台”的平台化架构又为什么不能满足企业的要求呢?好这就引出了我们的第二个问题企业为什么要建中台来先定义一下前台与后台。因为平台这个词过于宽泛了为了能让大家理解我在说什么我先定义一下本篇文章上下文下我所说的前台和后台各指什么前台由各类前台系统组成的前端平台。每个前台系统就是一个用户触点即企业的最终用户直接使用或交互的系统是企业与最终用户的交点。例如用户直接使用的网站手机App微信公众号等都属于前台范畴。后台由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源数据计算例如财务系统产品系统客户管理系统仓库物流管理系统等这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源也属于后台的一部分。后台并不为前台而生。定义了前台和后台对于第二个问题企业为什么要建中台同样先给出我的答案因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求后台更多解决的是企业管理效率问题而中台要解决的才是前台的创新问题。大多数企业已有的后台要么前台根本就用不了要么不好用要么变更速度跟不上前台的节奏。我们看到的很多企业的后台系统在创建之初的目标并不是主要服务于前台系统创新而更多的是为了实现后端资源的电子化管理解决企业管理的效率问题。这类系统要不就是当年花大价钱外购需要每年支付大量的服务费并且版本老旧定制化困难要不就是花大价钱自建年久失修一身的补丁同样变更困难也是企业所谓的“遗留系统”的重灾区。总结下来就两个字“慢”和“贵”对业务的响应慢动不动改个小功能就还要花一大笔钱。有人会说了你不能拿遗留系统说事儿啊我们可以新建后台系统啊整个2.0问题不就解决了。但就算是新建的后台系统因为其管理的是企业的关键核心数据考虑到企业安全、审计、合规、法律等限制。导致其同样往往⽆法被前台系统直接使用或是受到各类限制⽆法快速变化以⽀持前台快速的创新需求。此时的前台和后台就像是两个不同转速的⻮轮前台由于要快速响应前端用户的需求讲究的是快速创新迭代所以要求转速越快越好⽽后台由于⾯对的是相对稳定的后端资源⽽且往系统陈旧复杂甚至还受到法律法规审计等相关合规约束所以往往是稳定至上越稳定越好 转速也自然是越慢越好。所以随着企业务的不断发展这种“前台后台”的⻮轮速率“匹配失衡”的问题就逐步显现出来。随着企业业务的发展壮大因为后台修改的成本和⻛险较⾼所以驱使我们会尽量选择保持后台系统的稳定性但还要响应用户持续不断的需求自然就会将大量的业务逻辑业务能力直接塞到了前台系统中引入重复的同时还会致使前台系统不断膨胀变得臃肿形成了一个个⼤泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“⽤户响应⼒”用户满意度降低企业竞争力也随之不断下降。对于这样的问题Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中给出了一种解决方案即按照“步速”将企业的应用系统划分为三个层次正好契合前中后台的三个层次不同的层次采用完全不同的策略。而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断层我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层为前台减肥恢复前台的响应⼒又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层赋予这些业务能力更强的灵活度和更低的变更成本从而为前台提供更强大的“能力炮火”⽀援。所以企业在平台化的过程中需要建设自己的中台层同时包括技术中台业务中台和组织中台。总结思考并回答了文初提出的两个关于中台价值的核心问题解决了我对于中台产生的一些困惑不知道对你有没有启发让我最后再来总结一下1. 以用户为中心的持续规模化创新是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段并不是⽬标本身。2. 中台⽆论是技术中台、业务中台还是组织中台的建设根本上是为了解决企业响应⼒困境 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾提供⼀个中间层来适配前台与后台的配速问题沉淀能⼒打通并顺滑链接前台需求与后台资源帮助企业不断提升用户响应⼒。3. 所以中台到底是什么根本不重要如何想方设法持续提高企业对于⽤户的响应⼒才是最重要的。⽽平台化或是中台化只是恰巧走在了了这条正确的⼤道上。二、中台有哪些类型数据业务双中台提起中台绕不开也是最先想到的应该都是阿里巴巴的数据业务双中台。毕竟阿里的“大中台小前台”战略人尽皆知其威力也是显而易见的。以阿里这么大的体量经过了这么多年的厮杀在互联网快速迭代创新的竞争环境中仍然可以保持快速迭代创新上演了一场接一场现实版的大象跳舞中台战略的成功居功至伟。摘自《企业核心业务数字化转型最佳实践》阿里的数据业务双中台堪称经典上图摘取自钟华古谦于刚刚结束的2018云栖大会《企业核心业务数字化转型最佳实践》分享。从图中可见阿里中台主要体现为由业务中台和数字中台并肩构成的双中台并肩扛起了所有前台业务。业务中台将后台资源进行抽象包装整合转化为前台友好的可重用共享的核心能力实现了后端业务资源到前台易用能力的转化。数据中台从后台及业务中台将数据流入完成海量数据的存储、计算、产品化包装过程构成企业的核心数据能力为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。业务中台与数据中台相辅相成、互相支撑一起构建起了战场强大的后方炮火群和雷达阵。移动中台同样来自于2018年云栖大会杭州站在移动研发平台EMAS专场上阿里巴巴高级技术专家泠茗带来的分享中就为我们揭开了阿里移动中台的面纱。摘自《数字化转型 移动化先行 云栖大会上发布了哪些移动研发新利器》可见阿里的移动中台是构建在业务数据中台之上为更好更快的利用中台能力、快速迭代移动端产品又生生的挤出或是说沉淀出了一个新的中台层。移动中台建立在业务数据双中台之上更靠近移动前端战场我们可以类比成战场上的坦克群近距离支撑一线战场。技术中台大中台小前台并不代表前台不重要相反大中台的建设就是为了更好地服务好小前台大中台的威力也需要靠小前台的引导才能真正发挥和体现出来。就像是深入敌后的前台特种部队如果定位不到敌人的精确位置就算有再强大的水陆空中台炮火群也只是一群废铁而已。大中台小前台战略其实是给小前台的构建提出了更高的要求就像我们对于特种兵的要求也比一般的士兵高出很多一样。那如何快速构建出短小精悍武器精良战斗力十足的特种兵前台应用充分发挥和释放出中台炮火群的威力就需要依靠这里提到的技术中台。摘自《阿里技术手册-研发篇》技术中台就是将使用云或其他基础设施的能力以及应用各种技术中间件的能力进行整合和包装。过滤掉技术细节提供简单一致、易于使用的应用技术基础设施的能力接口助力前台和业务中台数据中台的快速建设。如果将业务数据双中台比喻成强大的中台炮火群可以直接对敌人进行进攻。那技术中台的作用就有些间接有点像前台特种兵身上各种先进的武器装备。精良易用的武器装备可以在大幅缩短前台特种兵的建设周期的同时大幅提高单兵作战能力令敌人胆寒。研发中台软件开发是一项工程涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”从而助力创新性应用的快速开发迭代也是我们看到的很多企业正在做的事情我们可以管这种关注与开发效能管理的平台叫做研发中台。如果说技术中台为前台应用提供了基础设施重用的能力那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。摘自《阿里技术手册-研发篇》上图摘自阿里的技术手册展示了阿里的效能事业部一直致力于构建的阿里研发效能平台有兴趣的同学可以去了解一下阿里自家的云效平台。ThoughtWorks帮助客户打造的DevOps云平台ThoughtWorks在敏捷与开发效能方面一直走在行业领先持续总结过去的经验并基于客户自身的需求和实际情况、结合最新的技术与客户一起携手成功打造了多个定制化的开发效能平台。总之开发效能是构建前中台应用过程中必不可少的重要一环。这方面的实践和能力通过沉淀结合快速开发框架平台例如微服务开发平台就形成了企业的研发中台。如果将技术中台比喻成前台特种兵的武器装备那效能中台就是前台特种兵的管理训练基地以及可以快速将战士运送到一线战场的机动运输部队。组织中台以上无论是业务中台、数据中台、技术中台、研发中台……都是围绕技术展开的也是企业在中台建设中最关注的方面。但真正实际经历过几次企业级中台的建设后我深刻的体会到围绕技术展开并不是基于在中台构建中技术的重要性而是因为技术的改进相对简单。而中台建设真正困难的是组织上的重构这往往是大家有意无意避而不谈的。中台战略的成功、能否实现技术架构与组织架构的匹配是一道绕不过去必须要迈过的门槛。从阿里成立共享事业部海尔的人单合一、职能并联到近期大家关注的腾讯的组织架构重构都是这些企业在这方面做出的努力。举个实际的例子在很多企业中一个新项目的启动从筹划到申请经过层层审批和评审短则一两月多则需要几个月的时间。要知道在当前所处的互联网时代几个月都够人家App都上线了。摘自《释放潜能-平台型组织的进化路线图》为了真正解决企业创新在组织层面的摩擦和阻力构建真正的平台型组织。《释放潜能-平台型组织的进化路线图》提出了上图这样一个平台型组织的组织结构。组织中台很像企业中的内部风投和创新孵化机构为前台组织和团队构建创新型前台应用提供类似于投资评估项目甄别、投资管理、投后管理孵化与风控真正从组织和制度上支撑前台组织和应用的快速迭代规模化创新。知易行难ThoughtWorks在科技时代精益企业背景下提出的“价值驱动决策”框架并用“EDGE”命名主要针对如何在市场高速变化时保证投资有效性即致力于帮助客户在组织上和投资管理上真正的助力创新也算是在组织中台建设上迈出的一步。如果还用前边军队的比喻那组织中台是什么呢可能你已经想到了对就是战场指挥部。到底中台长啥样列举了这么多各式各样的中台最后都扯到了组织层面是不是有种越听越晕的感觉是不是感觉什么东西加个“中台”的后缀都可以靠到中台上来估计很快就会看到例如AI中台VR中台搜索中台算法中台……对了算法中台已经有了……让我们引用一段阿里玄难在接受极客公园采访时提到对于中台的一段我非常认同的描述本文中我们一直提到的一个词就是“能力”从玄难的这段采访也可以看出在阿里“能力”也是中台的核心。甄别是不是中台还要回到中台要解决的问题上也就是我上篇文章主要关注的问题。我认为一切以”以用户为中心的持续规模化创新”为目的将后台各式各样的资源转化为前台易于使用的能力帮助我们打赢这场以用户为中心的战争的平台我们都可以称之为中台业务中台提供重用服务例如用户中心订单中心之类的开箱即用可重用能力为战场提供了强大的后台炮火支援能力随叫随到威力强大数据中台提供了数据分析能力帮助我们从数据中学习改进调整方向为战场提供了强大及时的雷达监测能力帮助我们掌控战场移动及算法中台提供了战场一线火力支援能力帮助我们提供更加个性化的服务增强用户体验为战场提供了陆军支援能力随机应变所向披靡技术中台提供了自建系统部分的技术支撑能力帮助我们解决了基础设施分布式数据库等底层技术问题为前台特种兵提供了精良的武器装备研发中台提供了自建系统部分的管理和技术实践支撑能力帮助我们快速搭建项目管理进度测试持续集成持续交付是前台特种兵的训练基地及快速送达战场的机动运输部队组织中台为我们的项目提供投资管理风险管理资源调度等是战场的指挥部战争的大脑指挥前线调度后方。所以评判一个平台是否称得上中台最终评判标准不是技术也不是长什么模样最终还是得前台说了算毕竟前台才是战争的关键才是感受得到战场的残酷看得见用户的那部分人。前台想不想用爱不爱用好不好用帮了前台多大的忙从中台获得了多大的好处愿意掏出多少利润来帮助建设中台这才是甄别中台建设对错好坏的唯一标准。对于中台来讲前台就是用户以用户为中心在中台同样适用。三、中台就是“企业级能力复用平台”有很多朋友在公众号后台给我留言来表达自己的想法我摘出来一个具有代表性的“互联网的企业就是爱炒概念。本来很明白的东西被他们一包装就变得高深莫测了。我理解中台就是敏捷响应机制…是一种思维或者理念…企业根据自己的实际情况落实就行。”对于这位同学的观点我很赞同中台本身就是一个比较抽象的概念很多时候我们被那个“中”字困住了整天在前与中中与后的具体差别和评判标准上纠结不已。但是就像“看板”不是“我们看到的那个板子”一样“中台”也不一定就是代表“处于中间平台”这两个字作为一个整体代表了一种新的思维和理念。在最新一期的ThoughtWorks技术雷达讨论阶段中国区的同学就把“ZhongTai”作为一个独立的技术点提交并没有做意译就像“Kanban”一样。那这种新的思维和理念到底是什么呢“中台”的背后到底意味着什么有没有价值价值何在这也我一直在不断询问自己的问题。要想搞清楚这些问题我认为一个关键点就是看我们是否能够给中台这个相对抽象的概念找到一个清晰的定义因为只有通过定义才能让抽象的概念清晰化从而明确边界、体现价值。如果让我给出一个定义目前我认为最贴切的应该是中台就是“企业级能力复用平台”。很简单有点失望是不是但是为了找到一个靠谱的定义我几乎花了快两年的时间期间有各种各样的定义曾浮现出来但至少到目前为止只有这个定义我觉得最贴切、最简单、也最准确它能解释几乎所有我碰到的关于中台的问题例如为什么会有那么多中台像上文提到业务中台数据中台搜索中台移动中台哪些才是中台哪些是蹭热点的中台与前台的划分原则是什么中台化与平台化的区别是什么中台化和服务化的区别是什么中台该怎么建设等等……这9个字看起来简单重要的是其背后对“中台”价值的阐释下面就让我为大家一一拆解来看。企业级首先中台一定是企业级的这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围甚至可以是跨企业例如现在同样火爆的生态的概念。按照徐昊ThoughtWorks中国区CTO的说法更贴切的叫法应该是“多前台产品团队”这里为了简单我还是用企业级来代表。当做中台建设的时候一定是跳出单条业务线站在企业整体视角来审视业务全景寻找可复用的能力进行沉淀从而希望通过能力的复用一方面消除数据孤岛业务孤岛一方面支撑企业级规模化创新助力企业变革滋生生态。所以虽然中台的建设过程虽然可以自下而上以点及面。但驱动力一定是自上而下的全局视角的并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门例如CIO级别领导或是企业的战略规划部门因为只有这些横跨多条业务线的角色和组织才会去经常反思与推动企业级的能力复用问题。这一点也引出了中台建设的一个关键难点就是组织架构的调整和演进以及利益的重新分配这是技术所不能解决的也是中台建设的最强阻力这个我打算在后续的文章里详细阐述。同时企业级也是区分企业中台化与应用系统服务化的关键点简而言之中台化是企业级、是全局视角服务化更多是系统级、是局部视角。所以从中台的兴起与爆发可以看到一种趋势就是越来越多的企业无论是由于企业运营效率的原因还是由于创新发展的需要对于企业全局视角跨业务线的能力沉淀都提高到了前所未有的战略高度。能力提到中台最常听到的一个词就是“能力”。可能是因为能力这个词足够简单又有着足够的包容度与宽度。企业的能力可能包含多个维度常见的例如计算能力技术能力业务能力数据能力AI能力运营能力研发能力……其中大部分的能力还可以继续细化和二次展开从而形成一张多维度的企业能力网。我在“中台到底长啥样”中已经举了一些常见的例子这里就不赘述了。可以说中台就是企业所有可以被“多前台产品团队”复用能力的载体。这里有一个经常碰到的问题就是对于某一家企业来讲你说了有这么多种不同类型的能力到底哪些能力才是我们企业需要的哪些是值得中台化的优先级又怎么划分这个问题比较大也很难有一个统一的答案。我们ThoughtWorks现在的做法是通过一系列Workshop从业务、数据、技术三个方面切入通过一系列方法结合企业愿景市场定位和数字化现状跨越多条业务线试图将企业需要的能力和可复用的能力识别出来并为落地做好规划和准备。这些会在后续写到中台如何落地的文章时再详细展开。复用讲到这儿相信大家一定有一个疑惑无论是说企业级多前台产品团队还是讲能力沉淀都不是什么新话题。很多企业组件化服务化平台化搞了好多年那「中台」到底有哪些新的启发我的答案就是对于“复用”的关注被提高到了一个前所未有的高度。虽然我们一直讲“去重复用”讲了很多年但仔细想想大多平台化建设会将重点放在“去重”消除重复上而对于“复用”则没有足够的关注。很多企业都号称已经建成了各种各样成熟的平台但是我们问心自问一下有多少平台是业务驱动的有多少前台产品团队又是自愿将自己的产品接入到平台上的有多少平台建设者是在真正关注前台产品团队的平台用户体验“去重”讲的更多是向后看是技术驱动的“复用”讲的更多是向前看是业务驱动和用户驱动的。所以两个词虽然经常一起出现一起被提及但是谈论的完全不是一件事情目的不同难度也不同做到“去重”已然非常困难关注“复用”的就更是寥寥无几所以“复用”是中台更加关注的目标“可复用性”和“易复用性”是衡量中台建设好坏的重要指标“业务响应力”和“业务满意度”也才是考核中台建设进度的重要标准。而实现更好的复用常常改进的方向有两个方面一方面将更高抽象例如业务模式级别的通用业务逻辑通过抽象后下沉到中台这样前台就会更轻学习成本和开发维护成本更低越能更快的适应业务变化缺点是抽象级别越高越难被复用需要架构师对于各业务有深入的理解和非常强的抽象能力。另一方面就是通过对于中台能力的SaaS化包装减少前台团队发现中台能力和使用中台能力的阻力甚至通过自助式Self-Service的方式就快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。平台这里的平台主要是区别于大单体的应用或是系统。传统的企业数字化规划更多的是围绕业务架构应用架构和数据架构展开。产出也是一个个基于应用和系统的数字化建设规划例如要采购或是自建哪些具体的系统例如ERP、CRM等。当然这个过程并没有什么问题可以理解此时这些独立的系统就承载了企业的各种能力由于企业各业务线统一使用一个应用或系统也自然实现了能力的复用。但问题常常出现在两个方面一个是大单体系统的业务响应力有限缺少柔性当业务发展到一定阶段后必然产生大量定制化需求随着内部定制化模块的比例逐渐上升响应力成指数下降成为业务的瓶颈点。另一个则是系统间的打通通常比较困难容易形成业务孤岛和数据孤岛所以越来越多的企业开始像互联网学习以平台化的方式重塑企业IT架构从而对于业务提供足够的柔性来满足对于业务的快速响应和复用的需求。总结“企业级能力复用平台”这个定义虽然看起来简单但经过这么长时间对于中台的实践与思考我觉得如上文所述的这个定义背后所代表的意义是目前对中台价值的最贴切的阐释企业级定义了中台的范围区分开了单系统的服务化与微服务能力定义了中台的主要承载对象能力的抽象解释了各种各样中台的存在复用定义了中台的核心价值传统的平台化对于易复用性并没有给予足够的关注中台的提出和兴起让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上平台定义了中台的主要形式区别于传统的应用系统拼凑的方式通过对于更细力度能力的识别与平台化沉淀实现企业能力的柔性复用对于前台业务更好的支撑。有了定义后如何建中台的思路也就豁然开朗如果说中台是“企业级能力复用平台”的话那中台化就是“利用平台化手段发现、沉淀与复用企业级能力的过程”再回头看看这两年做的事情确实也都在围绕着这些展开。福利扫描添加小编微信备注“姓名公司职位”加入【云计算学习交流群】和志同道合的朋友们共同打卡学习推荐阅读如何高效地准备技术面试漫画有趣的“帽子问题”我为什么放弃了 Chrome5天破10亿的哪吒为啥这么火Python来分析通俗易懂图解10大CNN网络架构互联网公司上演反腐风暴GitHub CEO 对断供表示无能为力程序员面试锦集| 开发者周刊在其他国家被揭穿骗子又盯上非洲? 这几个骗子公司可把非洲人民坑苦了……真香朕在看了
