《架構師應該知道的37件事》匯集了一名架構師20多年來在全球各大企業(yè)任職的經驗,共分為5個部分,分別對應在幫助大型企業(yè)進行IT轉型的過程中,首席架構師必須高效處理的5個方面:企業(yè)或IT架構師的角色和能力、架構工作在大型企業(yè)中的價值、與各種干系人的溝通、對組織結構和系統(tǒng)的理解、對傳統(tǒng)組織進行轉型。本書科學而系統(tǒng)地歸納出軟件架構師應該具備的完整能力模型,不僅幫助軟件開發(fā)人員系統(tǒng)地學習如何掌握這37項技能,而且還能讓他們進一步理解軟件架構師的角色和本質,使他們最終突破技術“天花板”,成為一名合格的軟件架構師。
1.美亞五星力作,以故事的方式講述架構師的內功心法
2.融匯架構高手20余年經驗心得,領悟企業(yè)信息變革的要義精髓
3.本書科學而系統(tǒng)地歸納出軟件架構師應該具備的完整能力模型,不僅幫助軟件開發(fā)人員系統(tǒng)地學習如何掌握這37項技能,而且還能讓他們進一步理解軟件架構師的角色和本質
很多大型企業(yè)面臨著全球快速數字化的壓力!罢{轉船頭”,這個經常用來描述轉型的短語,已成為很多傳統(tǒng)企業(yè)董事會上的熱議話題。架構師在這樣的數字化轉型中扮演著非常關鍵的角色。那么,如何才能成為成功的架構師呢?如果你已經是成功的架構師了,又如何繼續(xù)獲得支持并保持優(yōu)勢呢?
快翻開本書尋找答案吧!本書采用故事集的編排形式,匯集了一名見多識廣的出色架構師20多年來在全球各大企業(yè)任職的經驗,旨在討論架構師應該如何開拓視野,從而更好地在大型組織中發(fā)揮一技之長。全書共分為5個部分,分別對應在幫助大型企業(yè)進行IT轉型的過程中,架構師必須高效處理的5個方面:
●企業(yè)或IT架構師的角色和能力
●架構工作在大型企業(yè)中的價值
●與各種干系人的溝通
●對組織結構和系統(tǒng)的理解
●對傳統(tǒng)組織進行轉型
格雷戈爾·霍培 (Gregor Hohpe)
ArchitectElevator CXO云轉型顧問,并為新加坡政府科技局提供技術決策咨詢。曾任谷歌(新加坡)技術總監(jiān)兼CTO、谷歌(日本)高級軟件工程師、Allianz公司首席架構師、ThoughtWorks集成架構師。在IT領域有20多年的經驗積累,擁有3項美國專利。與人合著《企業(yè)集成模式》一書。
【譯者簡介】
許順強
資深軟件系統(tǒng)架構師、產品負責人。擅長設備協(xié)同互聯(lián)、物聯(lián)網和云平臺等技術領域,精通敏捷軟件開發(fā)流程,有十多年的跨國項目經驗,擁有1項美國專利和4項中國專利。喜歡編寫易懂易測、高效優(yōu)美的軟件代碼。譯有《C#敏捷開發(fā)實踐》等書。
IT 的50 種形態(tài) 1
第 1章 架構師 6
1.1 架構師電梯 9
1.1.1 缺失的一環(huán) 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 黑客帝國——規(guī)劃大師 14
1.2.2 剪刀手愛德華——園丁 15
1.2.3 粉身碎骨——導游 15
1.2.4 綠野仙蹤——魔法師 16
1.2.5 超級英雄還是強力膠 17
1.2.6 做決定 17
1.3 企業(yè)架構師與企業(yè)里的架構師 18
1.3.1 企業(yè)架構 19
1.3.2 業(yè)務和IT 是平等的 19
1.3.3 企業(yè)里的架構師 20
1.3.4 哪些樓層 20
1.4 架構師用三條腿立足 22
1.4.1 技能、影響力、領導力 22
1.4.2 良性循環(huán) 23
1.4.3 重復良性循環(huán) 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 關聯(lián) 39
2.1.3 異常處理 39
2.1.4 事務 40
2.1.5 反向壓力 41
2.1.6 會話 41
2.1.7 規(guī)范化數據模型 41
2.1.8 歡迎來到現實世界 41
2.2 這是架構嗎 42
2.2.1 定義軟件架構 42
2.2.2。ńㄖ┘軜嫑Q策 43
2.2.3 關鍵決策無須復雜 45
2.2.4 符合目標 45
2.2.5 通過測試 45
2.3 每個系統(tǒng)都是完美的 46
2.3.1 加熱器系統(tǒng) 46
2.3.2 反饋回路 47
2.3.3 有組織的復雜性 47
2.3.4 系統(tǒng)效應 48
2.3.5 理解系統(tǒng)行為 48
2.3.6 影響系統(tǒng)行為 49
2.3.7 系統(tǒng)抗拒改變 50
2.3.8 組織和技術系統(tǒng) 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 如果從不殺死任何系統(tǒng),你就會被“僵尸”包圍 56
2.5.1 遺留系統(tǒng) 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 首先,創(chuàng)造一種語言 79
3.1.5 一致的細節(jié)層次 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 筆桿子比槍桿子更強大,但仍敵不過企業(yè)政治 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 展示環(huán)境 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 系統(tǒng)隱喻 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 預警系統(tǒng) 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 發(fā)動機調優(yōu) 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 局部最優(yōu) 148
5.2.8 盲人鄉(xiāng) 148
5.3 速度經濟 149
5.3.1 舊的規(guī)模經濟 150
5.3.2 關注流程 151
5.3.3 延遲成本 151
5.3.4 可預測性的價值和成本 152
5.3.5 避免重復的價值和成本 152
5.3.6 如何轉變思維模式 153
5.4 無限循環(huán) 154
5.4.1 構建-衡量-學習循環(huán) 154
5.4.2 數字化轉速 155
5.4.3 傳統(tǒng)組織的阻礙 55
5.4.4 在外部循環(huán) 156
5.4.5 加速反饋 156
5.4.6 保持凝聚力 156
5.5 你不能假裝已經數字化 158
5.5.1 奠定基礎 158
5.5.2 反饋循環(huán) 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 創(chuàng)新者的窘境 163
5.6.2 留意最高薪人士的意見 164
5.6.3 開銷和被容忍的低效率 164
5.6.4 外部依賴 164
5.6.5 付出得越多,可能收獲越少 165
5.6.6 文化變革要由內而發(fā) 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