架構師應該知道的 37件事

架構師應該知道的 37件事

作者: [美] 格雷戈爾·霍培(Gregor Hohpe) 許順強
出版社: 人民郵電
出版在: 2020-05-01
ISBN-13: 9787115534651
ISBN-10: 7115534659
裝訂格式: 平裝
總頁數: 175 頁





內容描述


本書匯集了一名架構師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#敏捷開發實踐》等書。




相關書籍

Ultimate Guide to Project Management

作者 Sid Kemp

2020-05-01

敏捷開發(紀念版)

作者 [美]羅伯特.C.馬丁(Robert C. Martin)米咖.馬丁(micah martin) 簡方達 譯

2020-05-01

Practical Software Engineering: A Case-Study Approach

作者 Leszek Maciaszek Bruc Lee Liong

2020-05-01