架构未来：企业新质生产力战略与业务架构实战

数字化转型并非单纯的技术问题、数据问题，是企业整体经营行为、管理理念的转型，更是企业中每一个人的转型。从业者只有具备全局性结构化思维，才能充分思考如何实现业务数字化、数字业务化，只有理解结构化思维才能具备理解数字化的基本能力。

业务架构师对企业而言既是必须培养又是只能自己培养的核心人才，也是新质生产力中的关键一环。员工工要先学会采用结构化的方式定义问题、分析问题、解决问题，才能将业务想法融入数字化解决方案，通过形成数字化解决方案，使新质生产力在企业落地。

业务架构正是以全局性结构化视角分析、梳理企业业务，设计业务数字化方案，提升业务人员与技术人员沟通效率，促进全面、深度业技融合的关键性工具，只有把这种工具能力发挥到极致，数字企业才能用好新质生产力。

20余年行业经验本土化架构方法论布道者倾心撰写，阐述了新质生产力战略下，业务架构的基本概念和核心原则，讲解了如何通过业务架构技术识别和分析企业的业务需求、优化业务流程、提升决策效率，并构建与之相适应的组织结构和信息系统。同时深入探讨了数据架构、应用架构和技术架构与业务架构的协同作用，以及如何通过这些架构的整合来推动新质生产力的形成，并通过一系列成功案例，展示了不同行业、不同规模的企业如何通过业务架构技术实现转型升级，提升核心竞争力。

付晓岩
北京天润聚粮咨询服务有限公司创始人。国有大行原“新一代核心系统转型工程”企业级业务架构师(参加核心工程实践时间长达6年)，IBM原金融核心锐变团队企业架构交付总监(Band10级);阿里云原新金融事业部资深行业解决方案总监(P9级)，拥有20年国有银行工作经验，其中业务条线工作经验12年，1T条线工作经验8年;业技复合型人才，具备跨企业、跨行业企业架构实施、咨询经验，企业架构工作经验超过12年;曾在央行数字人民币项目中担任业务架构师。中国信息通信研究院企业架构推进中心、组装式推进中心技术专家，《基于云计算的企业架构成熟度模型》系列标准起草组专家。中国计算机学会软件工程专业委员会委员，数字金融分会首批执行委员。中国金融分布式账本行业标准起草组成员。国内中文业务架构专著《企业级业务架构设计:方法论与实践》及《银行数字化转型》《聚合架构:面向数字生态的构件化企业架构》作者。

序言
第一篇 初识业务架构
第一章 一个业务架构师的经历
第二章 业务架构方法论与新质生产力

第二篇 业务架构设计方法与实践
第三章 业务架构设计的一般过程与主要内容
第四章 业务架构设计之战略分析
第五章 业务架构设计之组织分析
第六章 业务架构设计之流程分析
第七章 业务架构设计之数据分析
第八章 业务架构设计之业务组（构）件分析
第九章 业务架构设计之产品化分析
第十章 从业务架构设计过渡到实施阶段
第十一章 从业务架构设计到应用设计
第十二章 架构原则与元模型
第十三章 业务架构工程项目常见成败因素
第十四章 本篇回顾

第三篇 业务架构师的工作
第十五章 关于业务架构师工作模式的讨论
第十六章 精进：方法论实施的创新案例
第十七章 探索：以架构思维设计组织形态
跋

序言·
PREFACE
业务架构方法论是新质生产力吗？
一提到新质生产力，大家通常会联想到各类颠覆性技术，比如人工智能、量子计算、核聚变等，但是新质生产力包含的内容绝不仅是颠覆性技术，按照对新质生产力的标准解释，劳动者、劳动资料、劳动对象及其优化组合都属于新质生产力的基本内涵。由此，方法论也是新质生产力，尤其是以优化和组合为研究对象的方法论，这就是本书介绍的内容，以业务架构为核心的方法论。
业务架构简单而言，就是业务的结构，但与通常涉及业务结构设计的各类战略分析、组织分析及流程分析方法论不同的是，它对全局性、结构化的要求更高，对数字化的指向性更强，处于业务和技术之间思维衔接、设计衔接的关键位置。它既不是单纯的业务分析方法，也不是单纯的技术分析方法，我们不能仅以其中一边的视角去看待它，而是要站在真正能够兼容二者的角度来理解它。
业务架构方法论大约诞生于21世纪初期，其通常作为企业架构方法论的一部分。企业架构方法论诞生于20世纪80年代末期，Zachman框架是公认的首个企业架构方法论，其中包含对企业业务进行澄清的内容和诉求，但是直到21世纪初，业务架构方法论才算正式在企业架构方法论中占有一席之地。企业架构方法论原本指如何在企业内部进行合理的系统分析与设计，也就是如何确定在一个企业内做多少系统及系统之间的关系，这一原始愿望一直延续到了之后诞生的各类企业架构方法论中。不过，随着持续研究与实践，以及对康威定律这类指导系统实践的经验性理论及其作用的认知不断深化，业务架构对于企业级系统格局的影响愈发得到公认，其体现在影响力最大的企业架构方法论——TOGAF（The Open Group Architecture Framework，开放组体系结构框架）中业务架构的出现及地位的持续上升。在TOGAF中，业务架构元模型的占比不仅是四个架构分支（业务架构、数据架构、应用架构和技术架构，即常见的“4A架构”）中最大的，而且大到几乎不成比例。
业务架构方法论的诞生和发展是非常符合逻辑的，毕竟，企业开发、购置业务系统是为了满足其业务发展的要求，那么，以业务架构为指导进行业务系统的企业级规划、演进就是合情合理的。并且，通过结构化的方式对业务加以澄清，才能把业务目标、业务流程、业务规则、业务数据、业务经验转化为可以纳入数字化系统加以实现的业务需求；通过全局性、结构化的方法，才能对众多的业务需求进行合理分析、整合、排序，从源头上开始建立“清澈”的开发工作流，让业务信息更好地流动到技术开发中。正因如此，如果说企业架构领域有所谓的“第一性原理”的话，笔者认为，“架构间融合一致”一定会是其中的一条。因为离开了各架构间的一致性，信息就很难通过架构传导，企业的整体概念一致性也几乎无法达成，企业架构方法论宣传的很多价值点也就无法实现了，而“架构间融合一致”正是从业务架构及其各组成部分的融合一致开始的。
数字时代的企业终将是业务结构与技术结构高度对称的知识型企业，只有这样，业务变动才能以最高效率传递到技术实现上，结构的对称将最大限度地降低沟通成本。这是企业在开发模式上需要关注的问题，也就是通常讲的“业技融合问题”。业务诉求是否能够很快地解释给技术人员，是否能够高效地定位需求、快速地分析影响范围、确定合适的解决方案、尽可能地应用企业已有能力等，这些问题都需要通过一定的“结构”进行讨论、分析和确定，就像在地图上找路一样，没有一张共同的地图，业务和技术双方各自“心目”中的位置可能会相差甚远，对问题的定位可能就会失之毫厘，差之千里。虽然一致的理解非常重要，但是很多方法论依旧在研究如何说好业务、技术各自的“方言”，而非建立真正的共同语言，过于强调技术鸿沟，偏重各自的习惯，没有相向而行。
如果业务侧和技术侧的“结构”偏差过大，那么，信息需要进行的分析、转换、确认量就会更多，沟通效率会降低，差错概率会增大，导致业技融合变难，所以，对“结构”的沟通问题才是思考业技融合发展路径时最应该关注和解决的问题。业务侧要有一个业务结构，技术侧也要有一个技术结构，但是二者在总体上应该是技术结构继承和支持业务结构，二者需要具有内在逻辑的一致性，而不是需要大量转换才能对应上的两个结构，高效的数字企业应该是对称结构。未来基于人工智能的智慧型企业，也应当是这样的结构，毕竟，当人工智能可以自己作为工程师直接实施代码开发时，其对业务部门的支持与今天靠软件工程师支持的开发逻辑并无本质不同，人工智能也不可能脱离企业的业务目标进行系统开发。
此外，在数据要素大行其道的时代，如果企业希望实现从经验驱动转向数据驱动，就必须在二者之间搭建一个桥梁，也就是知识，只有按照“经验—知识—数据”的建设逻辑，总结知识并沉淀到系统中，才能通过知识发挥数据的驱动作用，发挥数字经济“X”的效应，而知识的总结需要结构化的方法，知识的管理需要全局性的视角，这正是以全局性结构化思维为底色的业务架构方法论的强项。
经过工业时代的长期发展，人们懂得了不能用“种地”的套路去管理工厂，而应该用机械化的方式重新思考“种地”。但是，数字化的发展还没有真正在企业中引发类似的思考，究其原因，应该是企业还没能用数字化的视角重新看待企业的知识和以知识为基础的业务能力。
业务架构方法论以对业务能力的研究为核心，揭示了业务和技术在关注业务能力这一点上的内在同质性。基于内在同质性可以建立高效的表达、沟通方式，这种内在同质性也是企业管理学进行数字升级的过程中需要思考的关键问题，是传统管理学匹配数字企业的关键点。营销领域在21世纪最大变化就是完成了对4C理论的数字升级，企业管理也该深入思考自己的升级逻辑了。从18世纪末延伸至今的企业管理学需要真正步入数字企业时代，在此过程中，国内企业管理实践领域需要弥补“重实操、轻理论”的不足，方法论是新质生产力，而且是企业更容易把握住、更容易实时更新的新质生产力。
面向新质生产力，深入研究业务能力是非常重要的。在对业务能力研究不够深入的情况下，软件实现速度越快，软件业务含金量就会越低，速度与价值会成反比。由此延伸，一定条件下，架构能力与系统数量也会成反比，对此在企业数字化进程中我们要充分关注。“快”并不总是“好”，没有不以实力为基础的“快”，而实力的增强需要时间，“等不了”不该成为项目失败的理由，更不该成为数字化转型效果不理想的元凶。
以笔者自身的观察，极少见到企业达到了所谓“过度设计”的程度，“设计不足”才是更普遍的现象。“过度设计”一词被过度使用了，战略规划、设计文档、开发文档不会因为对“过度”一词的追捧就成为无用之物、可以无限“减重”之物。在使用“过度设计”一词之前，使用者应当首先扪心自问，是否所追求的目标、愿景是过度的，如果是，“减重”的对象应当是“目标”“愿景”，如果这些不是过度的，为何对它们的深入思考会是过度的？如果因为考虑欠妥，导致合理的目标、愿景失败，不是更过分吗？在笔者看来，好项目和坏项目最大的共同点就是时间消耗速度是一样的，最大的区别可能是在相同的时间消耗中，是否让企业过度提升了自己的能力。
今时今日的业务架构方法论已然非常有实用价值，不再只是理论层面的探讨，而是具有中国特色的实践。国内一批大型企业，以银行业为主，已经深入实施以业务架构为核心的企业架构方法论达十余年，其中不乏持久的超大型工程实践。其他采用该方法论的还包含航空航天、电子制造、消费品等等诸多领域的企业，在国家政策中也有对企业架构方法论价值的肯定和推广要求。企业架构方法论，尤其是其中的业务架构方法论，是在企业中推广系统思维，实现顶层设计、整体转型的良好抓手，业务架构提倡的全局性结构化思维正是系统思维的具体体现，与其他架构类方法论相比，也更容易被大多数业务人员接受。
综上，本书旨在讨论一个世纪之交就已诞生，而且面对未来生产力发展亦不会轻易过时的方法论，其当前的实施案例极具中国特色，是值得在数字时代深入了解、灵活实践的方法论。
本书共十七章，分为三篇。
第一篇为“初识业务架构”，其中，第一章以笔者自身的工作经历为开端，回顾笔者自己与业务架构的初识，帮助读者更快地感受业务架构的工作内容、环境；第二章介绍传统的业务架构方法论、业务架构的价值及演进趋势等。
第二篇为“业务架构设计方法与实践”，涵盖了业务架构设计和应用的各个环节，其中，第三至第九章为业务架构的设计方法，从战略设计一直讲到具体模型的设计过程，以完整的业务架构项目为背景进行充分的方法论介绍；第十至第十二章为业务架构驱动的IT开发过程，包括对架构治理原则和元模型的介绍；第十三章集中讨论基于业务架构的工程项目成败因素；第十四章为本篇回顾，这是由于第二篇内容较多而特意设置的回顾章节。
第三篇为“业务架构师的工作”，其中，第十五章为业务架构师的工作环境、方法论改良、工具设计等内容的介绍；第十六章以笔者最新工作经验为基础，讨论在实施条件不足以支撑完整的业务架构设计时，如何通过逻辑数据实体模型进行快速的业务架构分析与设计；第十七章为对全书理念的总结和扩展。
本书适用人员范围较广，因为笔者认为全局性结构化思维是数字时代的基本思考模式，是数字公民数字素养提升的重要内容，需要全员充分掌握。如果需要细分的话，企业领导者（含技术管理者）、业务侧中层管理者、技术侧中层管理者应该通读本书，以建立对数字企业的深刻认识，笔者认为本书是企业管理者的数字化转型必学书籍。领导层学习架构思维是企业打通业技融合的第一步；业务骨干至少应阅读本书的第一、第二篇以及第三篇的第十五章；需求分析师、产品经理应通读本书；项目管理师、技术侧骨干应阅读本书的第一、第二篇及第三篇的第十五、十六章；业务架构师及有志于成为业务架构师的读者应通读本书。此外，作为一种探究世界、观察世界的方法，很多与本领域直接工作无关的人，也可以尝试了解这种思维模式，也许会触发一些意外的灵感。
本书中涉及对多种架构类方法论的介绍，无论企业架构、业务架构还是业务建模，都涉及多种同类方法论信息，但由于篇幅的限制，无法完全展开介绍，需要读者自行补充相关信息。
在行文次序上，本书改变了之前拙作偏重方法逻辑阐述的特点，以更接近项目实操顺序的方式介绍方法论，因此，部分章节会令读者有“反复”之感，尤其是在介绍业务建模的部分，实际项目通常就是在这种“反复”中推进的，远非“飞流直下”“一气呵成”。笔者对方法论操作的经验、思考也都融入其中，既有给人以鼓励之处，也有打破幻想之处，希望读者在阅读时会有更强的临场感和代入感，引起更多针对实践的思考。
由于叙事视角更接近实操提示与复盘，因此，对有该类工程实践经验的读者而言，可以产生更强的共鸣；对没有该类工程实践经验的读者而言，可以在纵览全局的同时，为未来实践预置更多思考点；对希望改变职业方向的读者而言，可以预先了解业务架构方向的工作难点；对拟开展该类工程的企业而言，可以了解更好的选型思路和招标问题；对提供该类工程服务的供应商而言，可以进行更多对服务改进的思考。
本书的思考充分结合笔者实践，对业务架构方法论的价值也有颇多论述，这些论述并非宣扬它是包治百病的“灵丹妙药”，而恰恰是在说明，作为工具，它更需要基于反思“灵活妙用”。笔者在此领域工作已有十二年左右的时间，算是把“十二生肖”阅过一遍，希望通过此书把所见所闻化作所感，同读者尽可能地分享出来。对于读者而言，业务架构师也许会成为一种非常重要的职业，也许不会一直是一种职业，所以，选择业务架构师这个方向，更像选择了业务架构师的思维方式，选择了业务架构师观察世界的方式。这种方式可以融入更多职业中，也许读者当前的工作、生活，正好需要加入这种方式。
时隔多年之后，笔者能够有勇气再次动笔撰写业务架构图书，实在应当感谢各位读者、客户及众多架构从业者、爱好者的支持！正是各位的热情沟通和反馈，为本书提供了方向。本书的撰写也需要特别感谢电子工业出版社的各位编辑老师，刘少轩老师为本书的出版提供了契机，王欣怡老师担任了本书的责任编辑，张思辰老师为本书提供了人工智能工具应用支持，康旭老师协助整理了本书案例信息。笔者的重要合作伙伴，伙伴云公司为本书采用的零代码架构管理工具提供了平台和技术支持，在此对伙伴云公司CEO袁兆江先生、伙伴云公司副总裁罗国文先生、伙伴学院院长胡楠先生致以诚挚的谢意！架构管理工具在测评期间，得到了中国信息通信研究院的支持与指导，在此对各位负责测评工作的老师致以真诚的谢意！最后，笔者自2023年初独立创业以来，家人的鼓励与支持一直是笔者最温暖的心灵港湾和信心源泉，感谢家人的付出和陪伴。
零代码平台的实现能力已经今非昔比，笔者合作伙伴的产品——“伙伴云”就是一款很灵活的零代码平台，笔者正是基于该平台自研了聚粮数字企业极简管理平台（简称聚粮架构平台），本书中大量的架构制品截图也是通过该平台生成的（这些截图仅为示例，与任何真实项目无关）。该平台已于2024年6月19日，由中国版权保护中心正式授予软件著作权。“聚粮”一词来自《庄子·逍遥游》，“适千里者，三月聚粮”，这也是笔者公司名称中“天润聚粮”的来源，笔者还为此注册了商标。