轉載本文需註明出處：微信公眾號EAWorld，違者必究。
目錄：
1.中臺的研發過程
2.中臺的研發方法
3.評估方法
《金融企業數位化中臺》整本書成體系的介紹了金融企業數字中臺的由來、迷茫、建設原則、業務中臺、數據中臺、技術中臺的建設要點和成熟度評估方法，洋洋灑灑幾十萬字，上百頁。所以本篇抽取其中的一部分：數位化中臺建設的過程和方法來重點分享。
1.中臺的研發過程
中臺的研發過程，總結起來分三方面：
1.藉助軟體產品線工程方法，實現大規模重用
對於金融企業來說大部分的軟體需求並不是全新的，而是已有系統需求的變體，傳統的軟體研發通常只關注某一具體應用領域，不斷地重複開發該領域已有軟體的變體，這些變體之間通常存在著大量的相似性，這為系統化和大規模軟體重用奠定了基礎。金融企業需要採用產品化思維，通過平臺來進行重用和擴展，支撐大規模軟體重用研發。產品線工程方法就是進行大規模復用的一種方法。
2.金融企業數位化中臺建設關鍵是實現可變性管理
金融企業數位化中臺建設的核心是重用，中臺的建設可借鑑軟體產品線工程方法實現大規模的軟體重用、保證高質量的新產品開發。軟體產品線的關鍵問題是如何進行可變性管理，並基於可變性管理實現軟體核心資產的復用，因此金融企業數位化中臺建設關鍵也是實現可變性管理。
3.實現可變性管理需要將領域工程和應用工程分離
可變性管理是對產品線範圍內的通用資產和可變資產進行管理，並將可變性建模的成果透出給應用，用於應用的個性化業務的配置。建立企業級可重用能力將是金融企業數位化中臺建設的主要手段，企業級可重用能力的建設可藉助軟體產品線工程中重用的指導思想，依託可變性管理方法，將數位化中臺分為領域工程與應用工程來實現軟體大規模重用的開發。領域工程是開發以重用，基於領域工程將建設可重用的共享服務中心，提供通用的業務流程和服務，並提供可變的業務定製點，用於應用工程系統化的、一致的軟體重用。領域工程職責是定義主題數據並根據主題數據切分共享服務中心，實施標準化、端到端業務流程，並發布應用工程可復用的業務組件。應用工程是使用重用來開發，應用工程從領域工程的共享服務中心中獲得可復用的流程和服務，使用其中可變的業務定製點，實現特定業務需求的個性化實現，從而構建出個性化的前臺業務應用。應用工程職責是在利用領域工程提供的標準化、端到端流程，細化分析差異需求，通過個性化的可變點實現，完成個性化業務定製。
金融企業建立產品線時應先由產品經理制定詳細的「業務方案」，「業務方案」是一個全方位的產品規劃，包含目標客戶、核心價值、解決方案、渠道、合作方、考核指標、競爭分析、收入分析和成本分析等。從業務的構成看，銀行的業務方案可分解為客戶交互（渠道）、金融產品服務、產品營銷、產品運營、風險控制等部分，當一個業務方案提出後，需要明確業務在哪些渠道完成，本渠道如何交互，跨渠道如何協作；業務由哪些產品提供，這些產品需要哪些個性化要求；該業務通過何種營銷手段觸達客戶；渠道接受客戶請求後，企業內部所需的運營流程如何；該業務有哪些風險控制因素，如何控制風險。
編制系統需求時需要由中臺架構人員根據重用的指導思想、依託可變性管理方法，將需求拆分為領域需求和應用需求，並梳理領域需求中可重用的能力，決定是否需要領域工程研發新的組件。
領域工程研發過程分為領域需求、領域設計、領域開發等，最終交付可重用資產，並通過「可變管理」將「通用資產」（指在業務中臺建設過程中具有普遍應用價值的通用流程、服務、組件或工具類等）和「可變資產」（指在業務中臺建設過程中在時間、空間、角色、業務、技術等方面存在個性化差異的擴展主題）透出共享服務給「應用工程」，而應用工程在應用需求梳理、應用設計和應用開發時復用領域工程的通用資產，同時部分復用可變資產，然後通過個性業務定製，發布應用服務。
「業務需求」 是對業務目標、業務流程、業務實體類型和決策過程的業務模型的分析描述。業務需求需要描述清楚業務目標、業務辦理的流程、業務辦理的條件等。在需求階段，我們需要充分分解領域業務目標和應用業務目標，抽象可重用的業務流程和定製化的業務流程，透出共享服務，復用可變資產，建立領域需求與應用需求在需求層面的溝通體系。
在設計階段，我們需要全面闡述業務中臺建設的「體系結構」。「體系結構」是通過特定結構組合起來的 IT 系統架構，可以分解為業務架構、數據架構、應用架構、技術架構、部署架構，和技術中臺對應的是技術架構，技術架構又可以分解為應用集成架構、應用技術架構和基礎設施架構等。
「組件」是用來復用的，從功能的角度可以分為業務組件和技術組件，業務中臺中提供的主要是業務組件，技術組件是從技術角度看的復用，我們可以分為基礎設施（伺服器、存儲、網絡等）、基礎軟體（資料庫、作業系統等）、集成組件（門戶、企業服務總線、文件傳輸等完成應用間集成功能的軟體）、其他技術組件等。
2.中臺的研發方法
在研發過程中需要解決的核心問題是領域工程和應用工程的業務需求溝通、體系結構的設計和交付可重用的組件，為了更好地藉助領域工程和應用工程分離實現可變性管理，研發過程中也需要藉助一些成熟的研發方法，包括需求的結構化描述方法、參考「4+1」視圖和四色原型法進行體系結構設計、軟體持續交付的方法與規範、行為驅動的軟體測試方法，以及業務可變性分析的方法等。
結構化描述業務需求：
舉個簡單的交易前檢查的例子：
V1.0 ：必須是登錄的用戶才可以進行交易；必須是未懲罰、未凍結的用戶才可以進行交易；
V1.1：海外登錄的用戶IP不能是「XX.XX.XX.XX」；
V2.0：金額大於1000元需要簡訊驗證碼確認，單日限額10000元；
V2.1：簡訊驗證金額、單筆限額、單日限額可以由用戶調整……；
V2.5：轉帳給曾經轉帳用戶小於2000元無需簡訊認證……；
V3.0：購買行內理財產品僅需輸入密碼確認；購買三方理財產品需要簡訊驗證……；
V4.0：久眠戶交易必須增加實名認證和生物識別，且金額大於500元需要審批。
需求分析是軟體工程中的一個關鍵過程，也是一個複雜的過程。需求的管理與各個應用的特徵密切相關，同時還涉及非功能性需求及其與功能性需求的錯綜複雜的關係。需求需要方方面面的人員參與，業務部門是需求的發出者，需求分析人員是需求的接受者，開發人員是需求的執行者，只有三方人員對需求的理解達成一致才能開發出成功的軟體產品。但這三種人員由於背景知識不同、擅長的領域不同，通常不能完整、正確地了解對方領域的知識，再加上溝通的不充分，最終導致需求理解存在偏差。
4+1視圖：
一個軟體的架構要涵蓋的內容非常多，很難一蹴而就，因此多採用分而治之的辦法從不同視角分別設計。目前軟體架構設計常用模型就是視圖模型，可以從多個角度描述一個複雜的軟體系統，分而治之下一個架構視圖是從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，所以我們建議4+1視圖的方式：
1. 邏輯視圖：當採用面向對象的設計方法時，邏輯視圖即對象模型。邏輯視圖關注功能，不僅包括用戶可見的功能，還包括為實現用戶功能而必須提供的「輔助功能模塊」；它們可能是邏輯層、功能模塊等。
2. 開發視圖：描述軟體在開發環境下的靜態組織。開發視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將運行於其上的系統軟體或中間件。開發視圖和邏輯視圖之間可能存在一定的映射關係，比如邏輯層一般會映射到多個程序包等。
3. 運行視圖：描述系統的並發和同步方面的設計。運行視圖關注進程、線程、對象等運行時概念，以及相關的並發、同步、通信等問題，和開發視圖相比，運行視圖比較關注的正是這些運行時單元的交互問題。
4. 部署視圖：描述軟體如何映射到硬體，反映系統在分布方面的設計。部署視圖關注目標程序及其依賴的運行庫和系統軟體最終如何安裝或部署到物理機器上，以及如何部署機器和網絡來配合軟體系統的可靠性、可伸縮性等要求。和運行視圖相比，部署視圖重視目標程序的靜態位置問題，是綜合考慮軟體系統和整個IT系統相互影響的架構視圖。
運用「4+1」視圖方法可以針對不同需求進行架構設計，「4+1」視圖模型實際上使得有不同需求的人員能夠得到他們對於軟體體系結構想要了解的東西。系統工程師先從部署視圖，然後從運行視圖靠近體系結構；最終使用者、客戶、數據專家從邏輯視圖看體系結構；項目經理、軟體配置人員從開發視圖看體系結構。
「4+1」視圖可以全面闡述中臺建設的體系結構，運用「邏輯視圖」講述中臺分解方式、模塊層次關係、依賴關係；運用「運行視圖」講述應用系統內外的運行期交互模式，柔性價值等；運用「部署視圖」講述中臺進程在機器上的安裝部署，並和網絡等配合滿足軟體系統的可靠性、可伸縮等要求。運用「開發視圖」講述開發視角的組織管理形式、技術框架支撐等。運用「關鍵過程」講述業務中臺的研發交付機制。
四色原型：
四色原型是領域模型的一種原型，領域中的任何模型及其關係都可以抽象為「四色原型」。四色原型可以用這句話進行描述：某個人（Party）的角色（PartyRole）在某個地點（Place）的角色（PlaceRole）用某個東西（Thing）的角色（ThingRole）做了某件事情（MomentInterval）。
1）時刻-時間段原型（Moment-Interval Archetype）：表示在某個時刻或某一段時間內發生的某個活動。使用粉紅色表示，簡寫為MI。
2）參與方-地點-物品原型（Part-Place-Thing Archetype）：表示參與某個活動的人或物，地點則是活動的發生地。使用綠色表示。簡寫為PPT。
3）描述原型（Description Archetype）：表示對PPT的本質描述。它不是PPT的分類！Description是從PPT抽象出來的不變的共性的屬性的集合。使用藍色表示，簡寫為DESC。
4）角色原型（Role Archetype）：角色就是我們平時所理解的「身份」。使用黃色表示，簡寫為Role。
四色建模是建立在UML基礎之上的一種新型建模方式，在建模過程中需要按照四個步驟來完成業務領域的建模工作：
1）分析業務流程，確認流程中的關鍵名詞，抽象出業務實體；
2）從用例入手，找出其中的紅色；
3）找出其中的相關元素；
4）細化每一個類的方法和屬性。
這四種類型不僅規定了各種類的屬性和方法，而且也蘊含了不同原型間的典型交互方式。通過彩色編碼不僅有利於開發組中各種人員的溝通，而且還可以加深開發人員對領域問題的理解，從而保證開發可以按照分析階段的領域模型正確地進行開發。
軟體持續交付的方法與規範：
採用中臺架構後，各業務系統將從原來一個巨石型系統發展為大量的服務，服務可以獨立部署與發布，降低了系統耦合度，水平擴展能力得到顯著提高，但也帶來交付與運維複雜度增加的問題。中臺建設需要建立持續交付的方法與規範，將需求、設計、開發、交付、運維的過程協同與配合，用於促進應用開發、技術運營和質量保障各職能之間的溝通、協作與整合，通過優化開發（DEV）、測試（QA）、運維（OPS）的流程，使開發運維一體化，通過高度自動化工具與流程來使得軟體構建、測試、發布更加快捷、頻繁和可靠。
首先需要建立敏捷的項目管理方法。敏捷的項目管理方法以需求進化為核心，採用迭代、循序漸進的方法進行軟體研發管理。項目不再採用瀑布式的模式，而是被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特徵。分布式應用讓應用、服務、數據、感知都可以獨立發布、部署、運行，可以把一個大的業務系統項目分為多個相互聯繫但可以獨立運行的小項目，並分別完成，在此過程中軟體一直處於可使用狀態。支撐平臺支持這種敏捷的項目管理方法，幫助業務系統研發團隊管理需求與設計，建立需求、設計與開發、測試的關聯，分配任務並跟蹤進度，有效整理與跟蹤出現的問題，對團隊行為進行記錄，通過看板方式可視化團隊活動，提高各業務系統項目的項目管理水平。
其次要建立持續集成能力。持續集成可幫助業務系統的研發團隊經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，支撐平臺聯接統一的代碼庫，調用研發人員編寫的編譯腳本、自動化測試用例進行自動構建與自動測試，通常每次代碼遞交後都會在持續集成伺服器上觸發一次構建，可以在模擬生產環境中自動測試。研發人員需要保證每次構建都要100%通過，每次構建都可以生成可發布的產品。持續集成有利於檢查缺陷，了解軟體的健康狀況，減少了代碼編譯、資料庫集成、測試、審查、部署及反饋中的重複勞動，同時對功能完成度和缺陷率等項目的狀態自動產生有效的報告，提高了軟體研發的質量。
最後要實現一鍵式部署與持續交付。業務系統開發過程中，往往存在多個環境，包括開發環境、測試環境、預發環境、性能測試環境、生產環境，研發人員需要將代碼、配置、類庫等部署到多個環境中，遇到問題需要回退到前一個狀態，手工操作是一個非常繁瑣的過程，通常研發人員會編寫部署腳本進行一些自動化的操作，但是這些腳本又缺少規範與管理，無法成為統一、一致的行為。通過支撐平臺，研發人員可以自定義部署過程，實現一鍵部署、一鍵供應、一鍵創建新環境，環境的創建可以通過一條命令或一鍵點擊的方式創建，減輕運維人員的負擔，避免錯誤，縮短業務系統上線的周期。一鍵式部署讓持續交付成為可能，通過更頻繁的自動化部署，業務系統新上線的功能可以儘可能快地呈現在用戶面前，並能在一定的時間內從用戶處獲得儘可能多的反饋，根據反饋更快速地對新業務功能進行調整，從而加快業務系統交付的速度，適應業務變化。
行為驅動的軟體測試方法
傳統軟體研發模式的問題在於業務人員把業務需求描述給軟體需求分析人員之後，軟體需求分析人員按照自己的理解編寫軟體需求規格說明書，然後研發人員根據軟體需求規格說明進行軟體架構設計和編寫軟體代碼，最後測試人員根據軟體需求規格說明書編寫測試案例進行測試。由業務需求到軟體編碼，再到軟體測試的過程中，不同角色和不同人員在不同時段對軟體開發所需的信息進行處理，這中間有太多可能的機會丟失、弄錯甚至直接忽視業務人員的原始需求。軟體研發的眾多環節中，只需一個環節出錯，軟體研發團隊就很難按時交付出符合業務人員要求的軟體產品。
行為驅動開發（Behavior Driven Development，BDD）是一種敏捷軟體開發的方法，它鼓勵軟體項目中的開發者、QA和非技術人員或商業參與者之間的協作。應用在自動化測試中也可稱為行為驅動測試。BDD借鑑了敏捷和精益實踐，讓敏捷研發團隊儘可能理解產品經理或業務人員的產品需求，並在軟體研發過程中及時反饋和演示軟體產品的研發狀態，讓產品經理或業務人員根據獲得的產品研發信息及時對軟體產品特性進行調整。BDD幫助敏捷研發團隊把精力集中在識別、理解和構建跟業務目標有關的產品特性上面，並讓敏捷研發團隊能夠確保識別出的產品特性被正確設計和實現出來。
BDD的軟體研發過程是這樣的：
產品經理（業務人員）通過具體的用戶故事使用場景來告訴軟體需求分析人員他（她）想要什麼樣的軟體產品。使用軟體產品的使用場景來描述軟體需求，可以儘可能地避免相關人員錯誤理解軟體需求或增加自己的主觀想像的需求。
軟體需求分析人員（BA）和研發團隊（研發人員、測試人員）一起對產品經理（業務人員）的用戶故事進行分析，並梳理出具體的軟體產品使用場景舉例，這些場景舉例使用結構化的關鍵字自然語言進行描述，例如中文、英文等。
研發團隊使用BDD工具把用戶故事場景文件轉化為可執行的自動化測試代碼，研發人員運行自動化測試用例來驗證開發出來的軟體產品是否符合用戶故事場景的驗收要求。
測試人員可以根據自動化測試結果開展手工測試和探索性測試。
產品經理（業務人員）可以實時查看軟體研發團隊的自動化測試結果和BDD工具生成的測試報告，確保軟體實現符合產品經理（業務人員）的軟體期望。
BDD並不是一種軟體研發方法，也不是用來替代Scrum、XP、看板等現有的敏捷理論和方法，而是把現有的工作方法融合起來，讓軟體研發團隊更加高效地工作，從而減輕因軟體產品計劃延誤或功能缺失帶來的壓力。
3.評估方法
雷達型階段模型中，BAPO評估模型覆蓋了軟體工程的業務支撐、架構支撐、軟體過程、組織保障四個維度，每個維度有五個級別，可以全面、科學地對軟體產品或產品線的研發能力進行指導和評估，同時CMMI模型主要用於對軟體過程改善和軟體過程評估，對軟體開發流程中的需求開發階段有較好的參考價值。
在金融企業中臺建設中，我們認為存在四個相互依賴的中臺開發問題，即：業務支撐：如何從中臺產品中獲利；架構支撐：構建中臺的技術手段；軟體過程：中臺開發中的流程、角色、職責和關係；組織保障：角色和職責到組織結構的實際映射。這四個問題互相關聯，一個維度的變化會引起其他維度的變化。業務支撐是最有影響力的因素，必須優先考慮；架構支撐反映中臺軟體結構和規則中的業務問題；軟體過程構建由架構支撐確定的中臺產品；最後，通過組織保障執行軟體過程。
為確保評估的準確性，我們結合自身在金融企業信息化建設多年的經驗，綜合分析後選擇的國際先進BAPO評估模型是最符合金融企業中臺建設的評估模型，該模型提供了一個基於軟體工程成果的過程能力階梯式進化的框架，可基於BAPO模型對金融企業中臺建設進行全面且深入的評估。
參考資料：《金融企業數位化中臺》，歡迎採購閱讀。
關於作者：魏鵬，金融研究院，擅長DevOps、基礎架構層IaaS/PaaS/虛擬化、系統分析和架構分析；參與九江銀行持續集成項目、中投移動辦公平臺項目等服務治理項目諮詢工作。