作者 | 付曉岩
軟體設計面對的環境日趨複雜。對這種日趨複雜、難以駕馭的狀況，很多軟體人希望能有所改善。而标準化對提升架構設計效率和提高軟體開發成功率很有裨益。本文探讨架構演進的另一個趨勢，就是行業級标準化。
筆者在上一篇文章《關于架構演進發展的探讨》（又名《中台辨析：架構的演化趨勢》）中，總結了架構方法發展的三個趨勢：
1、從軟體架構到企業架構；
2、從内部架構到開放架構；
3、不同方法間的組合運用。
這些軟體設計面對的環境日趨複雜。背後原因不僅有技術發展本身帶來的複雜性，而且也有規模增大帶來的複雜性。
從最初面向小型群體、具體領域的程式設計，到面向上億使用者、交叉需求的生态建構，軟體設計似乎走上一條以複雜應對複雜的發展之路。我們看到，從方法到概念都日趨複雜。
一開始，很多軟體的早期版本較為清晰，後來逐漸走向“大泥球”模式。最終，它們“活成了我們最讨厭的樣子”。
“技術債務”成為軟體生命周期中的常見問題，是以，對軟體設計方法尤其是架構方法的探索始終未停。這些探索與軟體工程方法的演進互相作用。
對這種日趨複雜、難以駕馭的狀況，很多軟體人希望能有所改善。衆所周知，标準化對提升架構設計效率和提高軟體開發成功率很有裨益。在架構方法發展的過程中，關于這個方面的标準化努力也一直在緩慢推進。這個标準并非指軟體開發标準，比如國内的 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 所示：
圖 1 FSDM 資料模型的層級（來自網絡）
FSDM 将資料分為九個大的類别，各類别概念如表 1 所示：
表 1 九大概念（來自網絡）
九大概念之間具有一定的聯系，其互相關系如圖 2 所示：
圖 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 所示：
圖 3 以标準化為基礎的企業架構設計目标
盡可能以标準化元件支援企業商業模式的建構，能達成這樣的效果，軟體對企業生産的基礎性作用才能進一步增強，才能用軟體大規模覆寫各類型企業的生産、管理，這正是數字化轉型的前提。
數字化不是一個企業自己的數字化，而是整個行業、社會的數字化，也是所有從業人員的數字化。精煉行業級标準化構件的過程，正是業務和技術兩側同時進行數字化思維轉型的過程。
數字化時代，各類企業都或多或少地轉型為一家科技企業。數字化轉型完成，大家走到同一起跑線，今天所謂的“跨界者”，在數字化時代将不複存在。大家比拼的是快速創新商業模式的能力，快速創新離不開快速搭建。而快速搭建離不開對标準化資産的快速利用，對要素的獨特組合能力才是大部分創新的主要表現形式，重複造輪子在今天也許還情有可原，而在數字化時代很可能就真是“無情的浪費”。
可以回想下，對精益生産過程探索的動力正是對杜絕“浪費”的執着，如果軟體生産想要靠近精益生産，那就從杜絕“浪費”開始吧。
4 行業級标準化的發展思路：大教堂與集市
Eric S·Raymond 所著的《大教堂與集市》被認為是诠釋開源思想的最佳書籍之一。軟體系統的開發模式是以出現“大教堂”和“集市”兩種比喻，前者是傳統的、大公司的軟體開發模式，後者則是新興的、社群化的軟體開發模式。
行業級标準化這個想法，初次聽起來，很多人自然會跟“大教堂”聯系到一起，畢竟行業級标準化聽起來就有很多“中心化”因素在其中，需要标準、跨企業共識、組織推動等等，而且，現有其他領域的标準化模式一般也都是“中心化”的，無論國内國外，國家标準都是标準層級中非常有影響力的部分。
軟體行業是否會有些獨特之處呢？當然會有，軟體是一組可工作的計算機代碼，而計算機代碼的特點是，很容易“沾染”開發者的個人特點，也很容易複制。是以，軟體制品同時具備“偶然性”和“難保護”的特點，也正是“偶然性”使軟體的創新比現有工業制品更容易。
盡管應當保護開發者付出的辛苦，但是無論是現有專利制度的效率，還是軟體保護本身給行業發展帶來的弊端，都足以讓所有人反思，軟體行業該采用什麼樣的方式走向标準化，走向數字化時代。
軟體行業從業者的核心競争力到底是什麼？Paul Graham 在《黑客與畫家》一書中曾指出，解決困難問題才是程式員最核心的競争力，而這種能力并非來自于對代碼的保護。在國外，專利、收購、訴訟等都是大公司經常采用的保護手段，而非一個程式員可以輕易采取的手段。
解決困難問題的能力也并非是編寫“前無古人後無來者”的代碼，正如 Eric S·Raymond 所言，“好的程式員知道寫什麼，而偉大的程式員知道改寫（或者重複使用）什麼”。軟體行業進一步發展，進入大規模批量化軟體生成的數字化時代的前提條件，也許正是重新設定軟體行業的管理、保護機制，推動開源“标準化”模式的發展。
為提高生産效率和軟體品質，我們需要通過開源模式，提升構件的标準化程度、可用性和易用性，建立國家營運的行業級開源構件庫，形成類似開源社群的機制。優秀程式員的價值既然可以通過在開源社群的影響力獲得，也一樣可以通過對行業級開源構件庫的貢獻來建立，優秀程式員依靠的并不是對他已有成果的封閉式保護。
對軟體開發企業而言，企業的核心競争力也應當是其設計和內建解決方案的能力。從這個角度來講，構件的标準化和開源會對企業能力有更大的提升，“一招鮮吃遍天”并不是應該鼓勵的發展模式。
對應用軟體或者自主開發内部軟體的企業而言，軟體保護本就不應該是其業務的核心，軟體代碼不是可樂配方，一成不變的代碼不會為企業帶來持久的競争力，隻會随着時間的變化快速衰減。此外，架構并不是可以簡單照搬照抄的東西，開放架構設計未必會讓競争對手快速趕超，不小心的追趕者甚至有可能掉進無意設定的“陷阱”。
未面向數字化時代深入思考的軟體保護機制也許更多隻是給行業籠罩了一層神秘面紗。“集市”方式并不适合直接孕育一套可用的軟體，開源“标準化”模式的建立也需要“第一推動”。“集市”方式成立的前提條件之一是要先提供一套可以運作的軟體作為起點，開源“标準化”也需要逐漸建立每個行業第一套可用的标準構件庫或者開源系統，然後再通過社群化方式不斷發展為更具生命力的标準體系，這個“第一推動”和對構件标準體系的設計就是标準化組織的責任，這樣的組織也應該是公益性的。
未來的大規模軟體生産，也許正是用“集市”提供的構件建設“大教堂”的模式，基于這個認知，行業級标準化正是架構演進該有的趨勢。
作者簡介:
付曉岩，《企業級業務架構設計：方法論與實踐》圖書作者，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關系、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職于建信金融科技有限責任公司。即将發行新書《銀行數字化轉型》，公衆号：曉談岩說。
相關文章推薦：
關于架構演進發展的探讨