軟件設計面對的環境日趨複雜。背後原因不僅有技術發展本身帶來的複雜性，而且也有規模增大帶來的複雜性。
從最初面向小型羣體、具體領域的程序設計，到面向上億用戶、交叉需求的生態構建，軟件設計似乎走上一條以複雜應對複雜的發展之路。我們看到，從方法到概念都日趨複雜。
一開始，很多軟件的早期版本較爲清晰，後來逐漸走向“大泥球”模式。最終，它們“活成了我們最討厭的樣子”。
“技術債務”成爲軟件生命週期中的常見問題，所以，對軟件設計方法尤其是架構方法的探索始終未停。這些探索與軟件工程方法的演進互相作用。
對這種日趨複雜、難以駕馭的狀況，很多軟件人希望能有所改善。衆所周知，標準化對提升架構設計效率和提高軟件開發成功率很有裨益。在架構方法發展的過程中，關於這個方面的標準化努力也一直在緩慢推進。這個標準並非指軟件開發標準，比如國內的 GB8567-88，而是指能直接應用於具體開發的設計參考，比如行業級標準化模型。
本文探討架構演進的另一個趨勢，就是行業級標準化。
1 爲何行業級標準化發展緩慢？
行業級標準化之所以較難達成，是因爲背後有許多複雜因素。
首先，這是一項帶有公益性質的工作。一旦做成功，大家都受益，但推動者的付出與其收益之間不成比例，要靠一定的“奉獻”精神支撐。
其次，標準達成需要統一衆多觀點。而這種統一併非可以強制達成，標準本身的建立過程就會比較緩慢。時間一久，甚至不了了之。
最後，即便建立標準，更新維護的主體通常也難以確定和維持，“保鮮”難度大。
如此困難之事，爲何今日應該重提？這又涉及另外兩個原因，而它們卻是今後軟件或者數字化的發展方向。
1. 軟件在生產、生活中的基礎性地位還不夠
我們現在常說，軟件、互聯網改變了人類社會，但實際上，並非所有行業和生活場景都充分線上化了。事實是，大部分行業中，軟件的基礎性地位還沒有達到人們通過宣傳所“認爲”的水平，並且，軟件行業總產值也沒在 GDP 中有很高佔比。
這表明，軟件還未像工業製成品那樣深入到社會的各個角落，軟件生產也沒像工業生產那樣成爲廣泛的社會性生產。
根據埃文斯數據公司 (Evans Data Corporation) 2019 年最新的統計數據顯示，2018 年全球共有 2300 萬軟件開發人員；到 2019 年底，這個數字將達到 2640 萬，而到 2023 年，這個數字是 2770 萬。其中，它對軟件開發人員的定義很廣泛，甚至包括技術作家。
與之相比，2018 年，世界各國青壯年和逐漸進入的勞動年齡段 (15 至 64 歲) 人口總數約爲 49.6 億（數據來源於互聯網）。也就是說，無論是從行業規模還是勞動人口的數量來講，軟件行業仍處在上升階段，還沒有成爲一個像農業或者工業那樣可作爲時代標誌的行業，數字經濟仍在發展初期。
從這種狀況，我們可以推想，多數對於行業級標準化的真實“焦慮”可能只存在於少數軟件從業者心裏，還沒真正上升爲企業“焦慮”，更未成爲行業“焦慮”。
所以，在開發中，儘管我們在項目管理中反覆強調一些項目級的標準化要求，但這些要求沒有真正走出項目以外，沒有真正成爲企業級、行業級的要求，所以行業級標準化的進程也必然緩慢。
但是，數字經濟的發展速度正在加快，不少人認同未來的企業可能都是科技企業。軟件會成爲主要的生產工具，這也許會改變經濟數據的統計口徑，從而讓數字經濟規模得到更準確的計量。
隨着這種發展，即便出於讓工具更易用、更易得的角度，行業級標準化也應得到更大重視。
企業之所以要爲軟件付出更大代價，很大一部分原因就是軟件無法像真正的工業製品一樣批量化製作與獲得，以及提供售後，甚至是其中無需太個性化的部分。當企業、行業越來越依賴於軟件時，軟件中的主要部分需要被標準化和真正量產。
當過度強調軟件使用和軟件生產中的個性化因素，這會讓軟件行業面對與工業化早期類似的問題，尤其是在“B”端，過度的“自由”可能會帶來“不自由”。這些過度之處對“創新”的意義也許被誇大。
工業標準化沒有讓工業變得死板和缺乏創新，反而減少浪費，讓創新能更好地分層次進行，比如設計創新、零件創新、材質創新和集成創新等，而無需經常從頭開始。軟件行業也應該通過行業級標準化減少“創新浪費”，這樣纔有可能讓軟件走出現在這種“大規模小團隊手工作坊”的階段。所謂的 AI 設計，需要的不也正是基礎性的標準化嗎？
也許滿足標準化，我們才能把精力花在更有價值的創新上，而不是整天修改別人也改過的 BUG，成天擔心踩別人踩過的坑。
標準化是工業成熟的體現，也是其在整個社會生產中基礎性地位增強的必然結果，這也是軟件未來必須要走的路。
2. 架構設計的開放性不足
在發展的大部分時間中，軟件設計更多處理的是封閉邊界內的封閉問題域。當處理複雜問題時，軟件設計者的思考習慣是儘可能將複雜問題拆分成更小的獨立問題。處理“封閉”空間會令軟件設計者感到“舒適”，而“開放”空間則容易讓軟件設計者失去“焦點”，也會帶來更大的知識負擔。
處理好邊界是軟件設計的原則之一，不定義好邊界的軟件很可能無法交付。這種方式本身無可厚非，其隱含的問題在於，多數軟件設計缺乏企業間的橫向聯通和行業級的定義。很多承載行業統一概念的行業術語雖然在設計過程中被軟件人員學習和思考，但並沒有發揮其在標準化方面應有的作用，“封閉”也成了一個一個軟件實例的“封閉”。
現有的各類技術標準多數無法幫軟件形成標準化的設計結果，它們更多是對工藝和技術的要求。
工業在發展早期，企業間的標準化和連通性也不強，一度出現囊括生產鏈條大部分環節的超大型企業集團。但是，隨着精細化分工的發展，企業最終放棄這種不經濟的“全都幹”模式，採用供應鏈、生態圈模式。
標準化在提升企業協作上發揮至關重要的作用。
早在 1926 年，擁有國家級標準化組織的 25 個國家在國際上成立國家標準化協會國際聯合會（ISA），由此，標準化活動從企業行爲演進爲國家管理，進而成爲全球事業，活動範圍從機電行業擴展到各行各業。標準化擴散到全球經濟的的各個領域，從保障互換性的手段，發展成保障資源合理配置、降低貿易壁壘和提高生產力的重要手段。
軟件行業現在也有些類似工業早期的狀況，優秀開發資源的集中，從上到下的完整、個性化開發比比皆是。
此外，企業習慣於“封閉”設計成果，因爲軟件一旦跟核心生產領域接觸，就自然地牽連上各類“商業祕密”，導致成果“封閉”，甚至包括設計過程中產生的模型資產，這也是大家需要重複建設的原因之一。
綜上所述，軟件開發中，思考方式、設計範圍、設計成果方面都具有不同程度的“封閉”傾向。當然，這其中有其處理現實問題方面的必要性，但是，這也導致架構在設計標準和視野上不夠開放，標準化發展緩慢。
現在，隨着互聯網技術對企業連接能力的進一步加強，生態圈構建從業務層面將下沉到軟件層面，要求軟件層面更多地支持聯通和協同，這不僅僅是對 API 的關注，還需要在架構設計方面有更多的全局視野和開放性。各類新興技術，無論是出於對應用成本的考量，還是對應用速度的考量，都需要其在轉換爲軟件時，提升通用性，提升標準化水平。
從企業內部架構走向開放式架構、推動國民經濟數字化轉型的過程中，軟件架構順應經濟模式的發展，必須要解決標準化短板對開放性、規模化的制約。這不僅有助於將設計人員從重複“搬磚”過程中解放出來，也讓“磚”能更方便地蓋成“樓”，不能總把軟件設計當做個體行爲和個別實例。
2 行業級標準化的核心方向
軟件設計主要處理的對象就是數據和行爲，架構設計的關鍵其實也在識別數據結構，劃分處理數據的不同行爲模塊。
所以，從設計結果角度出發，架構標準化主要是對數據和行爲的標準化，而標準化的範圍，從對設計結果應用的角度看，行業級的標準化是較爲合適的層級，這個層級具有合適的語境和語義範圍，也有行業術語作爲統一概念基礎。
1. 數據標準化
數據是計算機程序的輸入和輸出，也是不同程序模塊間進行銜接時必須要進行標準化處理的部分。在軟件設計中，接口標準化已經是大多數項目必備的設計要求。目前行業級的數據模型也有實例，比如 IBM 之前爲金融領域設計的 FSDM(Financial Services Data Model) 數據模型。
FSMD 是上個世紀 90 年代，IBM 針對金融行業建立核心應用系統或者數據倉庫推出的數據模型。作爲大機及大機開發服務的主要供應商，IBM 在這方面有獨特優勢，而金融行業也是大機的 VIP 級用戶，因此，IBM 根據其豐富的行業經驗設計這一經典的行業級數據模型。
FSDM 是一種分層級、逐級細化的數據模型，包括“ABCD”四個大的層級，具體分層如圖 1 所示：
FSDM 將數據分爲九個大的類別，各類別概念如表 1 所示：
九大概念之間具有一定的聯繫，其相互關係如圖 2 所示：
FSDM 金融服務數據模型定義了金融服務機構自身和業務運作所需的基本數據概念以及相互關係，包含銀行業的絕大部分數據。在實際設計中，數據模型會在九大領域下再細分爲不同的數據主題域，主題域包含數據實體，實體下包含數據屬性，從而自上向下完成對數據的企業級模型化梳理工作。
FSDM 模型證明，只要堅持積累和鑽研，構建一個具有一定影響力的行業數據模型是完全可行的，而且確實可以給軟件設計提供一定的指導和便利。
但是 IBM 當初畢竟是與其商業行爲進行一定的結合，有適當的驅動力。在沒有足夠商業利益結合的情況下，如何推動行業級標準化數據模型的建設是一個難題。此外，FSDM 更多承擔的是指導性作用，還沒有真的成爲標準，需要金融企業依據其指導建立數據模型並自行維護。
2. 行爲標準化
相較於數據標準化，行爲標準化更爲困難。如果想要建立對軟件設計起行業級指導作用的標準化模型，這個模型必須能指導細粒度的開發，而非僅傳遞到概念層級，如果比照工業標準的效果，應當可以指導或者直接生產出可供複用的軟件“零件”。
軟件設計一直在關注如何提升對已有軟件資產的複用，從對代碼的“複製粘貼”到模塊化、服務化、微服務化，通過對業務邏輯乃至數據封裝和接口開放，實現軟件資產的可重複利用。各種設計思路中，筆者認爲，構件化作爲推廣標準化的理念而言，也許是更爲合適的概念。
構件化設計，又稱 CBD（Component-Based Development，基於構件的開發）或 CBSE（Component-Based，基於構件的軟件工程）。關於該方法的討論比較早，文獻也較多，例如，Alan W.Brown 所著的《Large-Scale, Component-Based Development》（中譯本名稱爲《大規模基於構件的開發》，2003 年由機械工業出版社出版，趙文耘、張志等譯）。
按照構件化設計理念，構件可以獨立部署，但一個構件可能會用到其它構件或平臺提供的服務，或者說基於構件的軟件系統通常是多個構件協作完成一定功能，所以構件依賴於組裝環境或稱爲語境（context），而構件基礎設施應是支持異構構件互操作的標準和通信平臺，構件框架則是構件實例“即插即用”的支撐結構。
CBD 的實現方式之一就是大家耳熟能詳的——SOA（Service Oriented Architecture ，面向服務的體系結構）或者 SCA（Service Component Architecture ，服務組件體系結構）。從發展脈絡上講，1990 年左右就開始出現面向構件的技術思想，也即，編程方法在面向對象後是面向構件，然後纔是面向服務。
關於構件化設計，國家標準也早已有之，比如 GB/T11457-2006 軟件工程過程、GB/T36445-2018 軟件構件模型，都有相關技術標準約定，但是這些標準都未包含構件的設計方法，實踐中大家更關心的是如何做出標準化構件的方法論。
有人經常用“樂高積木”一詞來形容構件化或服務化設計方式，樂高積木之所以會吸引不同年齡段的人羣，並能讓大家充分發揮創造力，主要原因不外乎兩點：一是接口的高度標準化，可以簡單搭接；二是使用者能很輕易地理解每個積木塊，自由運用它。
構件模型設計的關鍵也在於這兩點。設計行業級標準化構件模型，首先是接口的高度標準化，這一點有賴於前文中提到的數據標準化；二是構件功能的標準化和可理解性，這就涉及到對業務行爲的標準化，或者說對各種同類型企業（也存在同類型企業中按照規模等級再細分的可能）的業務活動標準化，這種標準形成需要以業務爲核心的建模方法，也需要通過作爲參照系的標杆企業來提煉標準業務行爲。
在建模方法中，Alan W.Brown 在《Large-Scale, Component-Based Development》一書中給出的主要是基於 UML 的方法，該方法雖然與現實結合緊密，但對業務人員不夠友好；DDD 也是可以應用於構件化設計的建模方法，尤其是在以構建微服務爲應用方向運用 DDD 方法時，該方法也充分考慮了業務含義。筆者在《企業級業務架構設計：方法論與實踐》一書中提到的構件模型也是一種可用的構建方式，其優點是具有企業級視角，與業務和技術兩端結合緊密，也適合於推導行業標準模型這種精煉性工作。
綜上，數據標準化和行爲標準化的探索一直有人在進行，但需要更強有力的推動來真正形成行業級的標準，否則，軟件的發展有可能在“兇猛”的創新下反倒出現“作繭自縛”的情況。
3 行業級標準化的深遠影響
行業級標準化的價值有很多，比如有助於提升軟件資產的可重用性、提升軟件質量、減少不必要的改動、提升互聯效率、提高需求質量、提升需求形成效率等，這些價值很多文章都提出過，筆者在本文中想闡述一個目前較少提及的遠期價值：推動數字化思維轉型。
數字化時代是依靠大規模軟件生產支持社會生產的時代，如同今天工業的作用。而大規模軟件生產能力的形成需要與之相匹配的思維方式，人們的思維方式總是要與時代的主要生產方式相適應，當軟件成爲主要的生產方式時，結構化思維就成爲這個時代最基礎的思維方式，提升所有參與者的結構化思維能力是面向數字化時代最重要的思維轉型方向，包括業務人員的思維轉型和技術人員的思維轉型。
業務人員思維轉型，是指能結構化地看待業務、理解業務，結構化的業務視角更有利於將業務映射到技術實現，也更有利於業務人員較爲直接地應用已有的軟件資產，如同業務人員看到“樂高積木”，具備結構化思維能力的業務人員，更容易適應在數字化時代看到的“事物”和從事業務活動、開展業務創新的方式。
技術人員思維轉型，則是要能結構化地看待業務構成與技術實現的關係，從而更好地將業務分解成合適的“零件”，這是在技術人員原有結構化思維方式上的一種深化。對技術人員而言，這還意味着要更主動地去接受標準化的“約束”，從個體化的改進軟件向公用化的改進“標準”發展，這是數字化時代進行大規模軟件生產需要的技術思維方式。
換句話說，就是在業務側，應當能看到“業務服務化”、“服務編排化”，業務人員具有利用構件化軟件資產、協助生產構件化軟件資產的能力；在技術側，應當能看到“服務業務化”、“編排服務化”，技術人員具有按照業務含義準確設計標準化服務，將編排作爲一種服務向業務側提供的能力。
基於行業級標準化構件，我們應當能實現更爲標準化的企業架構，企業內部以行業級標準化構件爲基礎搭建軟件，而具備這樣標準化架構的企業也必然會成爲開放式架構中的標準化元素，實現行業級、社會級的開放互聯。如圖 3 所示：
儘可能以標準化組件支持企業商業模式的構建，能達成這樣的效果，軟件對企業生產的基礎性作用才能進一步增強，才能用軟件大規模覆蓋各類型企業的生產、管理，這正是數字化轉型的前提。
數字化不是一個企業自己的數字化，而是整個行業、社會的數字化，也是所有從業人員的數字化。精煉行業級標準化構件的過程，正是業務和技術兩側同時進行數字化思維轉型的過程。
數字化時代，各類企業都或多或少地轉型爲一家科技企業。數字化轉型完成，大家走到同一起跑線，今天所謂的“跨界者”，在數字化時代將不復存在。大家比拼的是快速創新商業模式的能力，快速創新離不開快速搭建。而快速搭建離不開對標準化資產的快速利用，對要素的獨特組合能力纔是大部分創新的主要表現形式，重複造輪子在今天也許還情有可原，而在數字化時代很可能就真是“無情的浪費”。
可以回想下，對精益生產過程探索的動力正是對杜絕“浪費”的執着，如果軟件生產想要靠近精益生產，那就從杜絕“浪費”開始吧。
4 行業級標準化的發展思路：大教堂與集市
Eric S·Raymond 所著的《大教堂與集市》被認爲是詮釋開源思想的最佳書籍之一。軟件系統的開發模式因此出現“大教堂”和“集市”兩種比喻，前者是傳統的、大公司的軟件開發模式，後者則是新興的、社區化的軟件開發模式。
行業級標準化這個想法，初次聽起來，很多人自然會跟“大教堂”聯繫到一起，畢竟行業級標準化聽起來就有很多“中心化”因素在其中，需要標準、跨企業共識、組織推動等等，而且，現有其他領域的標準化模式一般也都是“中心化”的，無論國內國外，國家標準都是標準層級中非常有影響力的部分。
軟件行業是否會有些獨特之處呢？當然會有，軟件是一組可工作的計算機代碼，而計算機代碼的特點是，很容易“沾染”開發者的個人特點，也很容易複製。因此，軟件製品同時具備“偶然性”和“難保護”的特點，也正是“偶然性”使軟件的創新比現有工業製品更容易。
儘管應當保護開發者付出的辛苦，但是無論是現有專利制度的效率，還是軟件保護本身給行業發展帶來的弊端，都足以讓所有人反思，軟件行業該採用什麼樣的方式走向標準化，走向數字化時代。
軟件行業從業者的核心競爭力到底是什麼？Paul Graham 在《黑客與畫家》一書中曾指出，解決困難問題纔是程序員最核心的競爭力，而這種能力並非來自於對代碼的保護。在國外，專利、收購、訴訟等都是大公司經常採用的保護手段，而非一個程序員可以輕易採取的手段。
解決困難問題的能力也並非是編寫“前無古人後無來者”的代碼，正如 Eric S·Raymond 所言，“好的程序員知道寫什麼，而偉大的程序員知道改寫（或者重複使用）什麼”。軟件行業進一步發展，進入大規模批量化軟件生成的數字化時代的前提條件，也許正是重新設置軟件行業的管理、保護機制，推動開源“標準化”模式的發展。
爲提高生產效率和軟件質量，我們需要通過開源模式，提升構件的標準化程度、可用性和易用性，建立國家運營的行業級開源構件庫，形成類似開源社區的機制。優秀程序員的價值既然可以通過在開源社區的影響力獲得，也一樣可以通過對行業級開源構件庫的貢獻來建立，優秀程序員依靠的並不是對他已有成果的封閉式保護。
對軟件開發企業而言，企業的核心競爭力也應當是其設計和集成解決方案的能力。從這個角度來講，構件的標準化和開源會對企業能力有更大的提升，“一招鮮吃遍天”並不是應該鼓勵的發展模式。
對應用軟件或者自主開發內部軟件的企業而言，軟件保護本就不應該是其業務的核心，軟件代碼不是可樂配方，一成不變的代碼不會爲企業帶來持久的競爭力，只會隨着時間的變化快速衰減。此外，架構並不是可以簡單照搬照抄的東西，開放架構設計未必會讓競爭對手快速趕超，不小心的追趕者甚至有可能掉進無意設置的“陷阱”。
未面向數字化時代深入思考的軟件保護機制也許更多隻是給行業籠罩了一層神祕面紗。“集市”方式並不適合直接孕育一套可用的軟件，開源“標準化”模式的建立也需要“第一推動”。“集市”方式成立的前提條件之一是要先提供一套可以運行的軟件作爲起點，開源“標準化”也需要逐步建立每個行業第一套可用的標準構件庫或者開源系統，然後再通過社區化方式不斷發展爲更具生命力的標準體系，這個“第一推動”和對構件標準體系的設計就是標準化組織的責任，這樣的組織也應該是公益性的。
未來的大規模軟件生產，也許正是用“集市”提供的構件建設“大教堂”的模式，基於這個認知，行業級標準化正是架構演進該有的趨勢。
作者介紹：
付曉巖，《企業級業務架構設計：方法論與實踐》圖書作者，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職於建信金融科技有限責任公司。即將發行新書《銀行數字化轉型》，公衆號：曉談巖說。
原文鏈接：