当前位置:CIO技术探讨 → 正文

Gartner:CIO必须掌握业务中台的设计与开发准则

责任编辑:shjiaz 作者:查士加 |来源:企业网D1Net  2022-04-25 10:35:36 本文摘自:企业网D1Net

组装式应用是Gartner发布的2022年12大重要战略技术趋势之一,它与科学制定实施数字化转型战略、超级自动化和决策智能等趋势并行,均为助力企业、机构塑造变化的重要战略技术趋势。

数字化转型进入加速落地期

近几年,随着数字经济的飞速发展,数字化转型已经不只停留在概念阶段,开始进入加速阶段和实现落地阶段。据统计,2021年中国金融行业在科技领域的整体投入(包括硬件、软件、服务等)超过3000亿人民币,头部股份制城商行的数字化投入比例达到年营业额的3%甚至更高,处于较高水平。

在金融等数字化程度较高的行业,国家颁布的数字化转型指导意见已经越来越具体,开始聚焦架构转型、企业架构设计等关键领域。例如,《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》(银保监办发〔2022〕2号)中第十九条提到:推进传统架构向分布式架构转型,主要业务系统实现平台化、模块化、服务化,逐步形成对分布式架构的自主开发设计和独立升级能力。加快推动企业级业务平台建设,加强企业架构设计,实现共性业务功能的标准化、模块化。加强对开放金融服务接口的统一管理,实现安全可控运行。

Gartner研究副总裁孙志勇博士在《首席信息官秘籍:掌握中台的设计和开发准则》线上研讨会上提到:组装式业务或组装式应用与业务中台有着非常紧密的关联关系,伴随数字化转型进入加速落地期,如果企业尚未在数字化转型方面取得实际效果,那么必须审视企业是否在组装式业务以及架构方面做了充分的工作。以下是企业网D1Net对本次线上研讨会内容的整理报道。

充分认识组装式业务的价值

实际上,很多企业的高层领导对组装式业务或业务中台停留在初期认知阶段,由于他们没有充分认识到业务中台的价值,致使IT管理者很难拿到实际期望中的预算,如果只是小规模尝试,则很难达到深层效果。

因此,IT管理者首先要做的是让企业高管认识到组装式业务(或业务中台)对业务的价值,孙志勇博士强调:组装式业务并非单纯的技术架构问题,而是关乎业务发展和企业战略的关键问题,将帮助企业适应行业的发展潮流,对企业的可持续发展起到至关重要的作用。

那么,什么是组装式业务?

Gartner所指的组装式业务包含三大要素

1. 组装式思维和战略,关键在于共性业务模块的抽取,标准化、模块化以及业务功能的组装。

2. 组装式架构,主要是架构转型,现在的主流趋势是应用架构呼应业务架构,可以提升业务部门对IT价值的认可度。

3. 组装式技术,为实现组装式架构提供相应的技术基础。

组装式思维

过去,大多数企业采用前后台一体化、业财一体化的模式,后台以财务、人力资源、IT等大的部门进行横向支撑,前台对应大的行销部门以及不同的产品组,如今这种架构面临的一个重要问题是:受直播、短视频、流媒体等新模式的不断冲击,传统集中化的模式下后台的支撑能力已经难以及时响应前台快速变化的业务需求,因此越来越多的企业开始考虑将业务层面的共性能力(例如产品、运营、客户、渠道等)抽取出来,实现模块化、组件化,便于在共性能力的基础之上进行业务功能的快速组装,进行业务探索与创新,及时跟上市场的发展节奏。

孙志勇博士强调:CIO做中台,首先要跳出科技圈,站在业务的视角上思考中台能够解决哪些问题,只有抽取出共性模块,才能根据市场的需求快速组装,形成新的业务线和业务基础。例如在汽车制造业,越来越多的车企不再单纯依赖4S店,开始以客户体验为中心,采取多品牌策略,进行沙龙、直销等创新尝试,而共性能力组件是车企能够跟上快速变化的市场节奏的基础。

探索业务中台与组装式业务与之间的关联

从定义来看,业务中台是一种应用架构,可以用来对复用的数字化能力组件进行管理,企业利用业务中台可以加速业务的探索和创新,提升企业的敏捷性和自适应能力。孙志勇博士认为:业务中台应从价值链视角进行设计,从企业运营、产品研发到客户关怀与交互,为从产品转化为业务价值的整个链条进行支撑。

组装式架构的关键在于架构转型,一是业务架构的转型,二是应用架构的转型,与此同时业务架构与应用架构(业务中台)应该建立一种对应关系。企业先要将原有的前后台一体化架构拆分成前、中、后台三层架构,画出业务架构图,中台通过复用标准化、模块化的能力,可以针对前端变化的业务形态进行快速组装。

值得一提的是,那些数字化转型较为领先的企业,都在采用业务架构与应用架构保持高度对齐的做法,通过组件的集成实现业务的组装能力。

组装式业务的四大成效

1、用组装的方式加速创新,并降低风险和难度;

2、推进业务系统实现平台化、模块化以及服务化;

3、实现业务自助式设计与开发;

4、实现业务编排能力,推进数字化生态业务的发展。

当组装式技术达到一定程度,通过低代码、无代码等工具可以推进业务实现自助式设计与开发,一些头部企业已经把诸多业务中台能力封装成标准组件,帮助业务团队快速去进行自助式开发。例如一些手机电商,在底层逻辑实现后,直接由设计团队和营销团队负责拖拉拽操作,科技团队负责代码标准化管控等工作。

借助组装式业务的编排能力,利用业务中台的API组件,促进开放接口的统一管理,能够助力企业推进数字化生态业务的发展。以麦当劳为例,通过向银行开放API接口,可以实现银行的积分兑换,这是促进企业生态发展的重要手段。孙志勇博士强调:“通过这样的编排能力,企业绝大部分应用开发都将依赖于业务中台组件,使整体的开发效率得到大幅提升,能将三个月的开发周期缩短至两周上线,让企业紧抓市场红利期,快速应对业务变化。”

业务中台的设计与拆分原则

业务中台的设计原则是自上而下分别画出业务领域、数字化产品以及API组件三层。

第一层是业务领域,在业务中台设计时要先画出详细的业务域,这一步非常关键,涉及将来的业务中台对应哪些业务场景,这些业务领域可能包括产品、业务、运营、商机开发等等;

第二层是数字化产品,是业务域下实体产品的数字化,包含了一系列有着共性业务功能的API组件;

第三层是API组件,指从业务视角出发所产生的API函数和组件,例如,银行业务中台的支付API、台账API、现金管理和账户服务API,这些都是对业务能力的数据化反应。

业务中、后台的拆分要遵循三条核心原则:一是可复用,二是跨系统的共享,三是聚焦业务逻辑而非业务执行。孙志勇博士认为:中、后台的拆分没有绝对正确的原则,只要适合企业自身即可;业务中台在开始时可以把一些后台功能上浮到中台,颗粒度粗一些也无关紧要。

设置业务中台的开发团队

在设计原则正确的前提下,业务中台后续的开发工作将顺理成章。首先要画出组织架构图,并基于这一架构画出一些粗颗粒度的组件,例如要开发哪些函数,哪些组件,便于衡量整个开发团队的工作量。

业务中台的开发团队要设立三层关系:

最上层是业务域总监(Domain Head),也有部分公司称之为产品总监(Product Director),例如零售快消企业最关注的业务域是运营,运营业务域中包括支付、订单等等产品,而业务域总监负责管理该业务域下的所有产品。

中间一层是产品线,IT部门设产品经理或项目经理,统管所有API的开发工作;业务团队必须有一个Business Owner的角色,孙志勇博士强调这一角色的重要性不容忽视。业务中台的开发并非单纯的科技行为,而应从业务的角度出发,用技术能力或技术架构呼应企业的业务架构,正是基于这样的对应关系,能够在一些新的业务场景进行快速组装。业务侧的Owner将与IT团队的产品经理配合,负责开发、交付、运维及使用相关的API组件,确保项目顺利落地、上线。

最下面一层是产品与API开发团队,负责各个产品相关API组件的开发。通常一个开发团队需要设置三类重要角色:一是开发工程师,二是测试工程师,三是架构师。实际上,API组件开发完成后,背后有很多技术文档,它与后台的关系,以及其在应用场景中实践的诸多记录,这些内容不应由API开发团队或者产品开发团队负责,而是应该交给架构师来运维,架构师这一角色在开发团队中至关重要。

关键字:

本文摘自:企业网D1Net

x Gartner:CIO必须掌握业务中台的设计与开发准则 扫一扫
分享本文到朋友圈
当前位置:CIO技术探讨 → 正文

Gartner:CIO必须掌握业务中台的设计与开发准则

责任编辑:shjiaz 作者:查士加 |来源:企业网D1Net  2022-04-25 10:35:36 本文摘自:企业网D1Net

组装式应用是Gartner发布的2022年12大重要战略技术趋势之一,它与科学制定实施数字化转型战略、超级自动化和决策智能等趋势并行,均为助力企业、机构塑造变化的重要战略技术趋势。

数字化转型进入加速落地期

近几年,随着数字经济的飞速发展,数字化转型已经不只停留在概念阶段,开始进入加速阶段和实现落地阶段。据统计,2021年中国金融行业在科技领域的整体投入(包括硬件、软件、服务等)超过3000亿人民币,头部股份制城商行的数字化投入比例达到年营业额的3%甚至更高,处于较高水平。

在金融等数字化程度较高的行业,国家颁布的数字化转型指导意见已经越来越具体,开始聚焦架构转型、企业架构设计等关键领域。例如,《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》(银保监办发〔2022〕2号)中第十九条提到:推进传统架构向分布式架构转型,主要业务系统实现平台化、模块化、服务化,逐步形成对分布式架构的自主开发设计和独立升级能力。加快推动企业级业务平台建设,加强企业架构设计,实现共性业务功能的标准化、模块化。加强对开放金融服务接口的统一管理,实现安全可控运行。

Gartner研究副总裁孙志勇博士在《首席信息官秘籍:掌握中台的设计和开发准则》线上研讨会上提到:组装式业务或组装式应用与业务中台有着非常紧密的关联关系,伴随数字化转型进入加速落地期,如果企业尚未在数字化转型方面取得实际效果,那么必须审视企业是否在组装式业务以及架构方面做了充分的工作。以下是企业网D1Net对本次线上研讨会内容的整理报道。

充分认识组装式业务的价值

实际上,很多企业的高层领导对组装式业务或业务中台停留在初期认知阶段,由于他们没有充分认识到业务中台的价值,致使IT管理者很难拿到实际期望中的预算,如果只是小规模尝试,则很难达到深层效果。

因此,IT管理者首先要做的是让企业高管认识到组装式业务(或业务中台)对业务的价值,孙志勇博士强调:组装式业务并非单纯的技术架构问题,而是关乎业务发展和企业战略的关键问题,将帮助企业适应行业的发展潮流,对企业的可持续发展起到至关重要的作用。

那么,什么是组装式业务?

Gartner所指的组装式业务包含三大要素

1. 组装式思维和战略,关键在于共性业务模块的抽取,标准化、模块化以及业务功能的组装。

2. 组装式架构,主要是架构转型,现在的主流趋势是应用架构呼应业务架构,可以提升业务部门对IT价值的认可度。

3. 组装式技术,为实现组装式架构提供相应的技术基础。

组装式思维

过去,大多数企业采用前后台一体化、业财一体化的模式,后台以财务、人力资源、IT等大的部门进行横向支撑,前台对应大的行销部门以及不同的产品组,如今这种架构面临的一个重要问题是:受直播、短视频、流媒体等新模式的不断冲击,传统集中化的模式下后台的支撑能力已经难以及时响应前台快速变化的业务需求,因此越来越多的企业开始考虑将业务层面的共性能力(例如产品、运营、客户、渠道等)抽取出来,实现模块化、组件化,便于在共性能力的基础之上进行业务功能的快速组装,进行业务探索与创新,及时跟上市场的发展节奏。

孙志勇博士强调:CIO做中台,首先要跳出科技圈,站在业务的视角上思考中台能够解决哪些问题,只有抽取出共性模块,才能根据市场的需求快速组装,形成新的业务线和业务基础。例如在汽车制造业,越来越多的车企不再单纯依赖4S店,开始以客户体验为中心,采取多品牌策略,进行沙龙、直销等创新尝试,而共性能力组件是车企能够跟上快速变化的市场节奏的基础。

探索业务中台与组装式业务与之间的关联

从定义来看,业务中台是一种应用架构,可以用来对复用的数字化能力组件进行管理,企业利用业务中台可以加速业务的探索和创新,提升企业的敏捷性和自适应能力。孙志勇博士认为:业务中台应从价值链视角进行设计,从企业运营、产品研发到客户关怀与交互,为从产品转化为业务价值的整个链条进行支撑。

组装式架构的关键在于架构转型,一是业务架构的转型,二是应用架构的转型,与此同时业务架构与应用架构(业务中台)应该建立一种对应关系。企业先要将原有的前后台一体化架构拆分成前、中、后台三层架构,画出业务架构图,中台通过复用标准化、模块化的能力,可以针对前端变化的业务形态进行快速组装。

值得一提的是,那些数字化转型较为领先的企业,都在采用业务架构与应用架构保持高度对齐的做法,通过组件的集成实现业务的组装能力。

组装式业务的四大成效

1、用组装的方式加速创新,并降低风险和难度;

2、推进业务系统实现平台化、模块化以及服务化;

3、实现业务自助式设计与开发;

4、实现业务编排能力,推进数字化生态业务的发展。

当组装式技术达到一定程度,通过低代码、无代码等工具可以推进业务实现自助式设计与开发,一些头部企业已经把诸多业务中台能力封装成标准组件,帮助业务团队快速去进行自助式开发。例如一些手机电商,在底层逻辑实现后,直接由设计团队和营销团队负责拖拉拽操作,科技团队负责代码标准化管控等工作。

借助组装式业务的编排能力,利用业务中台的API组件,促进开放接口的统一管理,能够助力企业推进数字化生态业务的发展。以麦当劳为例,通过向银行开放API接口,可以实现银行的积分兑换,这是促进企业生态发展的重要手段。孙志勇博士强调:“通过这样的编排能力,企业绝大部分应用开发都将依赖于业务中台组件,使整体的开发效率得到大幅提升,能将三个月的开发周期缩短至两周上线,让企业紧抓市场红利期,快速应对业务变化。”

业务中台的设计与拆分原则

业务中台的设计原则是自上而下分别画出业务领域、数字化产品以及API组件三层。

第一层是业务领域,在业务中台设计时要先画出详细的业务域,这一步非常关键,涉及将来的业务中台对应哪些业务场景,这些业务领域可能包括产品、业务、运营、商机开发等等;

第二层是数字化产品,是业务域下实体产品的数字化,包含了一系列有着共性业务功能的API组件;

第三层是API组件,指从业务视角出发所产生的API函数和组件,例如,银行业务中台的支付API、台账API、现金管理和账户服务API,这些都是对业务能力的数据化反应。

业务中、后台的拆分要遵循三条核心原则:一是可复用,二是跨系统的共享,三是聚焦业务逻辑而非业务执行。孙志勇博士认为:中、后台的拆分没有绝对正确的原则,只要适合企业自身即可;业务中台在开始时可以把一些后台功能上浮到中台,颗粒度粗一些也无关紧要。

设置业务中台的开发团队

在设计原则正确的前提下,业务中台后续的开发工作将顺理成章。首先要画出组织架构图,并基于这一架构画出一些粗颗粒度的组件,例如要开发哪些函数,哪些组件,便于衡量整个开发团队的工作量。

业务中台的开发团队要设立三层关系:

最上层是业务域总监(Domain Head),也有部分公司称之为产品总监(Product Director),例如零售快消企业最关注的业务域是运营,运营业务域中包括支付、订单等等产品,而业务域总监负责管理该业务域下的所有产品。

中间一层是产品线,IT部门设产品经理或项目经理,统管所有API的开发工作;业务团队必须有一个Business Owner的角色,孙志勇博士强调这一角色的重要性不容忽视。业务中台的开发并非单纯的科技行为,而应从业务的角度出发,用技术能力或技术架构呼应企业的业务架构,正是基于这样的对应关系,能够在一些新的业务场景进行快速组装。业务侧的Owner将与IT团队的产品经理配合,负责开发、交付、运维及使用相关的API组件,确保项目顺利落地、上线。

最下面一层是产品与API开发团队,负责各个产品相关API组件的开发。通常一个开发团队需要设置三类重要角色:一是开发工程师,二是测试工程师,三是架构师。实际上,API组件开发完成后,背后有很多技术文档,它与后台的关系,以及其在应用场景中实践的诸多记录,这些内容不应由API开发团队或者产品开发团队负责,而是应该交给架构师来运维,架构师这一角色在开发团队中至关重要。

关键字:

本文摘自:企业网D1Net

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^