前面，我們討論了基於構件模型支持細粒度組裝式開發、形成輕量級架構工具的方法，並闡述了通過產品目錄建設產品信息高速公路的設想，具備這一切條件之後，是否能夠進一步提升產品創新效率呢？這是很多企業都關心的問題，特別是總覺得比互聯網企業跑得慢的傳統企業。首先必須聲明，創新是一個複雜的大問題，人、制度、內外環境缺一不可，所以我不是在兜售“靈丹妙藥”，我只是從建設平臺化的產品創新能力這個角度，談談系統建設對創新能力的提升這件事。
從之前的介紹中我們可以看到“業務信息——產品目錄（標籤化）——產品——模板——構件——服務——項目信息”這樣一個完整的由業務延伸到技術的鏈條，這個鏈條上匯聚了對創新而言必備的主要信息，通過這個鏈條，關於一個產品的需求、設計、覈算、反饋、改進都能匯聚起來，因此，以這些信息爲基礎，是可以搭建一個產品創新平臺的。平臺的邏輯結構如下：
平臺的核心域爲產品研發域，研發域包括產品目錄和構件模型兩部分，前者是面向業務端的高維數據實現和信息匯聚，後者是面向設計和開發端的產品實現，這兩部分的內容之前的幾章已經介紹過就不再重複了。
平臺的支持域包括三個部分：
一、產品創意域。創意是產品的設計來源，很多企業都鼓勵內部創意，也有企業將創意管理系統化，在有產品目錄和構件模型的基礎上，可以更好地對產品創意進行分類，比如是對模板的創意、產品的創意、構件的創意或者憑空產生的全新創意，可以通過這些標籤更好地引導創意的流向。對創意的初步定位有利於創意的快速傳導，也考驗了整個企業對於業務模型這種通用語言貫徹的效果。如果有相當一部分業務人員都能夠了解自己領域的業務模型以及對應的到構件級的系統結構，那麼創新的效率一定會大幅提升。在大家倡導業務與技術深度融合之前，業務的歸業務、技術的歸技術，信息給到、互不干涉是開發中常見的情況，但是以後，隨着融合程度的加深，互相清楚對方在幹什麼、怎麼幹，是很有必要的。此外，除了全新的創意，還有些創意可能是基於業務需求形成的，這類創意可以建立與業務需求的關聯關係，以識別重複需求，這種關聯關係雖然不難建立，但是操作過程中卻可能由於錄入者嫌操作麻煩而被忽略掉。當然，出於成本的考慮，也可以斟酌要做到什麼程度。
二、產品評價域。產品評價也是大家關心的話題，不少企業爲此頭疼，有人搞高大上的理論結構，也有隻能看看報表、讀讀數的。產品評價不是件容易事兒，而更不容易的就是想搞企業級的，我原來所在單位也爲此頭痛不已。產品評價難的是指標體系，金融機構的產品差異大，搞出一套大家都認可的企業級指標體系不大容易，就像之前介紹的，產品分類都難以達成一致意見，何況這種直接跟工作業績掛鉤的產品評價呢。這方面，個人認爲，自上而下的去做企業級產品評價操作難度太大，還是DDD建模的理念靠譜，從單個領域出發，一個領域一個領域的構建評價模型，而領域內部則要一個產品一個產品地進行分類，歸類後，再一個類別一個類別地跟業務人員去嘗試建立評價模型。單產品的評價模型順利運行後，再逐漸彙集領域視角的評價方法。評價的數據來源通常爲生產系統或者數據倉庫的數據，考慮到部分產品的特殊性，可以附帶少量主觀評價指標。
三、產品運行效率監測域。這部分主要依賴於構件模型的特殊性，構件與服務之間有明確的聯繫，而構件可以按照執行順序形成設計視角的流程模型，這一點在之前有論述到。這種流程劃分方法爲監控每段流程的執行效率提供很好的依據，可以通過運維平臺的數據彙總出每段流程的執行時間、流程間的等待時間，以更好地分析流程的改進點，這比到櫃檯去現場計時要有效率的多，而且可以充分利用運維信息，隨時分析各地情況。
以產品研發域爲核心，產品創意域導入新需求、新理念，產品評價域考覈產品績效，通過產品串聯起需求、設計、評價的閉環，產品運行效率監測域則提供輔助的效率改進點。以這個抽象結構爲基礎的產品創新平臺應該可用於傳統企業的產品管理工作，但是在如何完善自身方面，還有很多需要進一步研究之處。
小結：對業務架構的再次思考
雖然做了六年的企業級業務架構，但是總覺得業務架構不是個好講的東西，業務架構離不開業務模型，所以講它就會搬出一堆枯燥的模型來，甚至會讓人覺得業務架構就是建模。但建模只是個手段，建模的目的是把現象總結成模式，再從模式中找到結構，將業務上看到的結構傳遞給技術，如果二者能夠基於同一結構思考，溝通上將產生最大的便利，這就是通用語言的基礎，其實說通用語言，還不如說通用結構，因爲說語言，經常會把人帶到語法層面，糾結於規則、概念、標準之類似是而非的東西。所以，我總結建模的原則無非是把握整體、穿透現象、保證落地，建模即不能死守規則、冥頑不化，也不能腦洞大開、信馬由繮，必須從一開始就關注如何落地。建模不是建個自圓其說的烏托邦，而是傳給後續過程的設計圖紙。業務建模可以有前瞻性，但是所謂的前瞻性是能夠看清分階段實施路徑的前瞻性。
業務架構是不斷演進和迭代的，它有生命力，可以成長，如果架構管理工具本身支持歷史記錄和模式比對，你也可以看到企業架構的演進歷史，而不是隻看得到現在，只能聽別人講講過去，過去是可以看見的。這種可視化的歷史是一種寶貴的學習資源，人是從歷史中學習未來的，畢竟有很多行業還是需要積澱的。
但是，業務架構的形成過程的確是在一種看起來科學的方法論下，不完全科學地操作的，這點我曾經也很糾結，後來軟件架構的書看多了，再加上到項目中的觀察，也逐漸釋然了。軟件架構其實很羨慕建築架構，覺得建築架構有力學基礎做支持，有很多可以計算的東西，但是軟件架構卻沒多少能算出來的。在開源思想時興之前，行業內部交流分享較差，都比較願意看別人的架構，而不想亮出自己的，很多研究者都抱怨這個非常需要標準的行業反倒是很隔離的。開源爲架構和軟件帶來新的成長方式，共享讓思維發展更快、普及更快，但是，軟件架構本身卻只是增加了大量的案例，依舊難以標準化，哪怕是同一個行業的企業，給這家做的軟件也不一定能直接搬到另一家去，很多商用化了的系統軟件也還是離不開個性的本地化改造過程。雲計算帶來的SaaS雖然讓軟件應用省去了許多部署過程，但是，依然難以改變這個行業個性化程度嚴重的局面。軟件架構尚且如此，業務架構也就不需要糾結了。
業務架構設計可以很快，也可能很慢。快無非是兩種情況，一是架構師自身爐火純青、天生慧眼，設計能力超強；二是原有業務模型已經很清晰，可以快速分析業務變化，形成架構設計，我們可以追求的是第二種，這也意味這首次建模，尤其是首次建設企業級模型，不要過快，對模型設計方法、業務流程分析、標準化過程，都要細緻點兒，基本功紮實了，纔有後邊的“敏捷”。企業級轉型沒有輕鬆的，不少企業是把轉型僅當成一個項目，而忽視了對自身的調整。一個普通士兵變成一個特種戰士，不是因爲給了他一身價值10萬的裝備，而是經過了地獄般的訓練。上至最高管理者，下至普通員工，人的思維不轉變，哪來的企業轉變呢？
爲了推動企業真正的數字化轉型，業務架構設計人員永遠不要忘記，業務架構最重要的職責不是傳遞需求，而是藉由自身的努力，推動業務和技術的深度融合，橋樑作用纔是業務架構最重要的職責，如果不能實現這一目標，也就不能真正實現一個快速響應內外部變化的企業級業務系統。
其實中臺並非萬能，客觀地講，一個優秀的架構設計人員是不會“迷信”於任何一種架構設計方式的，也不會執着甚至偏執於方法間的爭論，沒有哪種設計方式是完美無缺的，軟件行業沒有“銀彈”，任何一種方法都需要堅持與靈活的結合，都需要通過長期的實踐不斷總結和改良，如果一個方法沒有被堅持數年以上，可能連入門都談不上吧。我對中臺認識更多還只能算個一般觀察者，論述中難免有失，感謝讀者朋友們能夠寬容地看我一路“叨叨”下來。
相關文章：
中臺之上（一）：重視業務架構，不要讓“業務的歸業務、技術的歸技術”
中臺之上（二）：爲什麼業務架構存在 20 多年，技術人員還覺得它有點虛？
中臺之上（三）：戰略和組織結構，業務架構設計中不應被忽視的關鍵因素
中臺之上（四）：面對複雜的流程和數據，我們總結出了一個分析套路
中臺之上（五）：業務架構和中臺的難點，都是需要反覆錘鍊出標準模型
中臺之上（六）：如何爲一個商業銀行設計業務架構？
中臺之上（七）：不神祕但很麻煩的業務架構落地過程
中臺之上（八）：企業級業務架構的實現需要不斷溝通和調整
中臺之上（九）：如何基於企業級業務架構管理業務需求？
中臺之上（十）：業務架構設計“笨重”，它能跟敏捷沾邊嗎？
中臺之上（十一）：企業級業務架構設計的“五難”
中臺之上（十二）：如何快速設計業務架構？
中臺之上（十三）：探討支持組裝式開發的業務架構設計方法
中臺之上（十四）：嘗試構建輕量級架構設計工具
中臺之上（十五）：被忽視的產品目錄
作者介紹：付曉巖，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公衆號：曉談巖說。