描述
开 本: 32开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787111632801
（1）作者在金融行业有19年工作经验，2000年加入建设银行，几乎经历了建行所有核心系统的业务架构设计，经验丰富。
（2）本书内容得到了国内外绝大多数互联网公司的架构师和技术专家的认可和推荐，比如微软、亚马逊、阿里、百度、网易、滴滴等十几家公司。
（3）本书重思想和方法论，从业务架构“知行合一”的角度阐述业务架构的战略分析、架构设计、架构落地、长期管理，以及架构方法论的持续改良。
这是一部从方法论和工程实践双维度阐述企业级业务架构设计的著作。
作者是一位资深的业务架构师，在金融行业工作超过19年，有丰富的大规模复杂金融系统业务架构设计和落地实施经验。本书在出版前邀请了微软、亚马逊、阿里、百度、网易、Dell、Thoughtworks、58、转转等10余家企业的13位在行业内久负盛名的资深架构师和技术专家对本书的内容进行了点评，一致好评推荐。
作者在书中倡导“知行合一”的业务架构思想，全书内容围绕“行线”和“知线”两条主线展开。“行线”涵盖企业级业务架构的战略分析、架构设计、架构落地、长期管理的完整过程，“知线”则重点关注架构方法论的持续改良。
全书分为五个部分：
业务架构基础篇（第1～3章）
介绍了业务架构的发展历程、作用、与IT架构的关系，以及业务模型的相关知识。
业务架构设计篇（第4～7章）
详细讲解了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。
业务架构落地篇（第8～13章）
演示了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，比较了与敏捷开发的异同，集中讨论了企业级项目的实施困难，*后以一个设计实例展示了业务架构设计对提升企业开发效率的作用。
架构方法改良篇（第14～16章）
系统总结了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对之前方法的改良设想，需要读者对此多加思索，切勿生搬硬套。
业务架构与中台篇（第17章）
将业务架构设计方法与当前热点——“中台”模式进行了对比，“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
推荐语
前言
第一部分 业务架构基础篇
第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
企业是否一定要转型呢？有的人说，一些企业没转型，现在也运转得挺好。这个现象有点类似于人类社会，人类社会的发展是不均衡的，既有步入信息社会的发达地区，也有原始朴素、低生产水平的欠发达地区，那这些“欠发达”地区是否需要“转型”呢？这并非是一个要与不要的问题，如果这些地区想要保持原有状态，那么，减少与外界的接触可能是不得不采取的措施，因为接触会带来融合，融合会带来改变。
对于企业而言也是如此，企业无法脱离其生存环境，如果环境发生了改变，那么企业也不得不跟着改变，因为企业是不能靠与外界隔离来生存的。企业转型是必然的，无非是要考虑转型的时机等。在信息时代，转型的方向自然是信息化、数字化，实现业务与技术的深度融合，讨论这类内容的书籍并不少，但是，实践效果却难以让人满意，“众里寻他千百度”，依然不见“灯火阑珊处”。
企业级转型是一个很艰难的过程，它并非一个单纯的技术问题，因为转型涉及企业的方方面面，如果想走通这条路，尤其是对传统企业而言，充分认识自身、寻找适合自身的方法极为重要。笔者多年从事企业级业务架构设计与管控工作，有幸参与了一次历久弥新的企业转型工程，对业务架构在企业级项目和企业转型过程中发挥的作用深有体会，因此，笔者将对业务架构工作的感悟与自身的学习结合起来，超脱原有的工作实践和理论指导，面向可操作的一般方法论写作本书。
本书的主要内容
完整的企业级业务架构实践应当包含两条并行展开的主线，一条为“行线”，一条为“知线”，如图1所示。
“行线”是读者在日常工作中通常会比较关注的，其覆盖了企业级业务架构设计、实现及后期管理的完整过程；而“知线”则常常容易被忽视，尤其是在架构师或其团队之外。架构师有责任和义务持续改进、宣传架构设计方法，推动架构理念在企业以及社会范围内的磨砺、传播，实现架构工作的“知行合一”。出于这种认知，本书在内容方面设计了5个部分，其中，基础篇、设计篇、落地篇介绍了“行线”；改良篇、业务架构与中台篇探讨了“知线”，具体内容如下。
业务架构基础篇（第1～3章）分别介绍了业务架构的发展历程、作用、与IT架构的关系及业务模型的相关知识。
业务架构设计篇（第4～7章）分别介绍了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。
业务架构落地篇（第8～13章）分别介绍了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，并比较了与敏捷开发的异同，集中讨论了企业级项目的实施难度，最后，以一个设计实例展示了业务架构设计对提升企业开发效率的作用。
上述三部分完整介绍了业务架构设计的一般实现方法，并将企业级项目需要注意的问题及痛点融合在论述过程中，以供需要开展相关工作的读者参考。
架构方法改良篇（第14～16章）介绍了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对前文方法的改良设想，需要读者对此多加思索，切勿生搬硬套。
业务架构与中台篇（第17章）是对业务架构设计方法与当前热点—“中台”模式的一个比对。“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
如何阅读本书
本书适用于如下几类读者群体。
企业管理者
管理者决定着企业的发展方向，以下内容都适合其阅读：本书第一部分中对业务架构发展历程和业务架构作用的探讨；第二部分中对企业战略的分析，对标问题的分析和组织问题的阐述；第三部分中对企业级项目实施、实施后管理和企业级难点的集中论述。实施问题虽然涉及项目中一些琐碎的工作，但是这些琐碎工作对项目的成败却有较大的影响，需要管理者在推动转型之前就有充分的认知。目前，很多企业在转型方面遭遇困难，这些企业并非不善于设计“战略”，也并非不精通“业务”，而是不熟悉“架构”，不清楚如何将战略通过架构落实到业务和技术实现中，企业需要具备“架构”能力，而这种能力应该由管理者带头，从业务架构能力开始，自上而下地建立起来。
实施管理者
实施管理者通常为项目总监、各级项目经理、业务经理、技术经理等在项目实施过程中担任具体管理工作的人员。本书的前三部分对企业级业务架构设计及落地的阐述有助于实施管理者将本书的方法论引入其企业级项目工作中。第五部分的对比分析，也有助于各位实施管理者认真思考，寻找适合自身的方法论。第四部分则需要各位深入思考其方法与自身行业的适配性。
技术人员
在实现业务与技术的融合方面，技术人员自然是需要向业务侧多迈出一步。相信很多技术人员对自己到底是在实现“业务人员”的要求，还是在实现“业务”的要求产生过困惑。本书前三部分论述的方法有助于技术人员掌握一种可以与业务人员更好地进行沟通的方式，也能够在项目中，尤其是在企业级项目中，从“业务人员”的众多要求中抽离出“业务”的要求。后两部分则有助于促进技术人员对方法论的深入思考。
业务人员
在实现业务与技术融合方面，业务人员可能会更“痛苦”一些。一般业务人员在进行技术知识方面的学习时往往会更关注垂直领域，比如AI、区块链、大数据等，属于以应用为导向，但是很多人却忽略了对软件构建过程的关注，正是这种忽略导致了在开发中出现大量 “冲突”。本书作为业务架构设计方法论，技术门槛相对较低，有助于业务人员了解如何结构化自己的思维。通过对本书，尤其是前三部分的阅读，辅之对其他软件工程经典著作的一般了解，业务人员足以对软件的设计与实现有一个清晰的理解，使业务人员与软件的交互度更高。
希望成为业务架构师的读者
业务架构师并非一定要技术出身，但是技术实力雄厚的人显然具有基础知识方面的优势。业务出身的业务架构师需要克服更多的技术障碍，本书虽然不能帮助你学习更多垂直领域的技术知识，但却有可能是你成为业务架构师必读的一本书。
资源和勘误
由于笔者的水平有限，书中难免存在一些不准确的描述，恳请读者批评指正。如果读者有更多宝贵的意见，欢迎通过邮箱[email protected]联系笔者，期待读者们的真挚反馈，以在探索业务架构的道路上互勉共进。本书部分资源可在笔者的微信公众号（晓谈岩说）上获得。
致谢
非常感谢InfoQ中文站的编辑杜小芳女士，是她的积极支持促成了本书前身《中台之上》系列文章的连载，也感谢InfoQ中文站的郭蕾老师和Linda老师对笔者的长期支持。
书中既有对业务架构设计理论的清晰介绍，又有大量“接地气”的案例分析。
——陈耿 微软全球黑带技术专家
除了系统的业务架构设计理论外，还有基于大规模企业级项目的业务架构设计方法论。
——孙玄 转转公司首席架构师／技术委员会主席
企业级应用开发中业务架构不可或缺，业内对业务架构的论述很少，本书填补了这一空白。
——曹洪伟 百度DuerOS首席布道师
本书是作者多年业务架构的经验，既有由浅入深的理论讲解，又有贴合实际的案例实践。
——李鑫 天弘基金（余额宝）移动平台技术总监兼首席架构师
从企业战略分析到与IT架构的衔接，从业务模型的打造到架构的管理方法，本书让我茅塞顿开。
——王天庆 马蜂窝基础平台架构师
作者以金融行业的业务架构作为实例，从“行线”和“知线”两个维度系统讲解了业务架构的方方面面。
——茹炳晟 Dell EMC中国研发集团资深架构师
本书提出了业务架构“知行合一”的观点，让读者充分认识到业务架构的重要性，以及应该如何正确地进行业务架构设计。
——张逸 领域驱动设计布道师
作者以“行线”和“知线”为指引，全面介绍了业务架构的设计、落地以及架构的持续改良。
——郑然 百度主任研发架构师
作者分享业务架构设计的原理和落地方法，并阐述了如何通过业务架构推动技术架构和中台体系的建设。
——刘超 网易杭州研究院云计算技术部首席架构师
本书既有业务架构设计的方法论，又有*的架构方法，完整呈现了业务架构的全景图。
——周健 招银云创金融基础云负责人
作者把他在金融领域超过19年的经验和思考娓娓道来，逻辑清晰完整，案例引人思考。
——黄帅 AWS 认证云架构师
如果想要了解业务架构设计，这本书既有体系化方法论，又有*实践，不可多得。
——沈剑 到家集团技术中心负责人&快狗打车CTO
本书从“知行合一”角度讲解了业务架构设计的方法论和工程实践，是作者19年工作经验的总结。
——梁李印 滴滴大数据架构部高级专家工程师
《企业级业务架构设计：方法论与实践》：
对组织结构的梳理，在需求分析过程中也会经常遇到，内容包括部门职能、部门关系、岗位等。就信息收集而言，业务架构设计在操作方面并没有什么特别之处，区别在于，业务架构设计的着眼点是企业级能力规划，希望能够突破壁垒、形成合力。也正是因为这个“初心”，组织结构对业务架构设计的反作用力也是极大的，本节正是想要谈谈这个问题。
提及组织结构对系统设计的作用，很多人都会想起“康威定律”。Melvin Conway于20世纪60年代后期确定的“康威定律”告诉我们，任意一个软件都能反映出制作它的团队的组织结构，这是因为人们会以反映他们组织形式的方式工作。换句话说就是，分散的团队可能采用分散的架构生成系统，集中的团队更有可能采用单体的架构生成系统。
项目团队的组织结构中的优点和缺点都将不可避免地反映在他们制作的系统中。这个规律延伸到需求方身上也一样适用：需求方的组织结构不可避免地会影响到系统的组件结构。俗话所说的“干活儿不由东，累死也无功”，就是对这个问题最直观的解释。
前文曾讲过，做业务模型，有两个原则需要注意，其中之一就是整体性。设计业务架构，我们当然希望能够通盘考虑整个企业，而不要因为部门利益影响组件边界的划分，影响功能设计。做出来的模型，凡是公用的部分，应该照顾到所有利益相关方的需求；凡是已实现的功能都应该对新的需求方开放并支持必要的扩展，这是企业级设计应该追求的目标，但是，实现起来常常困难重重。企业无论大小，一旦系统的设计边界跨越了单个部门的职能范围时，都会出现部门利益问题， 无非是企业规模、文化差异造成的协调难度的差别。
在企业内部，部门利益是部门需求的天然边界，即便要做企业级，各方肯定也是要先说清楚自己的需求，再去考虑别人的需求，“种了别人家的田，荒了自家的地”是绝对不行的。所以，各部门在参与到企业级谈判中时，都是首先要满足自己所在部门的业务诉求。
这就要求，作为业务架构的设计者，拿出来的方案最好是以一种更有效的方式来满足所有相关方的需求，而不是单纯做抽象、归并，要各部门“你让一陇地，他少一棵树”的方式搞折中，这样做实际上就失去了做企业级的核心价值，因为这样的折中既无法保证系统的先进性，也无法保证用户体验，甚至还可能发生退步。部门利益是做企业级的最大障碍，跨越这个障碍是对业务架构师设计能力的最高挑战。当然，客观地说，没有更好的解决方案时，不动也是一种选择，因为，同样接受这个挑战的还有企业文化。
举个例子，银行都有积分系统，近年来各行也都做了综合积分，其实其中的实现难度很大，主要问题不在技术而在业务。理想的综合积分是企业只有一个积分系统，支持所有产品的不同积分规则。对不同的客户群、不同的营销方案可以进行参数化配置，最重要的是，支持以单一积分形式统一用于奖励兑换，而不是想要换个包，还得分别花去信用卡积分、黄金交易积分、基金业务积分，这样客户体验会非常糟糕。
……
评论
还没有评论。