数字化转型 推动母婴产业战略升级 品牌营销数字化管理旗舰品牌 全球1200家企业信赖之选 防伪·溯源·防窜·营销 多业务一并解决
您所在位置:首页 > 新闻中心 > 母婴研究 > 正文

中台启示录:企业更加合理的转型提速节奏

2020-02-18 07:59   来源:场量科技
概要:常言,B端决策缓慢又理性,为什么中台却如此迅速地席卷大江南北,从不断升温到碎片一地,中台究竟给我们什么样的启示?企业在面临新的技术概念时,如何更有条理地看待和采纳?

  中台按消费者(Consumer)调用的SLA来评价。比如一个模块,在做之前,如何通过价值评价来决策做或者不做?

  1、中台本质:企业架构治理

  尽管如今已经步入了Microservices与Cloud Native阶段了,但如果不是一家游戏类、照片类、音视频类纯数字化公司(据我观察,这类公司是早采用云计算技术的),我推崇还是搞清楚早期Microsoft的一篇架构文档中说明的三种架构层次。为什么?就像早期熟悉云计算架构必须看Amazon的技术白皮书一样,作为企业服务领域的一哥,Microsoft的总结有极强的参考价值:

  应用架构(Application Architecture),即系统技术架构,通常表现为带有数据库的三层/多层技术架构体系。

  产品/项目架构(Product/Project Architecture),后期又称之为解决方案架构(Solution Architecture),解决方案层与应用层的区别在于,它是业务导向的,致力于提升应用系统的业务质量。

  企业架构(Enterprise Architechture),它其实是一个规划过程,识别企业IT未来应该达到的状态,并实施一系列的计划,使项目团队通过交付达成。

  中台如何应对来自以用户为中心的业务挑战

  以用户为中心(Customer-centric)意味着向消费驱动的转变。企业产品与服务的推出不再内部可控,而是需要快速捕获外部用户的变化并响应用户的需求。曾经有客户问:业务部门一年复一年人员都没有增长,提需求的就是这些人,为啥我们的技术部门人员年年增长还不能完成需求?原因就在于:提需求的人是没有增长,但提需求的节奏、频率、变化都大大提升了。

  2007年时还没有Micoroservice架构,后来由Netflix在整合移动多屏及个性化时被实现。

  中台成功核心在于业务治理

  Morgan在一篇文章《Adoption, rather than Architechure, is the high order bit for Architects》中指出,企业架构重要的是组织对齐。“对齐”是国内某家企业跨部门沟通爱用的词,也充分体现了该企业强大的组织能力。

  中台与ESB的核心差异是什么?在于业务服务能力(Capability)的下沉。ESB是消息总线,解决系统异构信息交换问题,而中台集成的是各种服务提供方,解决业务能力共享的问题。中台服务面向的颗粒度更细,更强调的是封装完整的业务资源、逻辑和流程,每个服务有更强的自治性,而ESB的出现更单纯地是为了解决系统层面的协作。比如说,早年企业针对销售部门有一个订单管理系统,后来针对售后部门又开发了一个服务管理系统,后发现,售后需要回溯销售合同的条款,一开始通过批量同步,还行;后面量大了,批量处理已经延后了,就需要两个系统更及时地同步。如果作为中台架构师,在业务资源识别时,彻底的就是面向客户建立全生命周期的产品管理服务体系。早期的共享信息数据(SID)模型就是这样的架构。

  建设中台或任何企业级中心化的系统,需要权衡的就是如何协调不同使用部门之间的利益点。比如说,某些部门不希望花费过多精力在系统建设上,那么组织提供的共享资源就很有用处;而某些部门希望能够快速响应经常变化、个性化的需求,那么组织级平台就可能拖累他们的节奏;而还有一些部门根本就不想与其它系统有依赖,那这样的共享服务对他们而言就没有存在的必要。

  中台并不神秘,当企业想建设中台时,先应当考虑的是,业务部门的需求究竟是什么,他们希望改进什么方面?他们及涉及的利益相关者愿意为这个改进作出多大业务上的对齐?谁能够承担企业架构师的角色?很多架构师其实只是一个高级程序员,并不具备权衡(Tradeoffs)的能力和魄力。否则,这不应该成为中台项目,更好的处理模式是在解决方案或应用层面寻找优化措施。

  早期的Connected Services Framework,在许多国外大型机构中演进成为Shared Services架构。

  2、为什么你无法复制中台?

  阿里巴巴业务本身就是平台型、开放型,但仅仅因为业务形态,也不足说明非平台型公司不能建中台,毕竟建成后效率更高啊。但企业需要意识到,阿里巴巴成功建设中台,原因有两点:,是对现有资源的整合而不是新建;第二,由内部团队驱动而不是外部公司承接。

  可重用的资源

  中台普遍采用服务、API来集成提供业务能力,许多企业步就是欠缺的,没有这些服务和API;通常我们说的“服务化”,意思是把现有的组件封装为Web Service,以提供更强的复用能力,比如说,一个Java的组件,只有Java的程序能调用,但封装为服务之后,PHP/Node.js/iOS/Android全都可以支持了,就极大地提升了后端程序的复用性。

  但事实上去到企业一看,很多系统连组件边界都不清晰,这个服务化,其实在帮助企业进行应用架构(Application Architecture)层面的模块化梳理。许多企业连模块化都不想做,就要一步上中台,怎么办,请外部公司空降PPT画大饼、做培训、仓促上马半成品,结果可想而知。

  运行维护和保障:你有工程能力来建设中台吗?

  比如简单的一个问题,中台上一个服务有多个消费者,如何进行版本升级?内部组件如何做到灰度部署?如何回滚?事实是,关于服务要不要有版本编号,版本编号到底是不是一个值得采纳的工程实践,业界都还在踩坑、争论。运转中的中台,复杂度超过一般的系统运行维护,没有规范、没有自动化、没有云平台管理能力的企业,很难玩转中台。即使空降一个中台系统,落后的管理方式也只能将高铁按照大巴时刻发车。

  3、如何稳步走向服务化战略

  茅台这张PPT问题在哪里?在于没有给出路径。

  与“中台”这个名词相比,我们还是更喜欢使用面向服务的战略来表述以用户为中心的未来IT架构转变。

  用户驱动 显性化中台业务价值

  更个性化、更快地响应终用户的请求,尤其是外部用户的请求,应该是中台构建的业务价值目标。如果中台仅仅是优化内部业务,由于业务价值不明确,或难于衡量,将可能导致不及预期、难于协调一致多个部门,所以由外部用户感知的业务价值驱动,更能有效地落地业务资源与流程的整合。

  比如说,利用用户旅程分析工具,将过去用户需要面对多个业务人员的流程优化为一项自助式服务,并支持在移动端、PC端和终端多处完成。定义用户服务请求的监控指标改进,包括业务处理时间、业务流量、交易量,等,即决定了此项优化的业务价值。

  团队自治 构建高效面向业务服务的基层文化

  如果你的团队并不能真正理解服务化/中台的好处,如此庞大的工程不可能真正落地。因为中心化的系统建设涉及的范围太广了,一条规范不能被正确执行,都会留下后期调用的隐患。

  让过去涉及到多个业务协作的系统团队进行合作,设计出新的解决方案,让他们直接面向业务部门收集的反馈,或用户使用的行为指标、报告作出响应。

  如果发现在这个团队中,他们依然还需要依赖第三方的人、系统来解决问题,那么自治式还不够好,需要进一步解除依赖。虽然这在许多金融机构听起来不太可能,但如果这些问题都解决不了,谁又能真正承诺终交付的中台服务能够高效响应呢?

  服务管理 一步步加强中心团队治理能力

  随着服务越来越多,需要有专门的服务管理团队,接手服务基础设施、目录,并完善监控和运营治理。可以为服务管理团队设立服务规划部门,一步一步为企业的服务化/中台战略进行未来状态的导引。

  总结

  中台不是一个新事物,也并不神秘。重视中台,说明中国的企业开始意识到企业架构带来的巨大能效优势,供我们制定更加合理的转型提速节奏。

编辑:Arno

在线咨询

在线咨询

手机扫码分享

关注微信公众号

返回顶部