架构师应该知道的37件事 下载 pdf 百度网盘 epub 免费 2025 电子书 mobi 在线

本书汇集了一名架构师20多年来在全球各大企业任职的经验，共分为5个部分，分别对应在帮助大型企业进行IT转型的过程中，首席架构师必须高效处理的5个方面：企业或IT架构师的角色和能力、架构工作在大型企业中的价值、与各种干系人的沟通、对组织结构和系统的理解、对传统组织进行转型。本书科学而系统地归纳出软件架构师应该具备的完整能力模型，不仅帮助软件开发人员系统地学习如何掌握这37项技能，而且还能让他们进一步理解软件架构师的角色和本质，使他们最终突破技术“天花板”，成为一名合格的软件架构师。

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

格雷戈尔·霍培 （Gregor Hohpe）

ArchitectElevator CXO云转型顾问，并为新加坡政府科技局提供技术决策咨询。曾任谷歌（新加坡）技术总监兼CTO、谷歌（日本）高级软件工程师、Allianz公司首席架构师、ThoughtWorks集成架构师。在IT领域有20多年的经验积累，拥有3项美国专利。与人合著《企业集成模式》一书。

【译者简介】

许顺强

资深软件系统架构师、产品负责人。擅长设备协同互联、物联网和云平台等技术领域，精通敏捷软件开发流程，有十多年的跨国项目经验，拥有1项美国专利和4项中国专利。喜欢编写易懂易测、高效优美的软件代码。译有《C#敏捷开发实践》等书。

暂无出版社相关信息，正在全力查找中！

暂无相关书籍摘录，正在全力查找中！

在线阅读地址：架构师应该知道的37件事在线阅读

在线听书地址：架构师应该知道的37件事在线收听

在线购买地址：架构师应该知道的37件事在线购买

第1章架构师12。5超级英雄还是强力胶

和魔法师类似，对架构师的另一个期望就是超级英雄：如果你相信某些职位描述，那么企业架构师是这样的：能易如反掌地让公司进入数字时代，能够解决任何技术问题，并且总是对最新技术了如指掌。要达到这些期望很难，所以我要提醒所有架构师，不要对这些常见的误解信以

特尔公司的 Amir Shenhav 1恰当地指出：我们需要的是“强力胶”架构师，而不是超级英雄。“强力胶”架构师既懂得架构，又了解技术细节，还明白业务需求，而且能将大型组织和复项目中的人员团结起来。我喜欢这个比喻，因为它类似于把架构师比作催化剂。只不过，我们必须小心一些：强力胶或者催化剂，意味着你要相当了解要去“黏合”的东西。架构师不单单是个牵线搭桥的角色。

1。2。6做决定

究竟要做哪种类型的架构师呢？除了述架构师类型，还有更多的架构师类型以及可类比的电影角色。你可以像电影《盗梦空间》里那样，通过（危险的）意识潜入来创建架构的理想世界或者像电影《我为玛丽狂》里的两个骗子那样就智利建筑争辩不休；抑或像乌托邦剧《摩天大楼》中的（令人毛骨悚然的） Anthony Royal那样制定规则。总之，你可以选择的架构类型有很多最终，大多数架构师是这些经典形象的结合体，有时是强力胶，有时是园丁，有时又是导游，有时又展现出一种无所不知的高大形象。按照需要扮演不同的角色，就可以成为一个优秀的架构师

当我被聘为企业架构师时一更准确的头衔是企业架构主管（ Head of Enterprise Architecture）我还不太清楚企业架师到底需要承担什么责任。我也想知道，如果我是企业架构的“头（Head），我的团队是不是就应该被称为企业架构的脚，但团队成员并不喜欢这个称谓。现在这种加上“主管”后缀的头衔很流行。下面是我偶然在某个在线论坛看到的对这种现象的恰当解释

这个头衔通常表示候选人本想成为总监、副总裁或者执行官，但是组织不允许再增

加这些岗位的人员数量了。通过授予这种模两可的头衔，在组织外部看来，候选人已

经处于较高的级别，但在组织内部，候选人并没有获得相应的权力配。

我特别不喜欢“某某主管”之类的头，因为它强调的是带领团队，而不是实现具体的职能。我更愿意用一个岗位要达成的目标来命名它，并且要体现出履行该职能需要团队支持。幸运的是我现在是个“首席”，不再是个“主管”了，用一个在政治上不那么正确的比喻来说，当我还是个“主管”时，偶尔会以“打哈哈”的官僚方式和人打招呼

书籍介绍

本书汇集了一名架构师20多年来在全球各大企业任职的经验，共分为5个部分，分别对应在帮助大型企业进行IT转型的过程中，首席架构师必须高效处理的5个方面：企业或IT架构师的角色和能力、架构工作在大型企业中的价值、与各种干系人的沟通、对组织结构和系统的理解、对传统组织进行转型。本书科学而系统地归纳出软件架构师应该具备的完整能力模型，不仅帮助软件开发人员系统地学习如何掌握这37项技能，而且还能让他们进一步理解软件架构师的角色和本质，使他们最终突破技术“天花板”，成为一名合格的软件架构师。