中台的灵魂拷问(一)

简介: 中台到底是什么?能帮企业做什么?通过此文得阅读,抛砖引玉,希望可以帮你重新思考中台。

业务中台

什么是业务中台?
●【业务中台】为了避免相同能力(业务功能)重复建设,将通用业务能力进行“抽离”与“沉淀”,形成多个“标准、统一”的能力中心,对前台应用提供服务能力,同时打破了传统的业务支撑模式与组织架构。
●【举例】将原各业务系统“会员”相关的功能进行统一形成“会员中心”,统一实现如会员管理、成长值管理、积分管理等功能,提供给前台各应用使用,直接一方面将打通前台不同类型应用的会员体系,提升用户体验感知;另一方面统一对会员数据管理,保证会员数据一致性与完整性,为会员标签体系(数据变现)提供更加完整的数据支持。

业务中台到底能给企业带来什么好处?(为什么要用业务中台?)
●【去重】:能力复用与数据统一,通用能力沉淀将打破部门壁垒,避免重复建设(降本)
●【做强】:降低试错成本与加速业务创新,赋能前台业务发展(增效)

业务中台和既有的业务应用系统是什么关系?
●【横向替代】:替代原有支撑类业务应用。通过将多个支撑类业务应用的公共能力进行“抽离”与“沉淀”,形成业务中台能力中心,由于部分能力将由能力中心进行统一提供,此时业务中台能力与原有业务应用形成横向替代关系。
●【纵向支撑】:支撑前台业务应用。通过新建业务能力中心,完成中心化业务数据、业务能力的构建(迁移)后,前台业务应用将直接调用业务中台能力中心,完成业务实现。

业务中台和服务化应用的区别是什么?关系是什么?
●【服务化】服务化应用是指某个应用使用“服务”的形式进行构建,并对外提供接入方式,允许其他业务应用调用。服务化并不是中台化,因为并没有对企业的相同服务能力进行沉淀,也没有形成"标准“和”统一“的能力;另外业务中台同时也是一种架构,而服务化则是构建应用的一种手段。
●【关系】服务化应用与业务中台的关系是:业务中台的能力中心也是以服务化的形式进行构建的,所以业务中台的能力中心应用一定是服务化的应用。

业务中台和微服务的关系是什么?
●【微服务】构建复杂应用的一种架构风格,解决的是应用的扩展性、灵活性、故障隔离性等问题。
●【关系】业务中台一般比较庞大且复杂,考虑能力中心将支撑多个前台应用,对性能、扩展性、灵活性等要求,所以业务中台多采用微服务架构去建设各个能力中心,所以能力中心的服务注册、治理也符合微服务架构对服务的管理特性。

如何选择业务中台的第一个试点项目?
●【痛点驱动】选择存在业务痛点、集成关系相对简单(依赖较少)的能力中心作为第一个试点项目。
●【重要性】第一个试点项目直接决定业务中台的未来走向,必须成功,否则将丧失业务中台建设信心,同时第一个试点项目必须符合企业的业务痛点,否则无法做出成绩,即使成功,业务效果不明显,依然容易遭到质疑。

业务中台的业务效果如何体现与量化?
●【量化指标】业务中台首先需要选择业务痛点进行构建,量化指标可对比中台能力中心上线前后的几个方面:1.业务成功率、2.响应时间、3.并发承载量、4.基础资源投入量、5.横向扩展成本、6.功能迭代效率
●【分析对比】收集上线前的数据,对比业务中台能力中心上线后的数据,定期形成运营分析报告,并持续运营。

领域驱动到底能帮我们解决什么问题?
●【建模方法】领域驱动是一种软件设计的建模方法,通过统一的业务语言,打破不同IT工程师的交流壁垒,通过一套行之有效的方法论去“识别”与“构建”服务能力。
●领域驱动的建模方法,是构建业务中台能力中心的一种较好手段。因为领域驱动天然的会将业务进行领域划分与解耦,形成类似能力中心的服务模型,将对能力中心在服务拆分提供较好的指导建议。

没有领域驱动之前是怎么设计系统?
●【数据驱动】自下而上,先画出数据模型,再根据表间关系形成服务,适用于业务复杂度低的系统。
●【领域驱动】自上而下,先根据统一语言画出业务场景,识别业务领域模块与确定交互流程,技术人员更加容易理解业务方向,避免偏离业务目标,适用于业务复杂度高的系统

怎么解决业务中台通用性与前端业务定制化(个性化)的诉求?
●【接口开放】业务中台的能力中心一定是满足通用性的服务能力,同时提供足够的接口,允许前端业务根据额外的接口进行定制自己的业务。
●【自管理】定制化的能力,不可以沉淀在业务中台,定制化产生的数据与服务全部由业务定制方进行自管理存储与对外发布

业务中台的开始研发之前的规范包括哪些?(API、异常、命名?)怎么管理起来?
●【规范】建立一套适用于业务中台的规范,包括研发团队的协同管理、服务的命名规范、代码规范等
●【组件】使用一套适用于业务中台的组件,包括异常捕获组件、日志输出组件、消息组件、缓存组件等

业务中台的建设,必须先通过咨询才能完成建设吗?
●【建议】先寻找有中台建设经验的咨询团队为中台的顶层设计提供支持和经验,可以少走弯路,提升中台项目的成功率。
●【捷径】企业自有研发团队或ISV的,虽然拥有架构和代码能力,但是对业务中台的认识往往不足,容易将中台项目做成传统封闭的单体应用,咨询将把控建设过程,是中台项目成功的捷径。

业务中台建设,到底要投入多少才能看到成效?
●【评估】需要根据企业的IT现状、目标愿景、市场环境、业务诉求等多个方面,综合分析后,才能初步评估投入,一般情况下能力中心越多,成本越高。
●【持续】业务中台建设是个持续的过程,一般建议有限选择业务痛点进行首个中台能力建设,更加容易出成效,之后再进行持续增加新的能力中心,形成业务中台。

个人观点,仅供参考。

目录
相关文章
|
运维 前端开发 搜索推荐
大象转身-平台架构如何拥抱业务创新
如果你正在负责一个超大复杂型平台(比如电商、支付、物流)的架构师,且面临各种技术负债(比如架构复杂性、团队协同复杂性),同时业务又面临从平台服务,到场景化创新的转型。那么这篇文章也许对你有收获。
112309 25
|
定位技术
阿里研究员玄难:如何做电商业务中台
2016 ATF阿里技术论坛于4月15日在清华大学举办,主旨是阐述阿里对世界创新做出的贡献。会上阿里业务平台事业部&淘宝基础平台技术部负责人玄难阐释了淘宝经历13年的发展中,业务平台从零到有,同时又逐步演进为业务中台。
40802 0
|
微服务
为啥都说自己是“数据中台”创业,而不是“业务中台”? by彭文华
为啥都说自己是“数据中台”创业,而不是“业务中台”? by彭文华
为啥都说自己是“数据中台”创业,而不是“业务中台”? by彭文华
|
SQL 存储 Java
数据中台为什么难搞?
数据中台为什么难搞?
67 0
|
存储 数据采集 人工智能
谈谈数据中台建设启示
阿里巴巴的数据中台侧重对“烟囱式”应用数据的标准化和聚合,构建公共数据模型,发掘对内赋能运营和商家的数据价值。
谈谈数据中台建设启示
|
供应链 Cloud Native 搜索推荐
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?(2)
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?
456 0
|
运维 Cloud Native 容灾
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?(4)
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?
501 0
|
运维 Cloud Native 容灾
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?(3)
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?
471 0
|
敏捷开发 运维 Cloud Native
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?(1)
阿里云刘伟光:3.5万字拆解「核心系统转型」,核心从业者怎样寻得「出路」?
681 0
|
人工智能 数据挖掘 双11