由於“中臺”概念的推動，關心業務架構的讀者越來越多，很多企業也對實施“中臺”、“中臺”方法論趨之若鶩。歷史總是相似的，之前無論 SOA、微服務、DDD，還是敏捷開發、雙模開發等熱門技術概念出現時，都曾經給大家燃起“捷徑”的希望。然而，最終還是證明了軟件領域沒有“銀彈”，很多時候，反倒是應了北歐的一句民諺：捷徑是迷路的最快方法。
架構沒有捷徑，無論從架構的設計、架構的落地還是架構的學習方面來講，都是如此。
架構設計沒有捷徑
架構設計如同求醫問診，必須對症下藥。盲目相信任何已有架構設計成果都是很危險且極不負責任的。每個人的身體都各有特點，企業也是如此，而企業級轉型、企業級工程是對企業現有能力的最大調整，需要企業在認清自己的基礎上進行，任何忽略“向內看”過程的架構設計，都是為今後的混亂，甚至失敗埋下伏筆。
對於複雜手術，不經過詳細的診斷，不經過對術式反覆揣摩，醫生不會輕易為患者開刀，否則，不啻於用生命做試驗。軟件工程雖然少有“人命關天”的事情，但是，浪費時間也等同於浪費生命。
沒有為企業做過深入“體檢”而輕易相信“領先實踐”，很容易把在架構設計上節省的時間和精力，加倍“奉還”到實施過程中去。
企業級架構設計往往給人以過於漫長、難以響應變化的印象，但是，人們恰恰忽略了由此帶來的架構認知的積累，以及由量變到質變的過程。
當人們感慨一次“傳統”的企業級業務架構設計方式可能耗時一到兩年，而互聯網時代非常追逐“快”時，其實並沒有充分意識到，互聯網企業的架構，比如阿里的“中臺”也經歷了十餘年的積澱，而且十餘年的積澱也還只是理清了一個方向，不然也不會有今日對“中臺”概念的眾說紛紜。
互聯網架構並不代表架構設計上有“捷徑”，反而證明了，任何“快”都來自於自身的積累，是充分“向內看”才有了外在的“快”。“快”源自對業務的深刻理解，“中臺”對公共能力的沉澱正是來自於對業務能力的歸納和提煉，所以阿里才十分重視業務架構師的培養，而對“中臺”的探索絕不僅限於對公共能力的沉澱，最終會上升到對企業整體、對何為業務經營的認識，這是一個自然的過程。
筆者在最近與原阿里中臺核心架構師毗盧老師的交流中瞭解到，他們在進行中臺設計時也在反覆思考技術要努力支持業務經營的快速變化。
那業務經營到底是什麼？其實，大家關注的問題從領域級逐步上升到企業級之後，是一定會思考到底企業是什麼、企業如何運轉這些問題的。
互聯網架構並非簡單地快速試錯，這種試錯是對業務選擇能力的支持，而從技術視角看，則是對架構能力的不斷提煉，是架構的強大才有了快速設計的可能。
所以，架構設計沒有捷徑，唯有積累，通過積累提高了對企業自身的瞭解、對架構設計的駕馭能力，才有了可以快的“資本”。
此處，還得再說一次前邊提到的北歐民諺：捷徑是迷路的最快方法，無論是企業還是個人，切換架構設計方法前，都要對學習曲線有深刻的認識，否則，當別人在原來的方向上越走越遠時，你可能還是在原地打轉，只不過為別人提供了案例。
筆者 2019 年在公司負責搭建風險管理體系，而該項工作再次讓我認識到，架構不是可以“抄”的。
風險管理是個很成熟的領域了，三道防線的體系設計方式，無論是金融企業還是科技企業、無論是國內企業還是國外企業都在使用，但是，你卻無法直接把其他企業的防線設計簡單套用過來，必須一個工作事項一個工作事項地分析自己企業的流程，確認風險點，確認工作事項的負責團隊，落實具體的風控職責，之後，再考慮風控措施是否可以實現“機控”，而這一切又取決於該工作事項是否已經線上化。
這樣才能形成一個與實際工作環境相符，並融合數字化風控方向的全面風險管理體系。這種深入細節的體系建設無法通過照搬任何現成經驗來獲得，否則會出現“削足適履”的情況。沒有“捷徑”，只有“路徑”。
架構落地沒有捷徑
經常有讀者好奇企業級業務架構設計如何落地，筆者在書中、在 2019 年 12 月南京的中臺大會上都直言，企業級業務架構設計的落地過程沒有任何神秘和特殊，也不該有，今天筆者認為企業級業務架構日益重要，並不是因為它有什麼落地的捷徑，任何架構設計的落地過程都是靠一個邏輯一個邏輯、一個模塊一個模塊地實現的。
企業級業務架構設計只是讓業務端的整理更加的結構化、整體化了，不同於需求分析對局部細節的關注，也不同於產品分析的領域性特點，企業級業務架構關注的是企業能力的整體規劃和結構化表達，但它並不意味著在實現層面有何特殊性，它只是提供了軟件過程中的一個“指揮棒”，通過業務架構設計形成對軟件功能劃分的指導。而更重要的是，通過業務和技術都能理解的業務架構模型，使企業內部形成可以交流、甚至可以跨領域交流的“共同語言”。
這個“指揮棒”對於提升企業的整體性而言是必不可少的，管理學上一直在研究如何讓企業內部形成管理合力。
業務架構誕生初期，在上個世紀 80-90 年代，企業的信息化程度還不如今日這麼高，業務和技術的深度融合還沒有受到應用的重視，但是今天，淘寶、滴滴、美團、頭條等跨界競爭者給傳統行業的原有企業造成了極大的競爭壓力，乃至很多人都認同未來企業大部分都將轉型為科技企業，工行的領導者最近也發表了此類言論。
由此可見，加強業務與技術的深度融合已經十分必要了，而業務架構正是符合這種時代要求的工具，賦予企業清晰的能力視圖，清晰的結構加上架構的演進，就可能會不斷提升架構的彈性。
企業管理經常追求韌性，常說希望企業能夠像擰毛巾一樣，越擰越緊卻不會擰斷，而未來，鑑於企業都具有科技屬性，這樣的“韌性”可能就要來自於架構的“彈性”了。
提升企業的整體性猶如進行馬拉松訓練，業務架構雖然提供了一個有力的工具，但是馬拉松還是得依靠訓練者一步一步地跑完，成績的提升完全取決於訓練者自身的能力和毅力。
回到軟件工程上，架構落地即便是採用敏捷過程，也不意味著靠的是什麼“捷徑”，而只是對工程組織方式的改進和對效率的追求。
筆者近日閱讀了《敏捷革命》一書，與廣為流傳的“敏捷價值觀”相比，敏捷方法的原創者其實更在意的是如何通過信息的充分獲取與共享、良好的思維模型，以短週期的方式迅速提供核心價值，從而降低項目週期過長導致的項目失敗風險，通過多輪短週期的可控“衝刺”替代長週期的不可控過程。原創者非常推崇 OODA 原則，也就是飛行員訓練中採用的“觀察 - 導向 - 決定 - 行動”模式，其實每一次敏捷的 Scrum 中都體現了這一思想。“觀察”代表了對全面信息的迅速獲取；“導向”是依靠思維模型進行快速分析，也就是快速的設計過程；“決定”就是確定結論，不再猶豫，“行動”就是將決定付諸實現。原創者在書中也強調一個 Scrum 內，需求確定後就儘可能不動，這與飛行員的“決定”、“行動”的模式一樣，因為空戰時間太短了，幾乎沒有後悔重來的機會。
敏捷方法原創者十分推崇豐田的生產方式，筆者恰好最近也讀了《新鄉重夫談豐田生產方式》一書。豐田的生產方式，又稱“精益生產”、“Just-in-time”，是對拒絕“浪費”的極致追求，這個浪費指的不是原材料的浪費，而對是時間、效率的浪費。比如，豐田在思考原材料在不同生產場地間搬運造成的浪費時，首先的解決思路是如何做到不搬運，通過這種思考去調整生產環境；再比如，在反思如何提高打磨零件毛刺工作的效率時，採用了引入歐洲真空加工技術，讓零件根本不產生毛刺的方法。諸如此類的例子還有很多，正是通過這種對點滴效率提升的持續近 20 年的不斷追求，才最終打造出豐田生產方式。
任何方法的形成都是一個長期積累和反思的過程，而應用這些方法也需要使用者付出合理的努力加以掌握，架構設計的落地說到底是軟件工程問題，沒有捷徑，只有持之以恆的效率提升。無論是給予敏捷方法原創者靈感的豐田生產方式，還是敏捷方法原創者自己的實踐歷程，都是一個對方法持續改進、日益精熟的過程。
沒有真正理解方法之前，根本談不上效率，與其總是在方法之間換來換去地求“快”，不如真把自己已有的功夫練到極致，只要解決問題的效率高，你自己就是“一派”。“四萬八千法門”都能成佛，能夠在修煉過程中“博採眾長”就更好了，其實敏捷方法的原創者也正是這樣創立敏捷方法的。
架構學習沒有捷徑
沒有成為架構師的捷徑，只有勤學苦練。架構的學習需要很多基礎性工作，需要很廣泛的涉獵，這方面筆者在《六方面學習，幫你走上業務架構師之路》一文中有所介紹，在架構能力、流程優化、建模技術、軟件過程、編程語言、整體思維方面，都有很多知識需要學習，也列出了一些參考書目，此處不再贅述。
無論是哪一種架構師，都需要深厚的積累，架構師都是項目堆出來的。
不可否認的是，互聯網企業架構師成長確實很快，這也許是企業機制提供了更多的考驗機會給適任者，使其能夠快速進步。如果說培養架構師有什麼勉強可以稱之為“捷徑”的方法，對企業而言，就是認真思考下自己是否建立了快速發現人才、培養人才的機制吧，否則，阿里說過了，業務架構師只能自己培養，沒有合適的人才是什麼也幹不成的。
最近在一部《Doctor X》的連續劇中，醫術高超的女主角在一場難度極高的手術中，說了這樣一段話：“就像河水流淌一樣，反覆的基本技巧，就能創造出美麗的最終術野，那就是理想的手術……最重要的是，不管手術再艱難，也不能拋棄患者”，筆者想，這也同樣適用於架構領域吧。
架構沒有捷徑，有的只是前人的肩膀，努力學習，積極實踐，消化理解，真正站在前人的肩膀上，才可能看到前進的方向，而前人的肩膀也不僅限於你所從事的行業。
付曉巖，《企業級業務架構設計：方法論與實踐》圖書作者，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職於建信金融科技有限責任公司。即將發行新書《銀行數字化轉型》，公眾號：曉談巖說。
閱讀更多 InfoQ 的文章
