具体描述
这是一部从方法论和工程实践双维度阐述企业级业务架构设计的著作。
作者是一位资深的业务架构师，在金融行业工作超过19年，有丰富的大规模复杂金融系统业务架构设计和落地实施经验。本书在出版前邀请了微软、亚马逊、阿里、百度、网易、Dell、Thoughtworks、58、转转等10余家企业的13位在行业内久负盛名的资深架构师和技术专家对本书的内容进行了点评，一致好评推荐。
作者在书中倡导“知行合一”的业务架构思想，全书内容围绕“行线”和“知线”两条主线展开。“行线”涵盖企业级业务架构的战略分析、架构设计、架构落地、长期管理的完整过程，“知线”则重点关注架构方法论的持续改良。
全书分为五个部分：
业务架构基础篇（第1～3章）
介绍了业务架构的发展历程、作用、与IT架构的关系，以及业务模型的相关知识。
业务架构设计篇（第4～7章）
详细讲解了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。
业务架构落地篇（第8～13章）
演示了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，比较了与敏捷开发的异同，集中讨论了企业级项目的实施困难，最后以一个设计实例展示了业务架构设计对提升企业开发效率的作用。
架构方法改良篇（第14～16章）
系统总结了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对之前方法的改良设想，需要读者对此多加思索，切勿生搬硬套。
业务架构与中台篇（第17章）
将业务架构设计方法与当前热点——“中台”模式进行了对比，“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
作者简介
付晓岩
资深的企业级业务架构师，有超过19年的金融行业工作经验，目前就职于建信金融科技有限责任公司。2000年加入建行从事金融业务，2012年调入建行总行成都开发中心，2016年调入建行总行北京开发中心，各中心2018年整体转制，成立建信金融科技有限责任公司。
从事金融业务期间，多次作为核心业务人员参加业务系统开发工作，并就此转入技术开发部门，多年专职从事企业级业务架构设计。
工作期间，认真钻研软件过程、系统设计与分析、架构设计方面的理论知识，将其与实践相结合，不断融合设计思路，逐渐超脱原有工作经历和指导理论的限制，形成对企业级业务架构设计一般方法的认知。
InfoQ中文站专栏作家，发表《中台之上》系列文章，累计阅读量超过10万。维护着个人微信公众号：晓谈岩说，与各行业读者广泛交流，持续提升方法的普适性。
目录信息
前言
第一部分 业务架构基础篇
第1章 业务架构的发展历程2
1.1 Zachman模型2
1.2 TOGAF4
1.3 FEA和DODAF5
1.4 沉吟至今6
1.5 业务架构的定义8
第2章 业务架构的作用及与IT架构的关系10
2.1 业务架构的作用10
2.2 业务架构与IT架构的关系14
第3章 架构伴侣：业务模型18
3.1 模型与业务模型18
3.2 常见的建模方法21
3.3 建模原则与模型思维的应用25
第二部分 业务架构设计篇
第4章 业务架构的设计起点33
4.1 企业战略分析33
4.2 对标分析38
4.3 组织结构的影响不容忽视40
第5章 业务架构的设计过程44
5.1 价值链分析44
5.2 行为分析：业务领域和业务流程46
5.3 数据分析：企业级数据模型49
5.4 组件分析：行为与数据的结合51
5.5 业务架构的整体逻辑关系53
第6章 业务架构的设计难点56
6.1 基本的标准化方法56
6.2 避免“过度整合”59
6.3 何以解忧，唯有“融合”59
第7章 虚拟案例：商业银行业务架构设计61
7.1 价值链设计61
7.2 存款领域的模型设计63
7.3 贷款领域的模型设计65
7.4 跨领域的标准化67
7.5 组件设计70
7.6 案例总结73
第三部分 业务架构落地篇
第8章 从业务架构模型到业务架构方案76
8.1 业务架构设计不是为了替代需求分析76
8.2 制作业务架构方案77
8.3 小团队的应对之道83
8.4 需要充分解释架构方案84
8.5 努力打造“通用语言”85
第9章 基于业务架构方案的实施过程88
9.1 基于业务架构的设计89
9.2 基于业务架构的协调94
9.3 处理架构调整的原则96
9.4 企业级物有所值吗？100
第10章 建立转型后的长期应用机制103
10.1 项目结束了该怎么办？103
10.2 促进深度融合的需求管理机制106
第11章 这个“笨重”的过程与敏捷沾边吗？110
11.1 传说中和现实中的双模开发110
11.2 与正宗的敏捷对比112
11.3 与非正宗的敏捷对比114
11.4 且行且珍惜115
第12章 企业级的“五难” 117
12.1 捷径难寻118
12.2 文化难建119
12.3 预期难控120
12.4 权责难定121
12.5 长志难立123
第13章 实战：实现了快速设计的案例124
13.1 项目背景及需求124
13.2 设计思路和业务架构方案125
13.3 案例总结129
第四部分 架构方法改良篇
第14章 如何支持面向构件的设计132
14.1 “乐高积木”式的软件设计132
14.2 “颗粒度”问题134
14.3 构件模型的设计方式136
14.4 建立构件模型的虚拟案例139
14.5 构件模型的技术设计建议146
14.6 本章小结148
第15章 构建轻量级架构管理工具150
15.1 构件模型的抽象要素及逻辑关系150
15.2 轻量级架构管理工具的设计原理153
15.3 采集项目信息的价值155
15.4 轻量级架构管理工具的优缺点155
15.5 应用轻量级架构管理工具管理新需求156
第16章 基于构件模型谈谈传统企业的产品创新159
16.1 信息传导：打造信息传递高速公路160
16.2 信息分析：创造高维数据162
16.3 创新平台：扩展构件模型165
16.4 构件模型及其应用设想的不足169
第五部分 业务架构与中台篇
第17章 中台之上172
17.1 阿里中台简介172
17.2 企业文化的作用174
17.3 由业务架构方法可以推导出中台设计吗？176
尾声 对实践的再次思考179
附录A 位置、力量、资源183
附录B 积木式创新187
· · · · · · (收起)
读后感
作者写的这本书，什么内容都是浅尝辄止的感觉，全书只看到坐着的一些感受，没看到能真正知道大家做架构的方法。 作者写的这本书，什么内容都是浅尝辄止的感觉，全书只看到坐着的一些感受，没看到能真正知道大家做架构的方法。 作者写的这本书，什么内容都是浅尝辄止的感觉，全...
开源为架构和软件带来了新的成长方式，共享让思维发展得更快、普及得也更快。但是，软件架构本身却只是积累了大量的案例，依旧难以标准化、自动化，哪怕是同一个行业的企业，为这家开发的软件却不能简单移植到另一家，很多商用化了的系统软件也还是离不开各具独特个性的本地化...
2019年中台很火，写了《中台之上》的付晓岩老师出了一本被列入中台系列的书，原本只是讲业务架构设计的，因为中台，估计销量也很好，不知道付老师和华章对这个歪打正着的效果怎么看哈哈。 可能许多人跟我一样，在读《中台之上》的时候满脑子都是“中台”，没有真的理解“之上”...
开源为架构和软件带来了新的成长方式，共享让思维发展得更快、普及得也更快。但是，软件架构本身却只是积累了大量的案例，依旧难以标准化、自动化，哪怕是同一个行业的企业，为这家开发的软件却不能简单移植到另一家，很多商用化了的系统软件也还是离不开各具独特个性的本地化...
2019年中台很火，写了《中台之上》的付晓岩老师出了一本被列入中台系列的书，原本只是讲业务架构设计的，因为中台，估计销量也很好，不知道付老师和华章对这个歪打正着的效果怎么看哈哈。 可能许多人跟我一样，在读《中台之上》的时候满脑子都是“中台”，没有真的理解“之上”...
用户评价
这本书给我的冲击感，主要来自于它对“架构文档”和“沟通机制”的强调。在我的经验里，很多架构项目失败，不是技术能力不行，而是沟通成本太高，架构师和业务方、开发团队之间总是有信息差。这本书花了很大篇幅去讲解如何构建一套清晰、分层、面向不同受众的架构文档体系，如何利用可视化工具来传递复杂的概念，这一点对我这个需要经常跨部门汇报的架构师来说，简直是救命稻草。以前我做的文档，要么是技术人员看不懂，要么是业务人员觉得太枯燥，基本没人看全。这本书里提到的“建筑师手册”概念，强调文档的“可维护性”和“演进性”，而不是一次性的交付物，这个思路太棒了。而且，它对于如何通过架构设计来影响组织结构，也就是“康威定律”的反向应用，讨论得非常深入，让我开始思考，也许我们技术团队的组织方式，也应该围绕未来的业务架构进行调整，而不是一味地去适应现有的僵化部门设置。
读完这本书，我立刻有种“相见恨晚”的感觉，尤其是在阅读关于“服务化转型”和“微服务治理”那几章的时候，简直是醍醐灌顶。我们公司前几年盲目上马了几个大型系统，架构耦合严重，每次需求变更都要牵一发而动全身，简直是开发的地狱。这本书里对于如何自上而下地解构复杂业务体系，如何通过领域驱动设计（DDD）的理念来拆解“巨石应用”，提供了清晰的路线图。我印象特别深的是它对“治理模型”的探讨，它不是简单地告诉你应该用什么技术栈，而是告诉你，在什么样的组织结构和文化背景下，什么样的治理模式是最有效的，这才是企业级架构的精髓所在。作者的文笔非常犀利，逻辑链条环环相扣，没有一句废话。特别是那些案例分析，虽然是虚构的，但其背后的逻辑和遇到的挑战，我闭着眼睛都能联想到我自己的工作场景，这种强烈的共鸣感，是很多学院派著作无法给予的。这本书真正做到了连接理论与实践的桥梁。
这本书简直是为我这种在传统行业里摸爬滚打多年的IT老兵量身定制的“武功秘籍”。我之前在一家大型制造企业做信息化转型，那真是八仙过海，各显神通，每个人都拿着自己那套“宝典”在讲，听得我云里雾里。项目经常卡在需求不清、流程混乱的阶段，不是技术实现不了，而是我们压根不知道该实现个啥。这本书的出现，就像一束强光打进了我这个迷宫。它不是那种空泛的理论说教，而是真的给了一套实实在在的“方法论”。我最欣赏的是它对“业务场景”的梳理和建模，它强迫你跳出纯技术的思维定势，真正去理解业务的痛点和价值点。书里对“架构师”这个角色的定位描述得特别到位，让我们明白，架构师不光是画图的，更是业务的翻译官和战略的执行者。书中提到的那些从顶层设计到落地执行的闭环管理思路，特别实用，尤其是在面对层层汇报、审批缓慢的庞大组织时，如何有效地推动变革，让团队目标保持一致，这些细节的阐述，让我茅塞顿开，觉得之前走的很多弯路都是因为缺少这样一本指引。
我是在一个非常关键的转型期开始阅读这本书的，当时我们正面临着从单体应用向平台化架构迁移的巨大挑战，内部意见分歧很大，有人主张推倒重来，有人则想修修补补了事。这本书的出现，提供了一个强有力的、有理论支撑的中间立场和指导方针。它对于“平台能力”与“业务能力”之间的边界划分，以及如何通过“领域划分”来确定技术团队的划分，具有极高的参考价值。我尤其欣赏作者对“架构愿景”的强调，一个好的架构设计必须有一个清晰、鼓舞人心的愿景，否则，任何技术决策都容易偏离航向。书中对如何将宏大的愿景拆解成可执行的、短期的里程碑，并且确保每一步的交付都能为最终愿景积累价值，这些步骤的描述，详细到让人可以直接套用。这本书不仅仅是工具箱，更像是一份企业的“数字化建设宪法”，指导我们在不确定性中寻找确定性，在复杂性中构建秩序。
这本书的格局非常宏大，它超越了一般技术书籍的范畴，更像是一本关于“企业数字化运营的哲学思考”。它没有停留在画出漂亮的架构图，而是深入探讨了“架构的生命周期”和“价值交付的持续性”。特别是关于“架构治理”的部分，它将治理视为一个动态的、持续优化的过程，而不是一套僵硬的规则集。我特别喜欢它对“架构演进”的描述，它承认复杂系统必然会产生“技术债务”，关键在于如何制定策略去偿还和管理这些债务，而不是一味地追求“一次到位”的完美设计。这种务实、甚至略带悲观的现实主义态度，让我感到非常亲切，因为它符合我这么多年在复杂环境中工作所看到的真实情况。这本书教导我们，架构师首先要学会做“减法”，清晰地定义“非功能性需求”的优先级，并懂得在资源约束下做出最优的“权衡取舍”，而不是一味地堆砌最新的技术名词。
很薄一本小书，企业级领域值得反复阅读。分享的东西多是干活，比TOGAF更接地气。部分地方点到即止，文锋不够犀利，还应该更深入一点。
企业级转型不可能是轻轻松松就能完成的，不少企业只是将企业转型当成一个项目，而忽视了对自身的调整。一个普通士兵要想变成一个特种战士，不是因为给了他一身价值高昂的装备，而是经过了地狱般的训练。上至最高管理者，下至普通员工，若人的思维不发生转变，则不会带来企业的转变。 为了推动企业进行真正的数字化转型，业务架构设计人员永远不要忘记，业务架构最重要的职责不是传递需求，而是藉由自身的努力，推动业务和技术的深度融合，业务架构最重要的职责是起到桥梁连通的作用。如果不能实现这一目标，也就不能真正实现一个快速响应内外部变化的企业级业务系统。
确实讲得比较粗略，不过对于业务架构和应用架构的说法，以及中台和DDD的关系，还是有一些收获的。 说到底，业务架构的核心在于理解业务。不过正如书中所述，DDD放弃了企业级的建模，只专注在领域级，感觉确实是一个比较合适的角度，但即便这样推广也是困难重重。但是要做中台就必须搭建企业级的模型，难度就更加不用说了
书中的图表搭配合理，不会有全是图或者全是字的情况出现，阅读体验挺好的，说明作者应该是个逻辑思维非常强的人。写作的风格也不是很严肃的那种，可以当作枕边书来扩展视野，不会让人觉得非常累脑子，但是却能吸收很多干货
很薄一本小书，企业级领域值得反复阅读。分享的东西多是干活，比TOGAF更接地气。部分地方点到即止，文锋不够犀利，还应该更深入一点。
