软件架构师的12项修炼：技术技能篇
译者序
前言
致谢
第一部分 项 目 技 能
第1章 合作关系 5
1.1 什么是合作关系 6
1.2 合作关系的关键特征 6
1.3 一致 7
1.3.1 我需要和谁结成合作伙伴 7
1.3.2 找出思想领袖 8
查看完整
前言
致谢
第一部分 项 目 技 能
第1章 合作关系 5
1.1 什么是合作关系 6
1.2 合作关系的关键特征 6
1.3 一致 7
1.3.1 我需要和谁结成合作伙伴 7
1.3.2 找出思想领袖 8
查看完整
Dave Hendricksen，全球三大咨询提供商汤姆森路透集团（Thomson Reuters）公司资深软件架构师，在软件架构方面有非常深的造诣。在公司中，他与新产品开发团队紧密合作，为大规模在线平台（如Westlaw.com）创建新颖的法律产品。Hendricksen曾在卡内基梅隆大学具有影响力的软件工程学院做过题为“在敏捷世界中设计和构建大规模系统”的演讲。
姚军，曾在多家证券公司担任IT经理，在软硬件项目实施、网络管理及应用领域有15年以上的工作经验，自2006年以来已有多部译作出版。
姚军，曾在多家证券公司担任IT经理，在软硬件项目实施、网络管理及应用领域有15年以上的工作经验，自2006年以来已有多部译作出版。
《软件架构师的12项修炼：技术技能篇》是资深架构师DaveHendricksen的力作，系统阐述了成功架构师的必备技术技能，以及个人及团队拓展、应用这些技能的方法。本书分为3个部分，一部分（第1~5章）介绍项目技能，涵盖合作关系、发现、概念化、估算、管理；第二部分（第6~9章）介绍技术技能，涵盖平台开发、架构透视、治理和技术诀窍；第三部分（第10~12章）介绍想象力技能，涵盖技术创新、战略路线图和企业执行。
译者序
前言
致谢
第一部分 项 目 技 能
第1章 合作关系 5
1.1 什么是合作关系 6
1.2 合作关系的关键特征 6
1.3 一致 7
1.3.1 我需要和谁结成合作伙伴 7
1.3.2 找出思想领袖 8
1.3.3 认识影响力人物 8
1.3.4 确定可信的建议者 9
1.3.5 社区评审（架构评审委员会） 9
1.3.6 在做出关键决策之前寻求一致 9
1.3.7 共同愿景的一致成就合作关系 10
1.4 信任 10
1.4.1 建立信任 10
1.4.2 建立公开披露机制 10
1.4.3 避免将摊子铺得过大（过度投入） 11
1.4.4 在你过度承诺之后如何解脱 12
1.4.5 学会说“不” 12
1.4.6 信任带来透明度—合作关系的命脉 13
1.5 语境 14
1.5.1 了解合作的性质 14
1.5.2 了解你的业务背景（语境） 14
1.5.3 技术决策需要合作关系 14
1.5.4 关键点：技术决策是政治决策 15
1.5.5 首先介绍情况（提供语境） 15
1.5.6 支持你的合作伙伴 16
1.5.7 为合作伙伴的成功做出贡献 17
1.5.8 人多势众 17
1.6 协作 17
1.6.1 将价值放到台面上 17
1.6.2 成为导师 17
1.6.3 寻找导师 18
1.6.4 合作关系可能是机遇之源 19
1.6.5 合作关系是迈向构思的一步 19
1.6.6 协作推动更强大的合作关系 19
1.7 关系 19
1.7.1 合作关系不仅和业务有关 19
1.7.2 想要索取就要先付出 20
1.7.3 外部合作关系 20
1.7.4 过去的不愉快经历 20
1.7.5 躲开组织中的刻薄鬼 20
1.8 小结 21
参考书目 22
第2章 发现 23
2.1 什么是发现 24
2.2 发现的关键 25
2.3 了解客户 25
2.3.1 与销售、市场及新产品开发部门建立合作关系 26
2.3.2 与客户会面 29
2.3.3 取悦客户的是什么 33
2.4 了解市场 34
2.4.1 了解客户的客户 35
2.4.2 客户愿意在哪里花钱 36
2.4.3 竞争对手在做什么 37
2.4.4 倾听不同客户的主题 38
2.5 理解你的业务 39
2.5.1 研究你的业务目标 39
2.5.2 个性化公司的战略目标 39
2.5.3 为决策开发一个业务语境 40
2.6 小结 40
参考书目 41
第3章 概念化 42
3.1 构思 43
3.2 及早介入 43
3.3 概念化：将生命赋予思路 44
3.4 概念形成 45
3.4.1 他们使用什么语言 45
3.4.2 正在讨论的是什么问题 46
3.4.3 当你较晚进入构思团体中时，需要谨慎投入 48
3.4.4 这个概念是什么样子的 49
3.5 概念具体化 51
3.5.1 最小可行性产品 51
3.5.2 试验的需求 52
3.5.3 建立假设有助于协调愿景 53
3.5.4 确定必不可少的功能和客户角色 53
3.5.5 和客户一起进行概念具体化 54
3.6 概念演化 54
3.6.1 以史为鉴 54
3.6.2 接受多种视角 55
3.6.3 寻求概念完整性 56
3.6.4 发现邻近的机遇 57
3.7 小结 57
参考书目 58
第4章 估算 59
4.1 估算概述 60
4.1.1 估算的目的是什么 61
4.1.2 是否建立了项目语境 61
4.1.3 什么是架构方法 62
4.2 理解估算过程 63
4.2.1 估算管线 63
4.2.2 项目类型 63
4.2.3 项目筹资的其他方式 64
4.2.4 理解业务过程 65
4.3 开发架构方法 66
4.3.1 是合作伙伴关系还是合同关系 66
4.3.2 项目在业务上的依据是什么 66
4.3.3 营销方式是什么 67
4.3.4 是不是重复的估算 67
4.3.5 已经识别了哪些风险？能否缓解 68
4.3.6 是否将构建一个平台 69
4.3.7 是否将更改平台 69
4.3.8 使用何种技术 70
4.3.9 采用何种组织结构 70
4.3.10 是否需要进行外部调查 71
4.3.11 是否找出了可利用的组件 71
4.4 估算策略 72
4.4.1 为未知因素和挑战制订计划 72
4.4.2 务实：不要为了获得项目而屈服 72
4.4.3 严密控制关键因素 73
4.4.4 开发估算反馈循环 73
4.4.5 最大限度地减少组织耦合和内聚 73
4.4.6 随身带着PowerPoint 73
4.4.7 开发检查列表 73
4.4.8 及早获得高管和组织的支持 74
4.5 估算原则 74
4.5.1 确定疑难问题 74
4.5.2 提供选项 74
4.5.3 保持设计决策的开放 74
4.5.4 了解时间表 74
4.5.5 知道你想要的结果 75
4.5.6 避免负面态度 75
4.5.7 寻找说“是”的机会 75
4.5.8 现在就开始讨价还价，不要等到以后 75
4.5.9 不要认输 75
4.5.10 相信你的直觉 75
4.5.11 了解其他人估算过的项目 75
4.5.12 了解业务部门的目标价格 76
4.6 完成估算 76
4.6.1 了解时限 76
4.6.2 谁参与估算 76
4.6.3 理解你的切入点 76
4.6.4 组合所有信息 77
4.6.5 与高管人员接触 77
4.6.6 推销估算 77
4.7 小结 79
参考书目 80
第5章 管理 81
5.1 架构管理定义 82
5.2 架构师负责的领域 83
5.3 坚持追求技术上的卓越 83
5.3.1 确立一个愿景 83
5.3.2 提升技术负债意识，投资合适的解决方案 83
5.3.3 保持技术环境的趣味性 84
5.3.4 找出潜在的专利 84
5.3.5 寻求数据中心和运营部门对你的方向的支持 85
5.3.6 推广解决方案 85
5.3.7 建立战略性解决方案 85
5.3.8 利用现有解决方案 86
5.4 交付项目 86
5.4.1 与项目经理成为合作伙伴 86
5.4.2 无情地消除依赖性 86
5.4.3 管理预期 87
5.4.4 控制开发过程 87
5.4.5 在发生问题时出现 88
5.4.6 了解项目上不透明的因素 88
5.4.7 限制处于领导地位的承包商数量 88
5.4.8 提供技术管理（职责领域） 89
5.4.9 应急管理 89
5.5 解决问题 90
5.5.1 提出难题 90
5.5.2 立即处理问题 90
5.5.3 说“不”，但是要提出选项 90
5.5.4 在决策中努力保持一致 91
5.5.5 学会正面处理问题、摊牌 92
5.5.6 知道在协商中你所愿意接受的 92
5.5.7 勇于对不同意的领域（有礼貌地）提出挑战 92
5.5.8 坚持立场 92
5.5.9 知道哪些不是你的问题 92
5.6 与高管人员成为合作伙伴 93
5.6.1 通过透明度管理风险 93
5.6.2 审核估算 93
5.6.3 限制框图中方框的数量 93
5.6.4 提升技术意识 93
5.6.5 支持老板 94
5.6.6 不要打断高管人员的讲话 94
5.6.7 保持自信 94
5.7 管理你的时间 94
5.7.1 限制投入的项目数量 94
5.7.2 定义自己的角色并坚持 95
5.7.3 确定费时工作的优先级 95
5.7.4 学会在限定的日期和时间做出决策 96
5.7.5 只在你是活跃的参与者时才参加会议 96
5.7.6 了解最后期限 96
5.7.7 委托你信任的人 96
5.7.8 面对面会谈 96
5.8 培养技术人才 97
5.8.1 制定架构导师计划 97
5.8.2 建立技术论坛 97
5.8.3 鼓励技术团队成员参与当地的会议和用户组 98
5.8.4 雇用最好的员工：不只是填补一个职位 98
5.9 提高技能 99
5.9.1 与其他架构师坐在一起 99
5.9.2 每天做一些技术工作 99
5.9.3 专注于令你吃惊的事情 99
5.9.4 成为某个领域的专家 99
5.9.5 寻求能够提高技能的项目 99
5.10 小结 100
参考书目 100
第二部分 技 术 技 能
第6章 平台开发 106
6.1 平台开发定义 107
6.2 平台开发的要素 107
6.3 功能 108
6.3.1 定义目标集 108
6.3.2 定义功能集 108
6.3.3 专注于可利用功能 109
6.3.4 开发强大的概念模型 109
6.3.5 API是“打开王国的钥匙” 109
6.4 生态系统 110
6.4.1 平台用户 110
6.4.2 平台所有权 110
6.4.3 平台管理 115
6.4.4 平台开发 117
6.4.5 认识与平台相关的成本 118
6.4.6 管理平台质量 119
6.4.7 平台集成 119
6.4.8 可伸缩性 120
6.4.9 安全性 120
6.5 指导原则 120
6.5.1 追求超卓的质量 120
6.5.2 追求卓越运营 121
6.5.3 可配置性胜过硬编码 121
6.5.4 追求可利用性 121
6.5.5 追求冗余架构 121
6.5.6 追求线性的伸缩性 121
6.5.7 避免平台缠绕 122
6.5.8 避免平台蔓延 122
6.5.9 持续升级到最新技术 122
6.6 小结 122
参考书目 123
第7章 架构透视 124
7.1 架构透视的定义 125
7.2 架构原则 126
7.2.1 最少意外原则 126
7.2.2 最少知识原则（迪米特法则） 126
7.2.3 最小工作量原则（齐普夫法则） 127
7.2.4 机会成本原则 127
7.2.5 单一职责原则 128
7.2.6 精简原则（奥卡姆剃刀或者KISS） 128
7.2.7 最后责任时刻原则（延迟成本） 129
7.2.8 反馈原则 129
7.3 架构关注点 130
7.3.1 可用性 130
7.3.2 可伸缩性 131
7.3.3 可扩展性 132
7.3.4 可重复性 133
7.3.5 兼容性 133
7.3.6 可持续性 133
7.3.7 安全性、灾难恢复、业务持续性和开源许可证 134
7.3.8 第三方集成 134
7.4 架构沟通 134
7.4.1 领域模型 134
7.4.2 流程图 134
7.4.3 环境图 135
7.4.4 用户界面模型 136
7.4.5 逻辑架构框图 136
7.4.6 执行概况图 137
7.4.7 硬件环境框图 137
7.4.8 风险、假设、问题和相互依赖性（RAID） 138
7.5 整合所有因素 140
7.6 小结 140
参考书目 140
第8章 治理 142
8.1 治理的定义 143
8.2 治理原则 143
8.2.1 避免供应商锁定 143
8.2.2 鼓励开源产品的使用 143
8.2.3 最小化中断成本（实现业务持续性计划和灾难恢复） 145
8.2.4 实现业务部门之间的松散耦合 146
8.2.5 利用公共功能 146
8.2.6 确保监管依从性 147
8.2.7 确保安全性 148
8.2.8 最小特权原则（最小授权原则） 149
8.2.9 寻求统一身份和访问管理 149
8.2.10 寻求数据可移植性（避免数据锁定） 149
8.2.11 寻求集成和自动化 149
8.3 治理的领域 150
8.3.1 估算 150
8.3.2 管理关注点 151
8.3.3 架构 151
8.3.4 设计 152
8.3.5 构建、编码、集成、部署、测试和监控 153
8.4 使用敏捷方法的治理和健康压力 153
8.5 小结 154
参考书目 154
第9章 技术诀窍 155
9.1 技术诀窍的定义 156
9.2 开发诀窍 156
9.2.1 发展与技术诀窍的联系 156
9.2.2 发展技术诀窍的先进性 159
9.2.3 发展技术诀窍的卓越性 161
9.2.4 技术诀窍综合体 167
9.3 技术诀窍驱动的架构 167
9.4 小结 168
参考书目 169
第三部分 想象力技能
第10章 技术创新 174
10.1 技术创新的定义 175
10.2 趋势感知 176
10.2.1 趋势感知的领域 176
10.2.2 应用趋势感知 177
10.3 业务融合 178
10.3.1 注意客户咨询中的趋势 178
10.3.2 获得客户反馈 178
10.3.3 分析客户反馈 179
10.3.4 何时要对趋势保持警惕 179
10.3.5 何时接受趋势 180
10.4 战略性研究 180
10.5 技术创新原则 181
10.5.1 寻求得到批准的最少研究时间和资金 182
10.5.2 下小的赌注 182
10.5.3 定期使用技术搜索浏览和跟踪趋势 182
10.5.4 建立实验室区域 183
10.5.5 运用具备用户反馈循环的快速试验 183
10.5.6 向业务部门和客户展示原型 183
10.5.7 在系统边缘上引入新技术 184
10.6 实用技术创新 185
10.7 小结 186
参考书目 186
第11章 战略路线图 187
11.1 战略路线图的定义 188
11.2 战略路线图的要素 188
11.2.1 战略要点 188
11.2.2 时序 189
11.2.3 用“泳道”组织 189
11.2.4 依赖性感知 189
11.2.5 直观表示 189
11.2.6 协作特性 189
11.2.7 代码命名 189
11.2.8 上下文相关（个性化） 190
11.2.9 多学科和专业性 190
11.2.10 优先级排定 190
11.2.11 迭代特性 190
11.2.12 更新 190
11.2.13 发布 190
11.2.14 可计量 190
11.3 路线图制定策略 191
11.3.1 在白板上用即时贴演示路线图 191
11.3.2 从终点开始（反向推导） 191
11.3.3 召开研讨会 191
11.3.4 将战略路线图视为项目 191
11.3.5 捕捉基本指导原则 192
11.4 路线图制定原则 192
11.4.1 保持简单 192
11.4.2 与业务部门合作 192
11.4.3 行动起来 192
11.4.4 寻找乐趣 192
11.4.5 没有目标的战略毫无意义 193
11.4.6 识别需要研究和创新的领域 193
11.4.7 识别技能和知识的不足 193
11.4.8 在实现目标的时间上保持灵活 193
11.4.9 勇于尝试新路径 193
11.4.10 路线图与细节无关，重点是目标和关键里程碑 194
11.4.11 追随能够激励你的方向 194
11.5 架构师在路线图制定中的角色是什么 195
11.6 路线图可能用于哪些地方 195
11.7 路线图考虑因素 195
11.8 路线图社会化 196
11.9 庆祝里程碑的实现 198
11.10 小结 198
参考书目 198
第12章 企业执行 200
12.1 企业执行的定义 201
12.2 企业执行的要素 202
12.2.1 企业精神 202
12.2.2 承受预期风险 203
12.2.3 交付成果 203
12.3 企业执行原则 204
12.3.1 可承受损失原则 204
12.3.2 柠檬水原则 204
12.3.3 拼花布原则 204
12.3.4 一鸟在手原则 204
12.3.5 飞机驾驶员原则 205
12.3.6 把握时机 205
12.3.7 追随爱好 205
12.3.8 学会变通 205
12.3.9 以高成本效益的方式在实践中学习和犯错 207
12.3.10 寻求反馈 207
12.3.11 寻求可利用机会 208
12.4 以企业执行推动架构 209
12.5 小结 209
参考书目 210
结语 组合所有技能 212
^ 收 起
前言
致谢
第一部分 项 目 技 能
第1章 合作关系 5
1.1 什么是合作关系 6
1.2 合作关系的关键特征 6
1.3 一致 7
1.3.1 我需要和谁结成合作伙伴 7
1.3.2 找出思想领袖 8
1.3.3 认识影响力人物 8
1.3.4 确定可信的建议者 9
1.3.5 社区评审（架构评审委员会） 9
1.3.6 在做出关键决策之前寻求一致 9
1.3.7 共同愿景的一致成就合作关系 10
1.4 信任 10
1.4.1 建立信任 10
1.4.2 建立公开披露机制 10
1.4.3 避免将摊子铺得过大（过度投入） 11
1.4.4 在你过度承诺之后如何解脱 12
1.4.5 学会说“不” 12
1.4.6 信任带来透明度—合作关系的命脉 13
1.5 语境 14
1.5.1 了解合作的性质 14
1.5.2 了解你的业务背景（语境） 14
1.5.3 技术决策需要合作关系 14
1.5.4 关键点：技术决策是政治决策 15
1.5.5 首先介绍情况（提供语境） 15
1.5.6 支持你的合作伙伴 16
1.5.7 为合作伙伴的成功做出贡献 17
1.5.8 人多势众 17
1.6 协作 17
1.6.1 将价值放到台面上 17
1.6.2 成为导师 17
1.6.3 寻找导师 18
1.6.4 合作关系可能是机遇之源 19
1.6.5 合作关系是迈向构思的一步 19
1.6.6 协作推动更强大的合作关系 19
1.7 关系 19
1.7.1 合作关系不仅和业务有关 19
1.7.2 想要索取就要先付出 20
1.7.3 外部合作关系 20
1.7.4 过去的不愉快经历 20
1.7.5 躲开组织中的刻薄鬼 20
1.8 小结 21
参考书目 22
第2章 发现 23
2.1 什么是发现 24
2.2 发现的关键 25
2.3 了解客户 25
2.3.1 与销售、市场及新产品开发部门建立合作关系 26
2.3.2 与客户会面 29
2.3.3 取悦客户的是什么 33
2.4 了解市场 34
2.4.1 了解客户的客户 35
2.4.2 客户愿意在哪里花钱 36
2.4.3 竞争对手在做什么 37
2.4.4 倾听不同客户的主题 38
2.5 理解你的业务 39
2.5.1 研究你的业务目标 39
2.5.2 个性化公司的战略目标 39
2.5.3 为决策开发一个业务语境 40
2.6 小结 40
参考书目 41
第3章 概念化 42
3.1 构思 43
3.2 及早介入 43
3.3 概念化：将生命赋予思路 44
3.4 概念形成 45
3.4.1 他们使用什么语言 45
3.4.2 正在讨论的是什么问题 46
3.4.3 当你较晚进入构思团体中时，需要谨慎投入 48
3.4.4 这个概念是什么样子的 49
3.5 概念具体化 51
3.5.1 最小可行性产品 51
3.5.2 试验的需求 52
3.5.3 建立假设有助于协调愿景 53
3.5.4 确定必不可少的功能和客户角色 53
3.5.5 和客户一起进行概念具体化 54
3.6 概念演化 54
3.6.1 以史为鉴 54
3.6.2 接受多种视角 55
3.6.3 寻求概念完整性 56
3.6.4 发现邻近的机遇 57
3.7 小结 57
参考书目 58
第4章 估算 59
4.1 估算概述 60
4.1.1 估算的目的是什么 61
4.1.2 是否建立了项目语境 61
4.1.3 什么是架构方法 62
4.2 理解估算过程 63
4.2.1 估算管线 63
4.2.2 项目类型 63
4.2.3 项目筹资的其他方式 64
4.2.4 理解业务过程 65
4.3 开发架构方法 66
4.3.1 是合作伙伴关系还是合同关系 66
4.3.2 项目在业务上的依据是什么 66
4.3.3 营销方式是什么 67
4.3.4 是不是重复的估算 67
4.3.5 已经识别了哪些风险？能否缓解 68
4.3.6 是否将构建一个平台 69
4.3.7 是否将更改平台 69
4.3.8 使用何种技术 70
4.3.9 采用何种组织结构 70
4.3.10 是否需要进行外部调查 71
4.3.11 是否找出了可利用的组件 71
4.4 估算策略 72
4.4.1 为未知因素和挑战制订计划 72
4.4.2 务实：不要为了获得项目而屈服 72
4.4.3 严密控制关键因素 73
4.4.4 开发估算反馈循环 73
4.4.5 最大限度地减少组织耦合和内聚 73
4.4.6 随身带着PowerPoint 73
4.4.7 开发检查列表 73
4.4.8 及早获得高管和组织的支持 74
4.5 估算原则 74
4.5.1 确定疑难问题 74
4.5.2 提供选项 74
4.5.3 保持设计决策的开放 74
4.5.4 了解时间表 74
4.5.5 知道你想要的结果 75
4.5.6 避免负面态度 75
4.5.7 寻找说“是”的机会 75
4.5.8 现在就开始讨价还价，不要等到以后 75
4.5.9 不要认输 75
4.5.10 相信你的直觉 75
4.5.11 了解其他人估算过的项目 75
4.5.12 了解业务部门的目标价格 76
4.6 完成估算 76
4.6.1 了解时限 76
4.6.2 谁参与估算 76
4.6.3 理解你的切入点 76
4.6.4 组合所有信息 77
4.6.5 与高管人员接触 77
4.6.6 推销估算 77
4.7 小结 79
参考书目 80
第5章 管理 81
5.1 架构管理定义 82
5.2 架构师负责的领域 83
5.3 坚持追求技术上的卓越 83
5.3.1 确立一个愿景 83
5.3.2 提升技术负债意识，投资合适的解决方案 83
5.3.3 保持技术环境的趣味性 84
5.3.4 找出潜在的专利 84
5.3.5 寻求数据中心和运营部门对你的方向的支持 85
5.3.6 推广解决方案 85
5.3.7 建立战略性解决方案 85
5.3.8 利用现有解决方案 86
5.4 交付项目 86
5.4.1 与项目经理成为合作伙伴 86
5.4.2 无情地消除依赖性 86
5.4.3 管理预期 87
5.4.4 控制开发过程 87
5.4.5 在发生问题时出现 88
5.4.6 了解项目上不透明的因素 88
5.4.7 限制处于领导地位的承包商数量 88
5.4.8 提供技术管理（职责领域） 89
5.4.9 应急管理 89
5.5 解决问题 90
5.5.1 提出难题 90
5.5.2 立即处理问题 90
5.5.3 说“不”，但是要提出选项 90
5.5.4 在决策中努力保持一致 91
5.5.5 学会正面处理问题、摊牌 92
5.5.6 知道在协商中你所愿意接受的 92
5.5.7 勇于对不同意的领域（有礼貌地）提出挑战 92
5.5.8 坚持立场 92
5.5.9 知道哪些不是你的问题 92
5.6 与高管人员成为合作伙伴 93
5.6.1 通过透明度管理风险 93
5.6.2 审核估算 93
5.6.3 限制框图中方框的数量 93
5.6.4 提升技术意识 93
5.6.5 支持老板 94
5.6.6 不要打断高管人员的讲话 94
5.6.7 保持自信 94
5.7 管理你的时间 94
5.7.1 限制投入的项目数量 94
5.7.2 定义自己的角色并坚持 95
5.7.3 确定费时工作的优先级 95
5.7.4 学会在限定的日期和时间做出决策 96
5.7.5 只在你是活跃的参与者时才参加会议 96
5.7.6 了解最后期限 96
5.7.7 委托你信任的人 96
5.7.8 面对面会谈 96
5.8 培养技术人才 97
5.8.1 制定架构导师计划 97
5.8.2 建立技术论坛 97
5.8.3 鼓励技术团队成员参与当地的会议和用户组 98
5.8.4 雇用最好的员工：不只是填补一个职位 98
5.9 提高技能 99
5.9.1 与其他架构师坐在一起 99
5.9.2 每天做一些技术工作 99
5.9.3 专注于令你吃惊的事情 99
5.9.4 成为某个领域的专家 99
5.9.5 寻求能够提高技能的项目 99
5.10 小结 100
参考书目 100
第二部分 技 术 技 能
第6章 平台开发 106
6.1 平台开发定义 107
6.2 平台开发的要素 107
6.3 功能 108
6.3.1 定义目标集 108
6.3.2 定义功能集 108
6.3.3 专注于可利用功能 109
6.3.4 开发强大的概念模型 109
6.3.5 API是“打开王国的钥匙” 109
6.4 生态系统 110
6.4.1 平台用户 110
6.4.2 平台所有权 110
6.4.3 平台管理 115
6.4.4 平台开发 117
6.4.5 认识与平台相关的成本 118
6.4.6 管理平台质量 119
6.4.7 平台集成 119
6.4.8 可伸缩性 120
6.4.9 安全性 120
6.5 指导原则 120
6.5.1 追求超卓的质量 120
6.5.2 追求卓越运营 121
6.5.3 可配置性胜过硬编码 121
6.5.4 追求可利用性 121
6.5.5 追求冗余架构 121
6.5.6 追求线性的伸缩性 121
6.5.7 避免平台缠绕 122
6.5.8 避免平台蔓延 122
6.5.9 持续升级到最新技术 122
6.6 小结 122
参考书目 123
第7章 架构透视 124
7.1 架构透视的定义 125
7.2 架构原则 126
7.2.1 最少意外原则 126
7.2.2 最少知识原则（迪米特法则） 126
7.2.3 最小工作量原则（齐普夫法则） 127
7.2.4 机会成本原则 127
7.2.5 单一职责原则 128
7.2.6 精简原则（奥卡姆剃刀或者KISS） 128
7.2.7 最后责任时刻原则（延迟成本） 129
7.2.8 反馈原则 129
7.3 架构关注点 130
7.3.1 可用性 130
7.3.2 可伸缩性 131
7.3.3 可扩展性 132
7.3.4 可重复性 133
7.3.5 兼容性 133
7.3.6 可持续性 133
7.3.7 安全性、灾难恢复、业务持续性和开源许可证 134
7.3.8 第三方集成 134
7.4 架构沟通 134
7.4.1 领域模型 134
7.4.2 流程图 134
7.4.3 环境图 135
7.4.4 用户界面模型 136
7.4.5 逻辑架构框图 136
7.4.6 执行概况图 137
7.4.7 硬件环境框图 137
7.4.8 风险、假设、问题和相互依赖性（RAID） 138
7.5 整合所有因素 140
7.6 小结 140
参考书目 140
第8章 治理 142
8.1 治理的定义 143
8.2 治理原则 143
8.2.1 避免供应商锁定 143
8.2.2 鼓励开源产品的使用 143
8.2.3 最小化中断成本（实现业务持续性计划和灾难恢复） 145
8.2.4 实现业务部门之间的松散耦合 146
8.2.5 利用公共功能 146
8.2.6 确保监管依从性 147
8.2.7 确保安全性 148
8.2.8 最小特权原则（最小授权原则） 149
8.2.9 寻求统一身份和访问管理 149
8.2.10 寻求数据可移植性（避免数据锁定） 149
8.2.11 寻求集成和自动化 149
8.3 治理的领域 150
8.3.1 估算 150
8.3.2 管理关注点 151
8.3.3 架构 151
8.3.4 设计 152
8.3.5 构建、编码、集成、部署、测试和监控 153
8.4 使用敏捷方法的治理和健康压力 153
8.5 小结 154
参考书目 154
第9章 技术诀窍 155
9.1 技术诀窍的定义 156
9.2 开发诀窍 156
9.2.1 发展与技术诀窍的联系 156
9.2.2 发展技术诀窍的先进性 159
9.2.3 发展技术诀窍的卓越性 161
9.2.4 技术诀窍综合体 167
9.3 技术诀窍驱动的架构 167
9.4 小结 168
参考书目 169
第三部分 想象力技能
第10章 技术创新 174
10.1 技术创新的定义 175
10.2 趋势感知 176
10.2.1 趋势感知的领域 176
10.2.2 应用趋势感知 177
10.3 业务融合 178
10.3.1 注意客户咨询中的趋势 178
10.3.2 获得客户反馈 178
10.3.3 分析客户反馈 179
10.3.4 何时要对趋势保持警惕 179
10.3.5 何时接受趋势 180
10.4 战略性研究 180
10.5 技术创新原则 181
10.5.1 寻求得到批准的最少研究时间和资金 182
10.5.2 下小的赌注 182
10.5.3 定期使用技术搜索浏览和跟踪趋势 182
10.5.4 建立实验室区域 183
10.5.5 运用具备用户反馈循环的快速试验 183
10.5.6 向业务部门和客户展示原型 183
10.5.7 在系统边缘上引入新技术 184
10.6 实用技术创新 185
10.7 小结 186
参考书目 186
第11章 战略路线图 187
11.1 战略路线图的定义 188
11.2 战略路线图的要素 188
11.2.1 战略要点 188
11.2.2 时序 189
11.2.3 用“泳道”组织 189
11.2.4 依赖性感知 189
11.2.5 直观表示 189
11.2.6 协作特性 189
11.2.7 代码命名 189
11.2.8 上下文相关（个性化） 190
11.2.9 多学科和专业性 190
11.2.10 优先级排定 190
11.2.11 迭代特性 190
11.2.12 更新 190
11.2.13 发布 190
11.2.14 可计量 190
11.3 路线图制定策略 191
11.3.1 在白板上用即时贴演示路线图 191
11.3.2 从终点开始（反向推导） 191
11.3.3 召开研讨会 191
11.3.4 将战略路线图视为项目 191
11.3.5 捕捉基本指导原则 192
11.4 路线图制定原则 192
11.4.1 保持简单 192
11.4.2 与业务部门合作 192
11.4.3 行动起来 192
11.4.4 寻找乐趣 192
11.4.5 没有目标的战略毫无意义 193
11.4.6 识别需要研究和创新的领域 193
11.4.7 识别技能和知识的不足 193
11.4.8 在实现目标的时间上保持灵活 193
11.4.9 勇于尝试新路径 193
11.4.10 路线图与细节无关，重点是目标和关键里程碑 194
11.4.11 追随能够激励你的方向 194
11.5 架构师在路线图制定中的角色是什么 195
11.6 路线图可能用于哪些地方 195
11.7 路线图考虑因素 195
11.8 路线图社会化 196
11.9 庆祝里程碑的实现 198
11.10 小结 198
参考书目 198
第12章 企业执行 200
12.1 企业执行的定义 201
12.2 企业执行的要素 202
12.2.1 企业精神 202
12.2.2 承受预期风险 203
12.2.3 交付成果 203
12.3 企业执行原则 204
12.3.1 可承受损失原则 204
12.3.2 柠檬水原则 204
12.3.3 拼花布原则 204
12.3.4 一鸟在手原则 204
12.3.5 飞机驾驶员原则 205
12.3.6 把握时机 205
12.3.7 追随爱好 205
12.3.8 学会变通 205
12.3.9 以高成本效益的方式在实践中学习和犯错 207
12.3.10 寻求反馈 207
12.3.11 寻求可利用机会 208
12.4 以企业执行推动架构 209
12.5 小结 209
参考书目 210
结语 组合所有技能 212
^ 收 起
Dave Hendricksen，全球三大咨询提供商汤姆森路透集团（Thomson Reuters）公司资深软件架构师，在软件架构方面有非常深的造诣。在公司中，他与新产品开发团队紧密合作，为大规模在线平台（如Westlaw.com）创建新颖的法律产品。Hendricksen曾在卡内基梅隆大学具有影响力的软件工程学院做过题为“在敏捷世界中设计和构建大规模系统”的演讲。
姚军，曾在多家证券公司担任IT经理，在软硬件项目实施、网络管理及应用领域有15年以上的工作经验，自2006年以来已有多部译作出版。
姚军，曾在多家证券公司担任IT经理，在软硬件项目实施、网络管理及应用领域有15年以上的工作经验，自2006年以来已有多部译作出版。
《软件架构师的12项修炼：技术技能篇》是资深架构师DaveHendricksen的力作，系统阐述了成功架构师的必备技术技能，以及个人及团队拓展、应用这些技能的方法。本书分为3个部分，一部分（第1~5章）介绍项目技能，涵盖合作关系、发现、概念化、估算、管理；第二部分（第6~9章）介绍技术技能，涵盖平台开发、架构透视、治理和技术诀窍；第三部分（第10~12章）介绍想象力技能，涵盖技术创新、战略路线图和企业执行。
比价列表
