《架构师应该知道的37件事》汇集了一名架构师20多年来在全球各大企业任职的经验，共分为5个部分，分别对应在帮助大型企业进行IT转型的过程中，首席架构师必须高效处理的5个方面：企业或IT架构师的角色和能力、架构工作在大型企业中的价值、与各种干系人的沟通、对组织结构和系统的理解、对传统组织进行转型。本书科学而系统地归纳出软件架构师应该具备的完整能力模型，不仅帮助软件开发人员系统地学习如何掌握这37项技能，而且还能让他们进一步理解软件架构师的角色和本质，使他们最终突破技术“天花板”，成为一名合格的软件架构师。
1.美亚五星力作，以故事的方式讲述架构师的内功心法
2.融汇架构高手20余年经验心得，领悟企业信息变革的要义精髓
3.本书科学而系统地归纳出软件架构师应该具备的完整能力模型，不仅帮助软件开发人员系统地学习如何掌握这37项技能，而且还能让他们进一步理解软件架构师的角色和本质
很多大型企业面临着全球快速数字化的压力。“调转船头”，这个经常用来描述转型的短语，已成为很多传统企业董事会上的热议话题。架构师在这样的数字化转型中扮演着非常关键的角色。那么，如何才能成为成功的架构师呢？如果你已经是成功的架构师了，又如何继续获得支持并保持优势呢？
快翻开本书寻找答案吧！本书采用故事集的编排形式，汇集了一名见多识广的出色架构师20多年来在全球各大企业任职的经验，旨在讨论架构师应该如何开拓视野，从而更好地在大型组织中发挥一技之长。全书共分为5个部分，分别对应在帮助大型企业进行IT转型的过程中，架构师必须高效处理的5个方面：
●企业或IT架构师的角色和能力
●架构工作在大型企业中的价值
●与各种干系人的沟通
●对组织结构和系统的理解
●对传统组织进行转型
格雷戈尔·霍培 （Gregor Hohpe）
ArchitectElevator CXO云转型顾问，并为新加坡政府科技局提供技术决策咨询。曾任谷歌（新加坡）技术总监兼CTO、谷歌（日本）高级软件工程师、Allianz公司首席架构师、ThoughtWorks集成架构师。在IT领域有20多年的经验积累，拥有3项美国专利。与人合著《企业集成模式》一书。
【译者简介】
许顺强
资深软件系统架构师、产品负责人。擅长设备协同互联、物联网和云平台等技术领域，精通敏捷软件开发流程，有十多年的跨国项目经验，拥有1项美国专利和4项中国专利。喜欢编写易懂易测、高效优美的软件代码。译有《C#敏捷开发实践》等书。
IT 的50 种形态 1
第 1章 架构师 6
1.1 架构师电梯 9
1.1.1 缺失的一环 9
1.1.2 架构师电梯 9
1.1.3 有些组织的层级比其他组织要多 10
1.1.4 不是单行道 10
1.1.5 高速电梯 11
1.1.6 其他乘客 11
1.1.7 搭乘电梯的危险 12
1.1.8 将大楼扁平化 13
1.2 电影明星架构师 14
1.2.1 黑客帝国——规划大师 14
1.2.2 剪刀手爱德华——园丁 15
1.2.3 粉身碎骨——导游 15
1.2.4 绿野仙踪——魔法师 16
1.2.5 超级英雄还是强力胶 17
1.2.6 做决定 17
1.3 企业架构师与企业里的架构师 18
1.3.1 企业架构 19
1.3.2 业务和IT 是平等的 19
1.3.3 企业里的架构师 20
1.3.4 哪些楼层 20
1.4 架构师用三条腿立足 22
1.4.1 技能、影响力、领导力 22
1.4.2 良性循环 23
1.4.3 重复良性循环 24
1.4.4 要当一辈子架构师吗 25
1.5 决策 26
1.5.1 我们真的那么容易上当吗 27
1.5.2 小数法则 27
1.5.3 偏见 28
1.5.4 启动效应 28
1.5.5 决策分析 29
1.5.6 微亡率 29
1.5.7 模型思维 30
1.5.8 避免决策 31
1.6 刨根问底 32
1.6.1 五问法 32
1.6.2 反复追问才可以揭示出决策和假设 33
1.6.3 处理所有问题的研讨会 33
1.6.4 不存在自由通过 34
第 2章 架构 35
2.1 咖啡店不使用两段式提交法 38
2.1.1 请给我一杯热拿铁 38
2.1.2 关联 39
2.1.3 异常处理 39
2.1.4 事务 40
2.1.5 反向压力 41
2.1.6 会话 41
2.1.7 规范化数据模型 41
2.1.8 欢迎来到现实世界 41
2.2 这是架构吗 42
2.2.1 定义软件架构 42
2.2.2 （建筑）架构决策 43
2.2.3 关键决策无须复杂 45
2.2.4 符合目标 45
2.2.5 通过测试 45
2.3 每个系统都是完美的 46
2.3.1 加热器系统 46
2.3.2 反馈回路 47
2.3.3 有组织的复杂性 47
2.3.4 系统效应 48
2.3.5 理解系统行为 48
2.3.6 影响系统行为 49
2.3.7 系统抗拒改变 50
2.3.8 组织和技术系统 50
2.4 别有代码恐惧症 51
2.4.1 代码恐惧症 51
2.4.2 好的初衷 52
2.4.3 抽象层次 52
2.4.4 简单化与灵活性 52
2.4.5 抽象打包 52
2.4.6 配置 53
2.4.7 代码还是数据 53
2.4.8 运行时与设计时 54
2.4.9 工具化 54
2.4.10 配置化编程 55
2.4.11 配置还有用武之地吗 55
2.5 如果从不杀死任何系统，你就会被“僵尸”包围 56
2.5.1 遗留系统 56
2.5.2 变更恐惧症 57
2.5.3 版本升级 57
2.5.4 运行与变更 58
2.5.5 按计划报废 58
2.5.6 如果疼，就多做几次 59
2.5.7 拥抱变更的文化 59
2.6 平面的IT世界 60
2.6.1 失真的供应商地图 61
2.6.2 在你的地图上标绘产品 61
2.6.3 绘制版图 62
2.6.4 产品理念 63
2.6.5 制图标准 63
2.6.6 版图迁移 64
2.7 永远不要派人去干机器的活 65
2.7.1 让一切自动化 65
2.7.2 这不只和效率相关 65
2.7.3 可重复性能够提振信心 66
2.7.4 自助服务 66
2.7.5 超越自助服务 67
2.7.6 自动化不是单行道 67
2.7.7 显性知识才是好知识 68
2.7.8 人的用武之地 68
2.8 如果软件吞没了整个世界，最好使用版本控制 69
2.8.1 SDX——软件定义一切 69
2.8.2 纺纱工的暴动 70
2.8.3 像软件工程师一样思考 71
2.8.4 使用构建管道 71
2.8.5 质量检验自动化 72
2.8.6 合适的语言 72
2.8.7 软件吞没世界，一次一个修订 73
第3章 沟通 74
3.1 诠释技术主题 77
3.1.1 给高管们的高性能计算架构 77
3.1.2 搭建斜坡，而不是峭壁 77
3.1.3 留意间隙 78
3.1.4 首先，创造一种语言 79
3.1.5 一致的细节层次 79
3.1.6 我本来想要的，但又不敢 80
3.2 写给大忙人 81
3.2.1 写作可以延伸到更多受众 81
3.2.2 质量与影响 82
3.2.3 “在手中”——第 一印象很重要 82
3.2.4 好文章就像电影《怪物史莱克》 83
3.2.5 让读者轻松些 83
3.2.6 写作曲线——线性化 84
3.2.7 简洁明了 85
3.2.8 作家研讨会 86
3.2.9 笔杆子比枪杆子更强大，但仍敌不过企业政治 86
3.3 重点突出胜过面面俱到 87
3.3.1 3 秒测试 87
3.3.2 声明 88
3.3.3 突击测验 88
3.3.4 言简意赅 89
3.3.5 技术备忘录 89
3.4 给孩子们看看海盗船 90
3.4.1 获取关注 90
3.4.2 兴奋 91
3.4.3 聚焦目标 91
3.4.4 展示环境 92
3.4.5 里面的内容 92
3.4.6 考虑受众的身份 92
3.4.7 寓“作”于乐 92
3.5 给银行劫匪画像 94
3.5.1 每个人都看到罪犯 94
3.5.2 刑侦肖像专家 95
3.5.3 系统隐喻 95
3.5.4 视点 96
3.5.5 可视化 96
3.5.6 架构疗法 97
3.5.7 错了！重新做 97
3.6 图驱动设计 98
3.6.1 演示技巧——图 98
3.6.2 绘图技能 99
3.6.3 作为设计技术的绘图 100
3.6.4 没有银弹（点） 101
3.7 绘制连线 102
3.7.1 注意连线 102
3.7.2 元模型 103
3.7.3 语义学的语义 104
3.7.4 元素-关系-行为 104
3.7.5 架构图 105
3.7.6 UML 105
3.7.7 警惕过度应用 106
3.7.8 元素风格 106
第4章 组织 107
4.1 控制只是假象 110
4.1.1 假象 110
4.1.2 控制回路 111
4.1.3 智能控制 111
4.1.4 双行道 111
4.1.5 反馈中的问题 112
4.1.6 普鲁士人并不笨 112
4.1.7 实际控制 113
4.1.8 预警系统 113
4.2 他们不再那样构建了 115
4.2.1 为什么IT 架构师钟爱金字塔 115
4.2.2 组织金字塔 115
4.2.3 没有法老，就没有金字塔 116
4.2.4 建造金字塔 116
4.2.5 生活在金字塔里 117
4.2.6 总能变得更糟 118
4.2.7 构建现代结构 118
4.3 黑市并不有效 119
4.3.1 靠黑市来拯救 119
4.3.2 黑市很少有效 120
4.3.3 你不能把黑市外包出去 120
4.3.4 打击黑市 121
4.3.5 反馈和透明度 121
4.4 扩展组织 123
4.4.1 组件设计——个人生产力 123
4.4.2 避免同步点——会议无法扩展 124
4.4.3 中断打断——电话 124
4.4.4 堆积而不是退避 125
4.4.5 异步通信——电子邮件、聊天，等等 125
4.4.6 提问无法扩展——构建缓存 126
4.4.7 设置不当的域边界——过度对齐 127
4.4.8 自助服务是更好的服务 127
4.4.9 保持人性 128
4.5 缓慢的混乱并不是有序 129
4.5.1 快速与敏捷 130
4.5.2 速度和纪律 130
4.5.3 又快又好 130
4.5.4 缓慢的混乱 131
4.5.5 靠ITIL 来救援吗 132
4.5.6 目标和纪律 32
4.5.7 解决办法 133
4.6 通过盗梦治理 134
4.6.1 制定标准 135
4.6.2 通过行政命令治理 135
4.6.3 通过基础设施治理 136
4.6.4 盗梦 137
4.6.5 皇帝的新衣 137
4.6.6 按照需求治理 138
第5章 转型 139
5.1 没有痛苦，就没有改变 141
5.1.1 转型的各个阶段 141
5.1.2 数字化转型的各个阶段 142
5.1.3 一厢情愿地兜售“万灵油” 142
5.1.4 发动机调优 143
5.1.5 沿途求救 143
5.1.6 不变革的痛苦 144
5.1.7 摆脱困境 144
5.2 引导变革 145
5.2.1 拖拉机超过了赛车 145
5.2.2 设定航向 146
5.2.3 去大陆外冒险 146
5.2.4 破釜沉舟 146
5.2.5 理智之岛 147
5.2.6 臭鼬工程 147
5.2.7 局部最优 148
5.2.8 盲人乡 148
5.3 速度经济 149
5.3.1 旧的规模经济 150
5.3.2 关注流程 151
5.3.3 延迟成本 151
5.3.4 可预测性的价值和成本 152
5.3.5 避免重复的价值和成本 152
5.3.6 如何转变思维模式 153
5.4 无限循环 154
5.4.1 构建-衡量-学习循环 154
5.4.2 数字化转速 155
5.4.3 传统组织的阻碍 55
5.4.4 在外部循环 156
5.4.5 加速反馈 156
5.4.6 保持凝聚力 156
5.5 你不能假装已经数字化 158
5.5.1 奠定基础 158
5.5.2 反馈循环 159
5.5.3 按承诺交付 159
5.5.4 以客户为中心 159
5.5.5 共同打造IT 服务 159
5.5.6 吃自家狗粮 160
5.5.7 数字化思维 160
5.5.8 栈谬论 161
5.6 金钱买不到爱情 163
5.6.1 创新者的窘境 163
5.6.2 留意最高薪人士的意见 164
5.6.3 开销和被容忍的低效率 164
5.6.4 外部依赖 164
5.6.5 付出得越多，可能收获越少 165
5.6.6 文化变革要由内而发 166
5.7 有谁喜欢排队吗 167
5.7.1 留意活动间隙 167
5.7.2 一些排队论知识 168
5.7.3 查找队列 168
5.7.4 插队 169
5.7.5 让队列可见 169
5.8 在四个维度上思考 171
5.8.1 在一条线上生活 171
5.8.2 质量与速度 171
5.8.3 更高的自由度 172
5.8.4 改变曲线的形状 173
5.8.5 反转曲线 173
5.8.6 质量是什么 174
5.8.7 少了一个维度 174
第6章 架构IT转型 175
书单推荐
