筆者在 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」的連接，包括企業層面、架構層面和架構師層面的開放與連接。架構說到底就是結構和關係，架構的四大思維支柱，談的也就是處理好結構和關係的思考原則。文章終歸是一家之言，目的是拋磚引玉，希望有更多的人一起關注在當前這個大家都認定的「技術最好的時代」，我們應該如何培育「架構」這朵 IT 領域之花。
作者簡介：
付曉巖，《企業級業務架構設計：方法論與實踐》圖書作者，騰訊雲最具價值專家。原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職於建信金融科技有限責任公司。
關注我並轉發此篇文章，私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書！