三、中台的收益和价值

        中台的服务架构,可以让我们摆脱“烟囱式”系统建设所带来的种种发展桎梏,接下来我们用一个篇幅来讲述业务中台给我们带来哪些显著的收益和价值。

1、通用服务重用

          受项目制建设模式的影响,烟囱式的单体应用随着公司的发展和业务的增长会变得愈发臃肿到无法迭代。对于企业业务服务的持续发展和沉淀没有任何帮助。

          随着互联网技术的发展新的思想和技术诞生,从SOA到现在比较火的微服务技术,完美解决了烟囱式单体服务面临的各种问题。微服务是目前业界被验证的真正赋予企业业务快速响应和创新的科学架构。SOA和微服务理念最核心的价值是:松耦合的服务带来业务的复用,通过服务的编排助力业务的快速响应和创新。实现这种价值正是这些服务,只有这些服务在业务发展的过程中得到持续的演进、和功能的增强,最终变为企业在该领域最为专业的IT资产时,才能真正的达到前面提到的业务快速响应,更好的支持业务的创新。

          今天的阿里巴巴已经将20多个核心业务中公共的、通用的业务以服务的方式沉淀到了业务中台,整个集团的核心业务能力均建立这套业务中台体系之上,使得阿里在今天的业务支持中,发挥了微服务核心价值——服务重用。

 

        上图展示了阿里的共享服务如何支撑前端业务的,每个平台都有各自的订单创建流程,各流程的场景和业务逻辑是不同的,但是不管哪种场景下单都不会脱离 用户、商品校验,库存、促销和优惠券、订单创建、支付,这些服务均是有各自的服务中心提供,也就意味着不管前端业务形态如何多样,中台提供的服务都能个很好的提供所包含的核心服务,让前端业务的交易信息和数据回流到对应的服务中心。我们发现基于业务中台的服务建设能最大程度的避免“烟囱式”系统建设的第一个弊端“重复功能建设和维护带来的成本浪费”。

      因为“烟囱式”方式的系统建设,相关业务领域的业务和数据被分割到不同的系统中,比如之前举的例子品牌企业入驻天猫后在天猫旗舰店有天猫电商渠道的库存信息,在企业自建的电商平台上库存信息同样存在。随着业务的发展需要对企业整体库存进行统一管控,则不可避免的要打通以上几个系统。系统间打通要牵涉大量的协同和开发成本,成本是高昂的。

      基于业务中台服务体系的建设,原生就将相关业务的领域的业务功能和数据做了很好的统一,今天阿里巴巴已有2000多个应用,已经通过业务中台实现了统一和畅通。对于“烟囱式”系统建设带来的第二个弊端,需要打通不同系统间实现业务的交互带来的集成和协作成本可以最大程度的避免了。

 

2、培育创新土壤

企业需要的创新是来源于企业内部的,而不是外部所谓的专家告诉你如何创新,如果把在其他企业身上证明是好的创新搬到这家企业身上,效果可能完全不一样。好的创新一定是基于企业的现状因地制宜,而这决定了在很大程度上企业的创新会来自于企业内部,而且提出创新的人一定是对行业有过人的认识和理解,才能有可能提出创新想法。

        虽然很多行业都在进行跨界创新,但是对于大多数企业所做的创新还是在行业内的创新,这样的创新更多情况下是依赖行业内称得上专家的人,这样的人在行业特定领域一定有比普通人有更深的理解和认识,才能提出普通人想不到的创新。

        如何成为专家呢?我认为就像学习一样,我们最开始学习基础知识,去掌握知识点,随着我们掌握的知识点增多,我们开始有意识的讲知识点组合在一起,解决一些复杂的问题,关联这些知识点的过程实际上是讲这些知识点串成了线,随着业务领域的积蓄积累,越来越多的知识线汇集,我们就更全面的了解到这一知识领域(知识面),从而构建了这一领域自身的知识体系,而这时的你相信已经成为了这个领域的专家。

 

       阿里垂直业务线的1688、淘宝、天猫、聚划算、闲鱼都有各自的业务开发人员和架构师,他们对各自的交易业务非常的擅长,这都只是交易业务的“点”。二下方的交易中心中的业务开发人员或架构师所接触的都是来自不同各业务线的交易相关需求,这样的阵型是的负责“交易中心”的相关人员更容易扩展到线和面的维度,全面掌控交易的业务。结合签名的所说的理论,这样的服务体系能很好的培养出特定领域的专家。这些专家一定能为企业带来想要的创新能力吗?我坚信这是一个大概率事件。 

     2014年淘宝的的业务交易流程非常复杂,出现了个别业务不一致的情况,同年业务中台(共享服务中心)开发了一个BCP(business check platform 业务校验保障平台),通过该系统在2014年的双11就发现了超过10万个业务不一致的订单。给阿里带来了显著的业务价值,成为当年的创新奖的得奖项目。

 

3、赋予试错能力

      企业如果想在竞争对手中产生真正的差异化竞争力,我认为业务的试错是一个很重要的能力,只有先人一步,才能帮助企业抢占先机的制高点。互联网时代只有第一,没有第二。

      业务的创新如同创业,一旦成功回报巨大,但也意味着有失败的风险。在传统的企业中,要创新就要先申请预算和立项来落实业务创新的想法。 在传统的“烟囱式”系统建设方式对项目投入的资金和资源自然不会少,而且还有失败的可能性,在权衡利弊后大多数人会选择退缩只有少数有魄力的人顶着巨大压力走上了业务创新的道路。

       我们第一章提到的supercell这家公司,这家公司除了在企业文化上鼓励员工创新和试错外,更重要的是为公司业务的创新打造了一个坚实的业务中台。

      试想一下,如果你有一个好的创新想法需要去建设一个系统,你要完成这个想法所需要的资源投入20个人、4个月的时间,还有可能建设的系统达不到预期的市场效果,那这样的一个典型的试错成本是非常高昂的,任何一个企业都很难支持这一的试错方式。如果企业打造了业务中台,可以让3个人基于中台提供的核心服务在2个周的时间内就能成功建设一个系统并推向市场,看看市场的反馈来决定是否加大对这个新业务的投入,我想任何一家企业的领导都是很乐意做这样的投入和尝试的。

     便于大家理解中台,我举一个关于美军作战阵型的例子。美军在二战时以军为单位(10000 - 2000人)( 中国40000-5000)作战,  到了越战以营(500人左右)为单位作战;到了中东战争,以7人或11人的绩效办去作战,它是全世界最灵活的军事组织,也是核心竞争力和打击能力最强的组织。

 

 

美军之所以能敢放这么小的团队灵活作战,是因为有非常强的导弹指挥系统,有非常强大的中后台能力,引导整个进攻完成。美军这样的阵型和阿里巴巴的“大中台,小前端” 战略完全一致。

 

小前端团队的特质:

1)、团队协同效率最高

相比一个几十人、上百人的团队完成一项任务,几个人的效率是最高的。能以最短的时间达成统一和步调一致。

2)、调整方向更敏捷

俗话说“船大掉头难”,当发现任务的方向有错误的时候,上百人的团队的调整方向所花费的时间和资源一定远超过10个人的团队。所以一小团队的方式进行业务试错,一但业务出现方向性的错误时,不管是调整方向还是放弃,对于企业的资源投入范围都是可控的。

3)、一旦发现正确目标,全力投入扩大效果

这样的中台阵型,一旦前端作战团队发现目标,一个远程呼唤,后台的中台炮火群会瞬间摧毁目标。

举一个阿里巴巴最具代表性的例子,2010年随着团购业务的崛起,阿里也决定构建自己的团购平台,因为是一个新的业务模式所以阿里当时投入了产品经理、研发、运营等十几名员工进行团购平台的建设,最终在1个半月后就成功上线了。如果是其他的团购平台可能是阿里投入的几十倍,开发时间可能是阿里开发时间的好几倍,为什么投入会如此悬殊,最大的功劳就来自于阿里的业务中台。上线后在短时间内展现出巨大的流量,阿里意识到该业务的重要性,开始大量资源投入这一新业务,结果在短短14个月后,发展成了600人的事业部。这个团购平台就是“聚划算”,目前是与淘宝、天猫并驾齐驱的电商事业部。

 

4、储备价值数据

“烟囱式”的系统建设方案,是的相关业务领域的数据分布在不同的系统中,比如企业的会员信息可能分布在天猫、微信公证号、自建电商平台中,因为是不同的团队构建所以数据模型不统一,这就为大数据平台的同步带了很多复杂的工作,必然也对项目整体实施带来了风险。

 

5、提升组织效能

大多互联网公司都是以项目为导向的工作,一个项目上线后,就会投入到下一个项目。因为都是重复性工作,做了3年和5年的员工在开发能力上没有太大区别,差别可能做了5年的仅仅是熟练的技能多生产了几个不同的系统,员工不会随着工作时间的长短而让自己在业务或专业能力上得到提升。

有了业务中台,业务中台部门的员工按照服务中心的方式进行人员组织的重新编排,让员工在各自擅长和感兴趣的业务领域持续发展,团队成员对业务的理解和专业技能随着服务中心所提供的业务能力逐步完善而同步提升。 从而为团队培养出既懂技术又懂业务的复合型人才。

  • 2
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
对于大中台来讲,现在并没有十分严格的定义,每个企业对其的理解都是不同的,有的在技术上使用大中台模式,有的在业务上使用大中台模式,有的将两者相结合。“大中台,小前台”的机制最初阿里提出的时候,主要应用于O2O线上线下协同、电商等场景,对于电商来说,市场环境是瞬息万变的,而前台是主要的一线业务,这时就需要一个强大的技术中台提供快速设计方法和系统性后端服务,去应对市场变化,灵活快速的做出应对策略。 技术中台从技术角度出发,数据中台业务数据角度出发,业务中台站在企业全局角度出发,从整体战略、业务支撑、连接用户、业务创新等方面进行统筹规划,由基础中台、技术中台、数据中台L合支撑来建设业务中台。 本套中台案例基于真实工业界业务讲解,将多种经过工业界验证的成熟技术解决方案呈现给大家,本套课程拒绝枯燥的理论,全程代码实操,通过项目驱动的方式,让大家能够真实体验中台工业界开发过程,帮助大家建立中台思维,学习本套课程全部内容你完全可以自主开发一套高性能高可用高扩展的中台系统。本套案例集后端+前台+测试+运维一体,多方位的带你熟悉全过程。本课程将带大家实现一个真实的工业界中台项目,该项目是基于真实的知名互联网企业项目讲解,本课程将分为4个阶段: 第一阶段:会实现中台系统的大部分核心服务,包括:会员中心,商品中心,交易中心,商家中心,支付中心,友凡商城等等。 第二阶段:进一步完善中台系统的核心服务以及优化,包括:营销中心,搜索中心,店铺中心,缓存优化,数据库优化等等。 第阶段:进一步优化以及完善产品服务,包括:前台系统,中台系统,友凡商城 友凡生鲜,友凡超市等等。 第四阶段:项目收尾阶段以及运维阶段,包括:压力测试,系统维护,系统部署,虚拟化方案,测试方案等等。 本课程包含的技术: IDEA集成开发工具  SpringBoot 2.0.8.RELEASE SpringCloud Finchley.SR2 Thymeleaf(模板引擎技术)  支付宝支付 MyCat、MySQL、Druid  持续集成解决方案(Jenkins) 认证解决方案(JWT) 网关解决方案(Zuul) 负载均衡解决方案(Ribbon) 分布式事务+多线程+事件驱动 MyBatis+Redis+Quartz Ehcache+Hystrix Nginx(Web服务器) Restful AOP技术 性能压力测试Jemter  VUE+jQuery+Ajax+NodeJS VUE+Element-UI 容器部署Docker Kubertenes Lucene、ElasticSearch(搜索) 设计模式、RabbitMQ Swagger2 文档生成工具 人工智能(RNN、LSTM)多语言开发(Python、Django)课程亮点: 1.与企业无缝对接、工业界真实业务场景 2.集后端+前台+测试+运维一体,多面学习技术链 3.多语言协调开发,熟悉语言应用场景4.支持项目快速迭代和开发 5.引入人工智能智能客服系统 6.使用微服务技术栈+前后端分离构建项目 7.引入全新的设计理念 8.全链路性能压力测试 9.分布式事务解决方案 10.事件驱动设计解决方案 11.多线程技术+设计模式的实战应用 12.分布式架构下实现分布式定时调度 13.集成MyBatis实现多数据源路由实战 14.集成SpringCloud实现统一整合方案 15 Kubernetes+Docker容器化部署和管理 16.大型系统分布式部署方案 17.高性能系统(支撑海量数据) 18.高并发下的服务降级、限流实战 19.实现高并发请求和实现高可用架构解决方案 20.全程代码实操,提供全部代码和资料 21.提供答疑和提供企业技术方案咨询企业一线架构师讲授,代码在老师的指导下企业可以复用,提供企业解决方案。  版权归作者所有,盗版将进行法律维权。 

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值