架構師必看：架構設計的四大思維支柱

筆者在 InfoQ 前文《關于架構演進發展的探讨》和《架構演進的第四個趨勢：行業級标準化》中，提出了筆者對架構發展趨勢的一些淺見，也介紹了企業級業務架構方法論的來龍去脈，本文拟基于上述文章提煉一下企業軟體（大家常說的 B 端軟體）架構設計中的四大思維支柱供大家參考。

支柱一：整體思維

一、從靈活說起

靈活誕生正是為了解決傳統軟體工程普遍被認為存在的“低效”問題，諸如周期長、不能快速響應需求、成果長期不可見而易導緻失敗等。

是以，靈活往往給人“一言不合就開幹”的雷厲風行的印象，而很多時候，靈活在實操上也确實由于對“速度”和“形式”的片面追求忽視了對整體的合理設計，這樣的靈活并不是真正的靈活，而是“着急”。

靈活開發的幾位殿堂級大師對設計的重要性有着非常深刻的認知。Martin Fowler 認為靈活注重的是演進式設計，而不是輕視設計。

Vernon 也批評一些靈活開發實踐是用“任務闆挪卡”代替了設計；Sutherland 在“OODA”循環中也強調掌握全景資訊而非隻從自身視角看問題的重要性，每次 Scrum 結束提出 MVP，都要重走一遍循環。

因為 MVP 就是為了獲得更多、更全的回報資訊，有了這些資訊才能快速決策，快速決策絕非快拍腦袋，是因為有模式加速了對資訊的處理速度，這才是靈活的原動力，也是要總結方法論的原因，“全景資訊 + 思維模式 = 快速決策”。

“OODA”循環如圖 1 所示：

圖 1 “OODA”循環（來自網際網路）

靈活開發由于其“高效”的特點，在支援快速試錯的同時，也支援快速犯錯，這是一體兩面的，不能隻看到其由于快速提供傳遞物所具有的成果可見能力。

缺少整體把控，靈活也容易堆疊“技術債務”。是以，靈活開發也需要有整體思維做指導而不是隻關注“速度”。

如果靈活也需要整體思維，那本就是以被“诟病”的傳統軟體工程方法和系統分析方法也就更應該“且行且珍惜”了，衆所周知，Zachman 模型、TOGAF 模型和 DODAF 模型都很強調全景資訊。

二、切勿因小失大

所有局部問題的解決都離不開對整體的分析，分析的範圍不同，得出的結論也會不同。舉個簡單的例子，如果我們為功能開發任務排定優先級。

那麼，10 個任務之間進行排序和 20 個任務之間進行排序，很有可能得出排序結論是有很大差異的，分析範圍會決定分析結論。

随着輸入的增加，各類因素在總體上的權重就會有變化，原本認為重要的事情也可能是以不再重要了，最近大家又常提起一句話：“時代的一粒灰落在個人頭上就是一座山”，其實也有這個意味。

面向局部的分析和面向整體的分析是有很大差别的，而現在的企業管理越來越注重提升整體性。

是以，B 端軟體的架構設計、需求解讀都應當有一個全局觀，分析範圍不同，解決方案也可能不同。

過于關注局部，将視野局限在小範圍内，很可能會造成“因小失大”。

近年某大型電商曾在自己的支付平台上引進社交功能，但卻被用于不法用途，結果導緻功能下線。

該電商實力不凡，在系統設計方面也可謂獨步青雲，但是出現這樣大的“失誤”，很可能是分析問題時，沒能更廣泛地觀察已有案例和功能實際價值對整體的貢獻，低估了相關影響。

盡管上述說法未免“事後諸葛亮”，但我們不是一直希望避免出現此類問題嗎？那回首原因，沒做更全面的分析，就不能僅是一種“說辭”了。

三、工具何其難

基于整體分析的架構設計是一件極其耗費心力的工作，我們不能總是依靠架構師這台“碳基計算機”，總給架構師壓上千斤重擔而不提供支援。

架構師不是魔術師，我們也經常忘記了，“架構”是整個企業的架構而不是架構師的“架構”。

工欲善其事必先利其器。工具不僅僅是軟體類工具，方法論、流程管理工具、已有的模型資産、架構管理軟體都屬于工具的範疇，而所有這些資産中，其實最重要的兩樣是方法論和模型資産。

大家可能會覺得架構管理軟體更重要、更直接，但是架構管理軟體是根據架構設計方法論和架構設計實踐做出來的，是以方法論和模型資産是更重要的基礎性工具。

而以目前架構設計的“混亂”現狀而言，沒有通用的架構管理工具也是必然的，因為公認能普适的架構理論和行業級标準化的模型資産都沒有，也就沒有合适的、可以真正直達“痛處”架構管理工具。

如果能做出這樣的工具，那麼，一定可以開辟一個世界級的市場。

除了工具的支援，來自企業的整體支援也很重要，不過這就屬于資源層面而不僅僅是工具了。

面向整體的設計，應當有整體的參與，企業的各個部分都應當參與到整體設計中，而整體設計也應當向整個企業傳導。

走不出架構師的架構設計，沒有持久的維持能力；走不出 IT 部門的架構設計，不會凝聚起整個企業；走不出企業的架構設計，就無法真正落地企業戰略。

支柱二：洞察能力

一、深入了解業務

洞察能力是個老話題，不過架構領域本也沒多少新鮮事，任何架構方法都需要深入實踐才能逐漸掌握要領，架構領域沒有快餐，不大可能“一夜頓悟”，也不要急着“PK”，更多的是需要反複去啃的“硬骨頭”。

做軟體設計，大家常說要對業務進行深入分析，要抓住需求本質，要有合适的抽象力度，這些說的其實都是洞察能力。

洞察需要的是深入了解，而不僅僅是對需求的字面了解或者淺層的溝通。架構領域一直不乏有對哲學方法論的應用。

比如本體論，筆者近期閱讀維特根斯坦的《邏輯哲學論》時也發現，盡管難以深入了解大師的思想精髓。

但是計算機領域對面向對象程式設計的研究與這本一次世界大戰期間寫就的哲學著作如出一轍。

加強洞察能力，一般都會認為是要提升思維穿透能力，這當然是必須的，但是從企業層面而言，也有相對容易操作的方式，就是加強深層次溝通。

這首先需要企業逐漸改變業務人員的和技術人員的比例，使技術人員能夠走到業務人員中間來，加強二者的融合。

所謂深層次溝通并不是兩個人要碰撞出哲學火花，如果兩個人之間隻能具有一個聊聊需求的時間，就急着做産品上線了，那雙方之間的了解深度必然是有限的。

技術人員如果能夠輪班走到業務人員中間提供實地支援，深入了解工作環境，實際感受業務壓力，了解的深度自然會增加。

我們不需要指望技術人員變成哲學家來增加洞察力，隻需要給予他們更多的觀察機會和思考時間。這并非“強人所難”，至少，國外的大銀行，如摩根大通、高盛、Capital One 等，已經不乏這樣的操作了。

可能很多人會覺得這對中小企業不公平，不可操作，畢竟他們資源有限，但是，這也取決于你是否相信“未來的企業都是科技企業”。

至少筆者相信，因為軟體将是未來最主要的生産方式。也許今天很多企業不用急着進行這個操作。

但是，這不代表可以忽視這個問題，而越大的企業應該越早動手，因為企業越大轉型越慢、周期越長、溝通模式越複雜，企業的全貌也越難以掌握。

二、努力推進标準化

如果軟體行業整體都具備了深入的洞察能力的話，那标準化就應當是件自然的事情，農業和工業的發展都是這個曆程。

農業的耕種方法、選種和培育、肥料的制作，即便在今天看來極為簡陋的原始生産階段，為了提高農業種植的成功率和産量，也是在進行着不懈的“标準化”努力。

農書早已有之，即便在著名的“焚書坑儒”中，也獲準可以保留，可見古人對農業技術的重視，更不用說在現代工業條件支援下的大規模農業生産。

與之相比，軟體行業真有那麼特殊嗎？真的不會有标準化生産這個曆程嗎？

反思軟體行業目前的情況，也許隻能說，洞察力依然不夠，至少沒有真正了解标準化對行業的意義。

否則，一個已經發展了 70 多年、精英輩出的行業，不會在标準化資産、标準化生産方面如此“尴尬”。

我們書寫了那麼多的技術标準，卻依然無法提供一套能夠有效複用的行業級軟體資産，當然，這種複用不是指搬過來就用，而是至少不用從頭做起。

開源提供了很好的支援未來大規模軟體生産的模式參考，而需要的是增加對标準化的管理的思考，這也許是未來開源的發展方向。

沒有标準化能力，軟體行業可能無法撐起未來對軟體生産的大規模需求。标準化是行業成熟的表現，也是軟體行業對自身、對其他行業都具備深刻洞察力的展現，更是設計師在設計時應為之努力的方向。

支柱三：演進思維

一、唯快不破？

“快魚吃慢魚”幾乎成了當今社會的集體“焦慮”, 企業由于競争的壓力，對“立竿見影”的追求近乎“執着”。

筆者也是個二次元的愛好者，每每想到這個問題，自然會浮現出一部漫畫作品——《浪客劍心》，主人公绯村劍心的獨門絕技就是“拔刀”，一回合解決對手，拔刀的瞬間就緻對手與死地。

相信很多企業在搞軟體建設時也寄望于此，希望采用某個架構、做成某個系統後，可以實作超級應變能力。

然而漫畫作品中的主人公是在經曆了地獄般的生死訓練之後才具備如此能力，帶着一身的傷病，成了一台需要精心保養否則很難“善終”的機器，用個通俗點兒的解釋就是職業壽命比較短。

是以，“快”都是有代價、有基礎的，“快”是系統性訓練的結果，不是哪個部門的“快”在支撐整個企業的“快”；“快”是整個企業持續演進出來的，而不是被外部因素突然賦予的。

大家都不是漫威電影裡的“超級英雄”，不是天賦異禀，也不是被蜘蛛咬一口就可以拯救世界。

不注重基礎的“快”，隻能是“眼見他起高樓，眼見他樓塌了”。在業務領域裡，我們不乏見到業務人員被逼急了而出現的業績造假、财務造假，而忽視軟體工程的底線要求，把技術人員催的太緊，也可能出現技術“造假”。

也許筆者的說法不夠準确，但是英國 TSB 銀行的案例也許可以當成一個側寫吧。業績造假、财務造假對企業管理者而言還是可以搞清楚的問題，但是技術方面出的問題，相信大部分管理者可能搞不清楚。

有興趣的讀者可以看看對計算機 BUG 的分類，像薛定谔類型、海森堡類型、分形類型等，這是連技術人員自己都搞不懂的 BUG 形态。

技術目标的實作很難一蹴而就，也許不少傳統企業的管理者會問如今網際網路企業不是很具備“快”的樣子嗎？

與傳統企業相比，他們是挺快，這是因為他們具有更好的技術管理能力和開發環境，有基礎設施支援人員能力的發揮，但是，不容忽視的是之前熱過的“996.ICU”這個話題。

靈活創始人可是說過，靈活應該是高效和不用加班的。這種透支技術人員身體，把軟體行業搞得像“血汗工廠”的做法，不應該用對“理想”的追求一筆帶過。

傳統方法隻要用的純熟、堅持對方法論的完善和演進，合适的條件下，一樣可以獲得“快”的效果。

比如二神山的建設就是在瀑布模型和甘特圖的指導下實作“中國速度”的，感興趣的讀者可以找找二神山的工程師們公開分享的資料，看看他們對傳統方法的運用。

回到正題，架構設計及其實作應該注重的是演進思維，不可能“畢其功于一役”，再着急也無法忽視客觀規律。

如同搞戰略設計，如果給設計人員的隻有泡一碗友善面的時間，那傳遞的也隻能是一碗戰略友善面。

二、演進方向

架構設計要具備演進思維，演進思維除了意味着大目标要分段實作外，也意味着對目标該有一個整體認知，這個認知對企業軟體而言，就是要統一到企業的願景和戰略上。

本文筆者延續自己在《企業級業務架構設計：方法論與實踐》一書中的觀點，将願景定位于 20-30 年的長期方向，而将戰略定位于 3 年左右的“短期”方向。

技術變化比較快，戰略周期長了不利于調整，但是太短也很難有明顯實施效果，尤其是對大型企業而言。

從長期願景的角度看，數字化轉型是必然的，當代的人碰巧處于時代切換的轉型陣痛期，作為經曆“痛苦”的人，任何企業和個人都無法回避這個問題。

筆者将其列為長期方向，是因為筆者所認為的數字化與目前更為貼近資訊化的各類主張不同。

數字化不是一兩個系統或者某個架構就可以快速解決的問題，而是整個社會的數字化，企業的數字化是社會數字化中的一環，并且，不可能僅靠自身的數字化完成。

以數字化轉型為架構設計思維演進的長期方向，在每個戰略周期内，密切跟蹤技術的發展，适時引入可能帶來業務模式變化的技術，實作新技術與業務的融合，這種架構駕馭能力才是未來企業競争的關鍵。

筆者對數字化轉型的詳細論述包含在即将面世的新書《銀行數字化轉型》中，本文不再過多着墨于此。

支柱四：開放思維

一、有中心而無權威

這個說法略有“不當”，但筆者暫時沒有想到更形象的表述。實際工作中，架構師在項目中是具有“權威”性的，這樣比較有利于項目的總體管理，大的項目可能會有很多架構師，因為架構師的分工也是很細的，是以，從效率上來講，也需要設立個“首架”。

“中心”會提高執行效率，但是，架構師必須具有開放性，保持謙虛，架構師是“中心”，但不要總把“權威”看得太重，架構是企業整體資産。

說的不客氣點兒，企業搞架構也正是為了能夠擺脫對特定架構師的“單點依賴”，使架構工作能夠保持“業務連續性”。

架構設計中要保持這種謙遜性，這樣才能讓更好的設計思路進入設計師的視野，進入設計方案。“海納百川，有容乃大”。

所謂的技術權威，最好是自然形成的，而非來自于職權的任命；技術權威是用來“向我開炮”的，如果用來維護，很可能會産生适得其反的結果。

技術權威最終代表的是問題能被更好地解決，而不是“唯馬首是瞻”。

架構設計非常需要注重整體，盡可能考慮全景資訊，這往往也意味者過于依賴“權威”架構師其實是有風險的，“智者千慮必有一失”，負擔太重也會造成核心架構師“過載”。

從這個角度講，架構師團隊的開放協作，或者架構師與項目團隊的開放協作是非常重要的，整體思維和開放思維之間相輔相成。

二、開放式架構設計

關于開放銀行的讨論去年和今年特别多，筆者也曾釋出過相關文章，在筆者看來，與其稱之為開放銀行不如稱其為開放式架構含義會更明确。

企業之間在生态建設的“大旗”下，連接配接越來越緊密，而且從商業層面的連接配接逐漸下沉為技術層面的連接配接，API、SDK 等對接方式讓資訊化程度較高的企業之間聯系更為密切。

随着企業架構理論和企業實踐能力的提升，企業内部一體化程度會逐漸加強，并轉化為展現生态分工的跨企業系統協作。

這要求架構設計遵循開放的設計方向，以企業之間更好地對接為目标，實作跨企業的流程整合，這樣組成的“競合”關系更穩定、更具競争力。

面向開放式協作的架構設計，要求企業有更好的、可讀性強、可公開的内部架構，這樣才能有更好的協作前提。

而今天這種充滿個性的架構設計風格，要逐漸向更加标準化、更容易溝通的方向發展。

PPT 不是架構師的發力點，對架構的過度宣傳也許反而不利于架構的健康發展，架構風格的過度自由也許會帶來溝通上的不自由。

盡管今天架構師們面對的企業環境、技術環境越來越複雜，但是，簡單依然是設計應該持續追求的目标。

本文總結的四大思維支柱相信各位讀者并不陌生，筆者隻是将個人的一些了解融合進去。

如果用“T”型人才或者“T”型思維類比的話，整體思維相當于“T”字橫頭的“一”，洞察能力相當于“∣”，演進思維相當于小“T”逐漸積累成大“T”，而開放思維相當于多個“T”的連接配接，包括企業層面、架構層面和架構師層面的開放與連接配接。

結語