谈企业中台能力服务层构建01(5.13)

栏目: 数据库 · 发布时间: 5年前

谈企业中台能力服务层构建01(5.13)

对于企业中台构建,发现我自己原来写的文章进入到一个误区,即对于信息化基础薄弱的企业很难说一开始就按照中台战略来构建其企业整体业务和应用架构,而对于有信息化基础的企业往往又是已有传统IT架构而不可能按照理想的中台构建思路来全新构建。

因此,对于存粹理想的中台和中台服务层构建思路对于大部分企业都不适用。

而真正当前做迫切的需求往往还是在 已经有大量采用传统IT架构进行的信息化系统建设的企业,这些企业往往面临着进一步的IT信息化和传统IT架构转型需求,需要去考虑如何平滑迁移到中台架构模式。

为何需要迁移到中台架构模式,也是我们一直强调的首先是业务需求驱动,其次才是技术驱动。业务驱动表现在很多方面,比如构建一个新的应用的构建周期能否缩短,响应一个需求变更能够更加快捷?或者说我们月末,年底的结账周期,出报表的时间能否缩短?只有真正有明确的业务目标和需求驱动,才可能真正推动企业传统IT架构的转型,而中台构建也仅仅是传统IT架构转型中的一个部分,要实现这种转型往往涉及到PaaS云平台,中台,微服务架构,DevOps等多方面的内容融合。

企业的IT架构如何平滑朝中台架构转移?这个是必须思考的问题,如果所有IT战略规划和架构涉及都是将传统的IT规划和架构推翻,那么显然是行不通的,其本身也会影响到企业当前业务的正常开展。

如何平滑迁移?

实际上在我前面有些文章里面也谈到过, 首先其一是构建企业的技术中台 ,里面涉及到流程,4A,技术服务等各种基础技术服务能力,这个技术能力和业务无关,往往更加容易安装标准构建。

其次就是构建企业的业务中台,但是这个业务中台的构建注意不是我们通常说的业务中台,而更加类似于构建一个业务中台服务能力层。 你可以理解为你传统已经有采购系统,原来的采购系统本身也包括了前端功能,后台逻辑层和数据库,那么我们需要从中间切开一刀,将其关键的数据库能力,逻辑层能力以业务服务接口方式暴露出来并接入和注册到中台服务能力层。

即原来采购系统如何运作还是如何运作,但是当企业构建新的应用的时候,如果涉及到需要使用采购系统的业务能力,那么就只需要和业务中台的能力服务打交道。那么当我们构建的一个新应用涉及到采购,项目管理,财务等多个业务系统的时候呢?这个时候业务中台服务层优势就出来的,新应用也只需要和业务中台服务层打交道即能够完成新应用的构建。即业务中台服务层是企业多个业务系统业务能力的聚合和服务能力开放平台。这不仅仅是数据服务能力的开放,也包括了业务逻辑和业务规则处理能力的开放。

那么业务中台服务层构建是否仅仅是我们常说的集成平台或API服务网关的能力?

注意中台服务层构建不仅仅是服务网关能力,中台服务的提供我们希望是要将原来业务系统核心的业务能力重新抽取出来,因此涉及到要定制开发服务接口来暴露这些业务服务能力,而且最好的方式就是只依赖于原有业务系统的数据库,而对业务系统原来业务逻辑层已有的业务逻辑能力等进行重写。 只有这样才能够真正形成后期完全可以复用的业务能力中台。

同时通过这种方式可以看到,企业会对各个业务系统的开发商依赖越来越小,特别是在远期原有的业务系统很可能完全下层到数据库层或中台逻辑层,其能力全部通过接口服务能力开放,而上层应用基于开放的接口服务能力重新进行构建。这是企业传统IT架构逐渐朝中台架构模式迁移的一个可行方式。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

反应式设计模式

反应式设计模式

Roland Kuhn、Brian Hanafee、Jamie Allen / 何品、邱嘉和、王石冲、林炜翔审校 / 清华大学出版社 / 2019-1-1 / 98.00 元

《反应式设计模式》介绍反应式应用程序设计的原则、模式和经典实践,讲述如何用断路器模式将运行缓慢的组件与其他组件隔开、如何用事务序列(Saga)模式实现多阶段事务以及如何通过分片模式来划分数据集,分析如何保持源代码的可读性以及系统的可测试性(即使在存在许多潜在交互和失败点的情况下)。 主要内容 ? “反应式宣言”指南 ? 流量控制、有界一致性、容错等模式 ? 得之不易的关于“什么行不通”的经验 ? ......一起来看看 《反应式设计模式》 这本书的介绍吧!

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具