數字化中臺建設的過程與方法

轉載本文需註明出處：微信公眾號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/虛擬化、系統分析和架構分析；參與九江銀行持續整合專案、中投移動辦公平臺專案等服務治理專案諮詢工作。