写点什么

企业级业务架构与“中台”的关系

2020 年 3 月 26 日

企业级业务架构与“中台”的关系

随着《企业级业务架构设计:方法论与实践》一书的传播,笔者有了更多的机会与来自不同行业的读者共同讨论业务架构这个话题,业务架构与“中台”的关系也时常会被读者问起,笔者就以这篇短文,将与大家交流的情况做个分享。


经过去年的起起落落,圈内至少对中台达成了一个共识——它仍是一种企业级的软件工程方法,涵盖了一整套解决方案,既包括方法论层面,也包括具体的技术实现方式,当然,前者相对而言不够明晰。对中台方法的探索也在变得更加“宽容”,很多人也认可只要达到了企业级功能复用、一体化这样的核心目标,自家的系统也都可以当做中台的成功实践。


当关于中台的讨论越来越深入,实现方式越来越开放,中台也愈加转回到了大家更熟悉的概念:企业架构。与 Zachman、TOGAF 这样的传统“自上而下”的企业架构理论相比,中台常被认为是一种“自下而上”发展出来的颇具互联网特色的本土架构方法。作为案例背书的阿里巴巴集团的实践,的确体现了互联网公司勇于探索、自我激励、注重敏捷、坚守价值等众多特点,但也正是这样的发展过程,使其整体而言的严谨性与传统理论之间尚有一些差异。


中台常被划分成业务中台、数据中台,之后又出现了技术中台等其他中台定义,在阿里巴巴的实践中,他们很注重业务架构的作用,通过业务架构分析对产品或者功能进行模型化设计,其实这也是一种标准化设计,比如图 1,这是之前演讲中曾经公开的设计思路:



图 1 业务定义可视化


图中的能力模型、配置模型实际上就是对业务的结构化、标准化设计结果,配置数据就是实例化的运行。


通过这种方式,原有的业务能力可以被清晰定义,设计的业务流程可以被很好地结构化,在理想的实现条件下,软件可以被“业务”定义。


这里有一个关键问题,就是能力模型的定义范围,自下而上的实施方式,其对应的合理定义范围应当就是领域级的,这与随着微服务再度升温的 DDD 在思路上是一样的。但是,企业内部对整合、提升的要求并不会在领域级停住,所以,对跨领域的企业级问题的思考是必然的。此外,对于其他想复制中台模式的企业而言,自下而上的生长过程是没有的,尤其是传统企业,他们从一开始就是一个自上而下的转型行为,这其中的不对称就很明显了。如果原有的方法论中,缺少了自上而下的架构设计过程,如何应用中台方法呢?


笔者曾在前文《关于架构演进发展的探讨》中讨论过企业到底是要一个特化的中台还是一个泛化的中台。对于特化的中台,学的越像可能失败概率越高,这就是方法论的魔力,没有对方法论的驾驭能力而单纯追求方法,可能就是这种结果。


当思考到自上而下的架构设计过程时,我们就回到了企业架构的范畴,这些看似笨重的“老方法”一直在整体设计方面勤耕不辍。当面对企业转型这个严肃话题时,我们必须对企业管理和软件工程具备一个最基本的科学的敬畏态度,因为在当今这个时代企业转型正是这两者的结合,而面对未来真正的数字化转型,企业管理则需要充分吸收企业架构的设计思维,完成对自身“技术基因”的“突变”。


中台方法让实践者最为困惑的经常是中台里到底放什么,什么能力需要被沉降到中台,如果没有自下而上的积累过程,那么,自上而下的规划就必须被采用,脱胎于传统理论的企业级业务架构方法论正好可以满足这方面的需求。


企业级业务架构的整体逻辑如图 2 所示:



图 2 企业级业务架构的整体逻辑


这一整体逻辑展示了自上而下的业务分解过程,也体现了自下而上的能力对业务的支持方式,关于企业级架构方法,笔者书中有详细介绍,不在此对方法部分赘述。


企业级业务架构设计在实操层面非常注重标注化问题,如图 3 所示,标准化是设计过程中要遵循的重要原则:



图 3 标准化是企业架构的设计原则之一


标准化是业务能力沉降的基础,在自上而下的设计过程中,这是对企业整体能力的一次深入检视和重构,当然,整合不是一厢情愿,需要科学的态度。


通过企业级业务架构驱动企业级软件工程,我们可以得到落地实践后建立起来的企业能力地图,如图 4 所示:



图 4 企业能力地图


从这张图再演进,相信聪明的读者朋友们就回到了图 1 所示的阿里巴巴集团的设计目标上,殊途同归,不同的是,企业级业务架构方法论给出了一套明确的自上而下的设计过程。这个过程更大的意义在于其对业务侧结构化思维的影响,通过提升业务人员的结构化思维能力,我们可以为软件工程带来更大的效率提升,也能够使业务与技术实现更为深入的融合,软件生产过程和方法论的改善,绝不仅仅是技术侧的问题。


当我们用更加前瞻性的开放式架构思维和开源标准化思路去看待企业软件、企业架构设计时,我们也能推导出支持未来数字化时代所必须具备的、面向全社会而不仅仅是一个企业自身的大规模软件生产方式——基于行业级标准化构件的企业架构设计思路,如图 5 所示:



图 5 基于行业级标准化构件的架构设计


数字化时代,我们的应当更加注重能力的复用,并且是行业级的能力复用,而不是像今天这样动辄从头做一遍,这需要业务侧的思维更结构化,需要技术侧更理解业务,需要企业级业务架构做好中间的桥梁。


综上,笔者认为,企业级业务架构方法论可以为做中台转型的企业提供更好的规划与设计方法,二者并不冲突,任何方法论的发展和学习都是一种兼容并蓄的过程,而不同方法之间的结合也已经成为架构设计发展的一种趋势。除了可以与中台方法结合外,企业级业务架构设计方法因其对业务侧的特殊影响和更广阔的适用范围,可以为软件行业迈向更加成熟的标准化生产方式提供更好的支持与引导,是企业推动数字化转型工作的有力工具。


相关文章:


关于架构演进发展的探讨


架构演进的第四个趋势:行业级标准化


作者介绍


付晓岩,《企业级业务架构设计:方法论与实践》图书作者,原国有大行资深业务架构师,负责业务架构设计、项目管理,热衷新技术探索与实践,具有丰富的银行业务经验和企业级项目业务架构设计经验,曾主导客户关系、金融市场、同业、资管、养老金等多个领域核心系统的业务架构设计,现就职于建信金融科技有限责任公司。即将发行新书《银行数字化转型》,公众号:晓谈岩说。


2020 年 3 月 26 日 18:092257

评论

发布
暂无评论
发现更多内容

6.1分布式关系数据库(上)

张荣召

第2周作业

Steven

极客大学架构师训练营

【架构师训练营第 1 期 06 周】 学习总结

Bear

极客大学架构师训练营

框架设计原则

笨笨程序猿

架构设计 极客大学架构师训练营 接口隔离

1.请简述 CAP 原理。

张荣召

与前端训练营的日子--Week01

SamGo

学习

架构师训练营 - 第六周 - 作业一

行者

第六周总结

_

极客大学架构师训练营 第六周总结

碎碎念

大头虾

Week 2 :框架设计(作业一)

shuyaxx

第二周

宇文青

week2学习总结

幸福小子

架构师训练营第六周命题作业

一马行千里

极客大学架构师训练营 命题作业

架构师训练营第 1 期 - 第 6 周 - 学习总结

wgl

技术选型(2)课后作业

ABS

第六周作业

MULE 无法接收TCP报文问题分析

东风微鸣

APM

第六周总结

第二周作业总结

hunk

极客大学架构师训练营

Week2作业

幸福小子

依赖倒置原则、接口隔离原则优化类的设计

CJian

极客大学架构师训练营

架构师训练营 - 第六周作业

一个节点

极客大学架构师训练营

第六周 技术选型 作业一

应鹏

极客大学架构师训练营

第 5 周 这东西也有标准化答案???

Pyr0man1ac

架构师训练营第 2 期 第二周总结

月下独酌

架构师训练营第二周学习总结

张小胖

极客大学架构师训练营

week6

张兵

极客大学架构师训练营

第六周作业

熊桂平

极客大学架构师训练营

第六周课后总结

天天向上

极客大学架构师训练营

第六周 技术选型 学习总结

应鹏

学习 极客大学架构师训练营

架构师训练营 1 期第 6 周:技术选型(二) - 作业

灵霄

极客大学架构师训练营

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

企业级业务架构与“中台”的关系-InfoQ