筆者在 InfoQ 前文《關於架構演進發展的探討》和《架構演進的第四個趨勢：行業級標準化》中，提出了筆者對架構發展趨勢的一些淺見，也介紹了企業級業務架構方法論的前因後果，本文擬基於上述文章提煉一下企業軟件（你們常說的 B 端軟件）架構設計中的四大思惟支柱供你們參考。編程
支柱一：總體思惟
1、從敏捷提及
敏捷誕生正是爲了解決傳統軟件工程廣泛被認爲存在的「低效」問題，諸如週期長、不能快速響應需求、成果長期不可見而易致使失敗等，所以，敏捷每每給人「一言不合就開幹」的雷厲風行的印象，而不少時候，敏捷在實操上也確實因爲對「速度」和「形式」的片面追求忽視了對總體的合理設計，這樣的敏捷並非真正的敏捷，而是「着急」。api
敏捷開發的幾位殿堂級大師對設計的重要性有着很是深入的認知。Martin Fowler 認爲敏捷注重的是演進式設計，而不是輕視設計；Vernon 也批評一些敏捷開發實踐是用「任務板挪卡」代替了設計；Sutherland 在「OODA」循環中也強調掌握全景信息而非只從自身視角看問題的重要性，每次 Scrum 結束提出 MVP，都要重走一遍循環，由於 MVP 就是爲了得到更多、更全的反饋信息，有了這些信息才能快速決策，快速決策絕非快拍腦殼，是由於有模式加速了對信息的處理速度，這纔是敏捷的原動力，也是要總結方法論的緣由，「全景信息 + 思惟模式 = 快速決策」。微信
「OODA」循環如圖 1 所示：
架構
圖 1 「OODA」循環（來自互聯網）app
敏捷開發因爲其「高效」的特色，在支持快速試錯的同時，也支持快速犯錯，這是一體兩面的，不能只看到其因爲快速提供交付物所具備的成果可見能力。缺乏總體把控，敏捷也容易堆疊「技術債務」。因此，敏捷開發也須要有總體思惟作指導而不是隻關注「速度」。若是敏捷也須要總體思惟，那本就所以被「詬病」的傳統軟件工程方法和系統分析方法也就更應該「且行且珍惜」了，衆所周知，Zachman 模型、TOGAF 模型和 DODAF 模型都很強調全景信息。工具
2、切勿因小失大
全部局部問題的解決都離不開對總體的分析，分析的範圍不一樣，得出的結論也會不一樣。舉個簡單的例子，若是咱們爲功能開發任務排定優先級，那麼，10 個任務之間進行排序和 20 個任務之間進行排序，頗有可能得出排序結論是有很大差別的，分析範圍會決定分析結論。隨着輸入的增長，各種因素在整體上的權重就會有變化，本來認爲重要的事情也可能所以再也不重要了，最近你們又常提起一句話：「時代的一粒灰落在我的頭上就是一座山」，其實也有這個意味。ui
面向局部的分析和麪向總體的分析是有很大差異的，而如今的企業管理愈來愈注重提高總體性，所以，B 端軟件的架構設計、需求解讀都應當有一個全局觀，分析範圍不一樣，解決方案也可能不一樣。url
過於關注局部，將視野侷限在小範圍內，極可能會形成「因小失大」。近年某大型電商曾在本身的支付平臺上引進社交功能，但卻被用於不法用途，結果致使功能下線。該電商實力不凡，在系統設計方面也可謂獨步青雲，可是出現這樣大的「失誤」，極可能是分析問題時，沒能更普遍地觀察已有案例和功能實際價值對總體的貢獻，低估了相關影響。儘管上述說法未免「過後諸葛亮」，但咱們不是一直但願避免出現此類問題嗎？那回首緣由，沒作更全面的分析，就不能僅是一種「說辭」了。spa
3、工具何其難
基於總體分析的架構設計是一件極其耗費心力的工做，咱們不能老是依靠架構師這臺「碳基計算機」，總給架構師壓上千斤重擔而不提供支持，架構師不是魔術師，咱們也常常忘記了，「架構」是整個企業的架構而不是架構師的「架構」。.net
工欲善其事必先利其器。工具不只僅是軟件類工具，方法論、流程管理工具、已有的模型資產、架構管理軟件都屬於工具的範疇，而全部這些資產中，其實最重要的兩樣是方法論和模型資產。
你們可能會以爲架構管理軟件更重要、更直接，可是架構管理軟件是根據架構設計方法論和架構設計實踐作出來的，因此方法論和模型資產是更重要的基礎性工具，而以目前架構設計的「混亂」現狀而言，沒有通用的架構管理工具也是必然的，由於公認能普適的架構理論和行業級標準化的模型資產都沒有，也就沒有合適的、能夠真正直達「痛處」架構管理工具，若是能作出這樣的工具，那麼，必定能夠開闢一個世界級的市場。
除了工具的支持，來自企業的總體支持也很重要，不過這就屬於資源層面而不只僅是工具了。面向總體的設計，應當有總體的參與，企業的各個部分都應當參與到總體設計中，而總體設計也應當向整個企業傳導。走不出架構師的架構設計，沒有持久的維持能力；走不出 IT 部門的架構設計，不會凝聚起整個企業；走不出企業的架構設計，就沒法真正落地企業戰略。
支柱二：洞察能力
1、深刻理解業務
洞察能力是個老話題，不過架構領域本也沒多少新鮮事，任何架構方法都須要深刻實踐才能逐漸掌握要領，架構領域沒有快餐，不大可能「一晚上頓悟」，也不要急着「PK」，更多的是須要反覆去啃的「硬骨頭」。
作軟件設計，你們常說要對業務進行深刻分析，要抓住需求本質，要有合適的抽象力度，這些說的其實都是洞察能力。洞察須要的是深刻理解，而不只僅是對需求的字面理解或者淺層的溝通。架構領域一直不乏有對哲學方法論的應用，好比本體論，筆者近期閱讀維特根斯坦的《邏輯哲學論》時也發現，儘管難以深刻理解大師的思想精髓，可是計算機領域對面向對象編程的研究與這本一次世界大戰期間寫就的哲學著做一模一樣。
增強洞察能力，通常都會認爲是要提高思惟穿透能力，這固然是必須的，可是從企業層面而言，也有相對容易操做的方式，就是增強深層次溝通。這首先須要企業逐步改變業務人員的和技術人員的比例，使技術人員可以走到業務人員中間來，增強兩者的融合。
所謂深層次溝通並非兩我的要碰撞出哲學火花，若是兩我的之間只能具備一個聊聊需求的時間，就急着作產品上線了，那雙方之間的瞭解深度必然是有限的。技術人員若是可以輪班走到業務人員中間提供實地支持，深刻理解工做環境，實際感覺業務壓力，理解的深度天然會增長。咱們不須要期望技術人員變成哲學家來增長洞察力，只須要給予他們更多的觀察機會和思考時間。這並不是「強人所難」，至少，國外的大銀行，如摩根大通、高盛、Capital One 等，已經不乏這樣的操做了。
可能不少人會以爲這對中小企業不公平，不可操做，畢竟他們資源有限，可是，這也取決於你是否相信「將來的企業都是科技企業」，至少筆者相信，由於軟件將是將來最主要的生產方式。也許今天不少企業不用急着進行這個操做，可是，這不表明能夠忽視這個問題，而越大的企業應該越早動手，由於企業越大轉型越慢、週期越長、溝通模式越複雜，企業的全貌也越難以掌握。
2、努力推動標準化
若是軟件行業總體都具有了深刻的洞察能力的話，那標準化就應當是件天然的事情，農業和工業的發展都是這個歷程。農業的耕種方法、選種和培育、肥料的製做，即使在今天看來極爲簡陋的原始生產階段，爲了提升農業種植的成功率和產量，也是在進行着不懈的「標準化」努力。農書早已有之，即使在著名的「焚書坑儒」中，也獲准能夠保留，可見古人對農業技術的重視，更不用說在現代工業條件支持下的大規模農業生產。與之相比，軟件行業真有那麼特殊嗎？真的不會有標準化生產這個歷程嗎？
反思軟件行業目前的狀況，也許只能說，洞察力依然不夠，至少沒有真正理解標準化對行業的意義，不然，一個已經發展了 70 多年、精英輩出的行業，不會在標準化資產、標準化生產方面如此「尷尬」，咱們書寫了那麼多的技術標準，卻依然沒法提供一套可以有效複用的行業級軟件資產，固然，這種複用不是指搬過來就用，而是至少不用從頭作起。
開源提供了很好的支持將來大規模軟件生產的模式參考，而須要的是增長對標準化的管理的思考，這也許是將來開源的發展方向。
沒有標準化能力，軟件行業可能沒法撐起將來對軟件生產的大規模需求。標準化是行業成熟的表現，也是軟件行業對自身、對其餘行業都具有深入洞察力的體現，更是設計師在設計時應爲之努力的方向。
支柱三：演進思惟
1、惟快不破？
「快魚吃慢魚」幾乎成了當今社會的集體「焦慮」, 企業因爲競爭的壓力，對「立竿見影」的追求近乎「執着」。筆者也是個二次元的愛好者，往往想到這個問題，天然會浮現出一部漫畫做品——《浪客劍心》，主人公緋村劍心的獨門絕技就是「拔刀」，一回合解決對手，拔刀的瞬間就致對手與死地。相信不少企業在搞軟件建設時也寄望於此，但願採用某個架構、作成某個系統後，能夠實現超級應變能力。
然而漫畫做品中的主人公是在經歷了地獄般的生死訓練以後才具有如此能力，帶着一身的傷病，成了一臺須要精心保養不然很難「善終」的機器，用個通俗點兒的解釋就是職業壽命比較短。因此，「快」都是有代價、有基礎的，「快」是系統性訓練的結果，不是哪一個部門的「快」在支撐整個企業的「快」；「快」是整個企業持續演進出來的，而不是被外部因素忽然賦予的。你們都不是漫威電影裏的「超級英雄」，不是天賦異稟，也不是被蜘蛛咬一口就能夠拯救世界。
不注重基礎的「快」，只能是「眼見他起高樓，眼見他樓塌了」。在業務領域裏，咱們不乏見到業務人員被逼急了而出現的業績造假、財務造假，而忽視軟件工程的底線要求，把技術人員催的太緊，也可能出現技術「造假」。也許筆者的說法不夠準確，可是英國 TSB 銀行的案例也許能夠當成一個側寫吧。業績造假、財務造假對企業管理者而言仍是能夠搞清楚的問題，可是技術方面出的問題，相信大部分管理者可能搞不清楚。有興趣的讀者能夠看看對計算機 BUG 的分類，像薛定諤類型、海森堡類型、分形類型等，這是連技術人員本身都搞不懂的 BUG 形態。
技術目標的實現很難一蹴而就，也許很多傳統企業的管理者會問現在互聯網企業不是很具有「快」的樣子嗎？與傳統企業相比，他們是挺快，這是由於他們具備更好的技術管理能力和開發環境，有基礎設施支持人員能力的發揮，可是，不容忽視的是以前熱過的「996.ICU」這個話題。敏捷創始人但是說過，敏捷應該是高效和不用加班的。這種透支技術人員身體，把軟件行業搞得像「血汗工廠」的作法，不該該用對「理想」的追求一筆帶過。
傳統方法只要用的純熟、堅持對方法論的完善和演進，合適的條件下，同樣能夠得到「快」的效果。好比二神山的建設就是在瀑布模型和甘特圖的指導下實現「中國速度」的，感興趣的讀者能夠找找二神山的工程師們公開分享的資料，看看他們對傳統方法的運用。
回到正題，架構設計及其實現應該注重的是演進思惟，不可能「畢其功於一役」，再着急也沒法忽視客觀規律。如同搞戰略設計，若是給設計人員的只有泡一碗方便麪的時間，那交付的也只能是一碗戰略方便麪。
2、演進方向
架構設計要具有演進思惟，演進思惟除了意味着大目標要分段實現外，也意味着對目標該有一個總體認知，這個認知對企業軟件而言，就是要統一到企業的願景和戰略上。本文筆者延續本身在《企業級業務架構設計：方法論與實踐》一書中的觀點，將願景定位於 20-30 年的長期方向，而將戰略定位於 3 年左右的「短時間」方向。技術變化比較快，戰略週期長了不利於調整，可是過短也很難有明顯實施效果，尤爲是對大型企業而言。
從長期願景的角度看，數字化轉型是必然的，當代的人碰巧處於時代切換的轉型陣痛期，做爲經歷「痛苦」的人，任何企業和我的都沒法迴避這個問題。筆者將其列爲長期方向，是由於筆者所認爲的數字化與目前更爲貼近信息化的各種主張不一樣，數字化不是一兩個系統或者某個架構就能夠快速解決的問題，而是整個社會的數字化，企業的數字化是社會數字化中的一環，而且，不可能僅靠自身的數字化完成。
以數字化轉型爲架構設計思惟演進的長期方向，在每一個戰略週期內，密切跟蹤技術的發展，適時引入可能帶來業務模式變化的技術，實現新技術與業務的融合，這種架構駕馭能力纔是將來企業競爭的關鍵。
筆者對數字化轉型的詳細論述包含在即將面世的新書《銀行數字化轉型》中，本文再也不過多着墨於此。
支柱四：開放思惟
1、有中心而無權威
這個說法略有「不當」，但筆者暫時沒有想到更形象的表述。實際工做中，架構師在項目中是具備「權威」性的，這樣比較有利於項目的整體管理，大的項目可能會有不少架構師，由於架構師的分工也是很細的，所以，從效率上來說，也須要設立個「首架」。
「中心」會提升執行效率，可是，架構師必須具備開放性，保持謙虛，架構師是「中心」，但不要總把「權威」看得過重，架構是企業總體資產，說的不客氣點兒，企業搞架構也正是爲了可以擺脫對特定架構師的「單點依賴」，使架構工做可以保持「業務連續性」。
架構設計中要保持這種謙遜性，這樣才能讓更好的設計思路進入設計師的視野，進入設計方案。「海納百川，有容乃大」。所謂的技術權威，最好是天然造成的，而非來自於職權的任命；技術權威是用來「向我開炮」的，若是用來維護，極可能會產生拔苗助長的結果；技術權威最終表明的是問題能被更好地解決，而不是「惟馬首是瞻」。
架構設計很是須要注重總體，儘量考慮全景信息，這每每也意味者過於依賴「權威」架構師實際上是有風險的，「智者千慮必有一失」，負擔過重也會形成核心架構師「過載」。從這個角度講，架構師團隊的開放協做，或者架構師與項目團隊的開放協做是很是重要的，總體思惟和開放思惟之間相輔相成。
2、開放式架構設計
關於開放銀行的討論去年和今年特別多，筆者也曾發佈過相關文章，在筆者看來，與其稱之爲開放銀行不如稱其爲開放式架構含義會更明確。企業之間在生態建設的「大旗」下，鏈接愈來愈緊密，並且從商業層面的鏈接逐漸下沉爲技術層面的鏈接，API、SDK 等對接方式讓信息化程度較高的企業之間聯繫更爲密切。
隨着企業架構理論和企業實踐能力的提高，企業內部一體化程度會逐漸增強，並轉化爲體現生態分工的跨企業系統協做，這要求架構設計遵循開放的設計方向，以企業之間更好地對接爲目標，實現跨企業的流程整合，這樣組成的「競合」關係更穩定、更具競爭力。
面向開放式協做的架構設計，要求企業有更好的、可讀性強、可公開的內部架構，這樣纔能有更好的協做前提，而今天這種充滿個性的架構設計風格，要逐漸向更加標準化、更容易溝通的方向發展。PPT 不是架構師的發力點，對架構的過分宣傳也許反而不利於架構的健康發展，架構風格的過分自由也許會帶來溝通上的不自由。儘管今天架構師們面對的企業環境、技術環境愈來愈複雜，可是，簡單依然是設計應該持續追求的目標。
本文總結的四大思惟支柱相信各位讀者並不陌生，筆者只是將我的的一些理解融合進去。若是用「T」型人才或者「T」型思惟類比的話，總體思惟至關於「T」字橫頭的「一」，洞察能力至關於「∣」，演進思惟至關於小「T」逐步積累成大「T」，而開放思惟至關於多個「T」的鏈接，包括企業層面、架構層面和架構師層面的開放與鏈接。架構說到底就是結構和關係，架構的四大思惟支柱，談的也就是處理好結構和關係的思考原則。
文章終歸是一家之言，目的是拋磚引玉，但願有更多的人一塊兒關注在當前這個你們都認定的「技術最好的時代」，咱們應該如何培育「架構」這朵 IT 領域之花。
相關文章：
本文分享自微信公衆號 - 曉談巖說（）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。