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