架构师应该知道的37件事

[美] 格雷戈尔·霍培 (Gregor Hohpe)

出版时间

2020-04-30

ISBN

9787115534651

评分

★★★★★
书籍介绍

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

格雷戈尔·霍培 (Gregor Hohpe)

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

【译者简介】

许顺强

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

精彩摘录
  • "第1章架构师12。5超级英雄还是强力胶 和魔法师类似,对架构师的另一个期望就是超级英雄:如果你相信某些职位描述,那么企业架构师是这样的:能易如反掌地让公司进入数字时代,能够解决任何技术问题,并且总是对最新技术了如指掌。要达到这些期望很难,所以我要提醒所有架构师,不要对这些常见的误解信以 特尔公司的 Amir Shenhav 1恰当地指出:我们需要的是“强力胶”架构师,而不是超级英雄。“强力胶”架构师既懂得架构,又了解技术细节,还明白业务需求,而且能将大型组织和复项目中的人员团结起来。我喜欢这个比喻,因为它类似于把架构师比作催化剂。只不过,我们必须小心一些:强力胶或者催化剂,意味着你要相当了解要"
  • "当我被聘为企业架构师时一更准确的头衔是企业架构主管( Head of Enterprise Architecture)我还不太清楚企业架师到底需要承担什么责任。我也想知道,如果我是企业架构的“头(Head),我的团队是不是就应该被称为企业架构的脚,但团队成员并不喜欢这个称谓。现在这种加上“主管”后缀的头衔很流行。下面是我偶然在某个在线论坛看到的对这种现象的恰当解释 这个头衔通常表示候选人本想成为总监、副总裁或者执行官,但是组织不允许再增 加这些岗位的人员数量了。通过授予这种模两可的头衔,在组织外部看来,候选人已 经处于较高的级别,但在组织内部,候选人并没有获得相应的权力配。 我特别不喜欢“某某"
作者简介
格雷戈尔·霍培 (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

显示全部
用户评论
简单翻了一下,内容太杂了,每个点又讲得比较浅。虽然很多内容也有道理,但是太不系统了
“一个成功的架构师必须有三条腿才能立足: 技能、影响力、领导力”,“一份优秀的技术文档必须记录决策背后的具体原因以及折中后的具体结论”,这是书中的一些观点,作者是一个很务实的架构师,对于有一定经验的程序员或者架构师,一定会跟作者不少的观点产生共鸣
图书馆偶遇,看了以后觉得写的太好,再买一本吧
最大的一个收获就是:架构师不只需要技术,还要会沟通,会向上向下相处等
写给正在帮助传统企业数字化转型的IT架构师的建议
真是经验之谈
看不懂...
趁着相关项目跳章节读了一大半,讲得不深但胜在有趣
故事性很强,通熟易懂,不可多得。沟通、组织、转型。
下载
收藏