架構師應該知道的37件事

《架構師應該知道的37件事》是2020年人民郵電出版社出版的圖書，作者是格雷戈爾·霍培（Gregor Hohpe）。

基本介紹

• 中文名：架構師應該知道的37件事 
• 作者：格雷戈爾·霍培（Gregor Hohpe）
• 出版社：人民郵電出版社
• ISBN：9787115534651

內容簡介

《架構師應該知道的37件事》匯集了一名架構師20多年來在全球各大企業任職的經驗，共分為5個部分，分別對應在幫助大型企業進行IT轉型的過程中，首席架構師必須高效處理的5個方面：企業或IT架構師的角色和能力、架構工作在大型企業中的價值、與各種干係人的溝通、對組織結構和系統的理解、對傳統組織進行轉型。本書科學而系統地歸納出軟體架構師應該具備的完整能力模型，不僅幫助軟體開發人員系統地學習如何掌握這37項技能，而且還能讓他們進一步理解軟體架構師的角色和本質，使他們最終突破技術“天花板”，成為一名合格的軟體架構師。

作者簡介

格雷戈爾.霍培 （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