付曉巖 技術瑣話

本文為付曉巖老師在“技術瑣話”的直播整理，感謝付老師的付出。

今天說一說，咱們這個主要內容，主要分成這麼三個部分，

第一部分是軟體工程與企業架構方法論的發展。

不管是我個人寫的這些文章提到的這些個方法，還是中臺，都是從以往的方法發展到現在，也就幾十年的歷史。所以大家研究方法論也好，或者是看一些現象也好，如果你希望對這個現象的瞭解更深刻的話，那最好的還是要從這個方法的歷史開始瞭解。

第二部分，是關於這個企業級業務架構方法的介紹。

然後下一部分就是最後一部分，實際上是對這個企業架構的角度談這個中臺，我認為他就是企業架構範疇內的，所以第三部分：從企業架構角度談談中臺。

先說說第一部分吧，大家可能都知道軟體開發裡面其實有兩個核心問題，或者說兩個關注點也行，一個是軟體過程，就是這個軟體是怎麼造出來的，那從頭到尾這個全生命週期的多少什麼樣的。

那麼下一個就是軟體設計。這個軟體設計其實是軟體過程中的一個環節，但是這個環節比較重要，所以其實我們可以把它單獨提出來看一下，也就是軟體開發裡面其實有這麼兩個關注點或者是兩個重要的方向，一個方向是過程管理，一個方向就是關於設計。

軟體開發中的兩個關注點

工程裡邊，其實我們主要關注的就是工序和標準，類似於這些內容吧。

這個其實跟我們做一些工程管理或者其他其他行業融的專案管理其實是一樣的，都是關注做事情的順序，以及每一個步驟應該達到一個什麼樣的交付條件，這樣就是工序和標準，其實有了這個才能算得上是工程上的管理，不管是我們做這種傳統的傳統方法還是做敏捷來講，我覺得大家怎麼都需要關注這個東西，那麼我們關注這個工序和標準，其實在的目標是為了什麼？目標一個是為了提高這個軟體的質量，再一個呢就是產量。其實產量換一個角度說了就是速度。

然後在設計這一側，其實設計裡邊最難的部分應該就是架構設計，那麼架構設計了它的核心點，我個人認為簡單的來看就是結構和關係，也就是你把一個軟體，切成多少個部分，我把一個專案分成多少個部分，然後每個部分之間如何互動的，是一個什麼樣的關係，然後你怎樣處理這個關係比較合適。

那麼做架構的目的是什麼呢？我個人認為第一點是為了復現，其實做架構的時候，我們相當於是把人家客戶的要求啊，或者是業務人員的要求，很清晰的結構化的理出來。

理出來之後，讓這個清晰的結論確認他能跟業務的要求是一致的，所以我們做軟體其實大部分情況下你做的都是復現型的這種軟體，是突破型，那其實並不多突破型的，第二我覺得是就是技術人員對業務參與很多了之後，業務融合比較深的情況下，你才真正會產生一些是為了突破型的，是大部分情況下也是有其他很多傳統企業裡邊，做的這個軟體設計其實都是復現型的業務人員的這個需求，聽清楚了之後跟業務人員溝通好了，然後把這個業務需求復現出來。

那麼架構還有一個好處是什麼呢？就清晰的架構，還有一個優點就是有利於複用。

復現和複用，其實對我們這個質量和產量也是有影響的。那麼今天看起來呢就是這個軟體開發的關注。這兩點的話，大家已經學上去自然的一件事了，是吧？

但實際上在整個這個軟體行業的發展過程裡邊，這麼自然的一個事情，卻是很長時間才發展起來的

一九四六年第一個可程式設計的計算機誕生，這塊兒可程式設計的計算機誕生，就是軟體上也帶上了唄，對吧？那軟體兒的生產過程其實意思是比較粗放的，就是今天也有人還在用這種方式來生產，就是先寫了再說。先寫完再說，一開始的時候，因為沒有相應的管理理念，說有這種思路是有一種思維是很正常的。然後就出現了我們所說的軟體危機吧。

軟體工程和企業架構模型的發展

做軟體人們關注四個維度，時間，範圍，成本，質量，所謂的危機就是這四樣沒有一樣的控制住，所以大家又覺得該反思一下應該反思一下去組合什麼，怎麼做軟體是對的。於是就產生了這個第一個模型就是瀑布模型，這個模型是70年提出來的。

這個模型非常直觀，大家能看出來軟體開發到底有什麼東西，然後一開始咱們做軟體，肯定這個就是軟體上是兩條線嘛。

因為過程的線，一個是架構的線，那麼架構的線更慢了，過程那條線是二十多年才發展處一個模型的，那麼架構這條線都快四十年了，

一個相當大的一個變化，就是企業加入這種模型，從軟體自身的一個侷限，跳脫到對企業的關注了，實際上對於一個企業架構是花了四十年才誕生的，那麼咱們這個架構了，其實只是一個框架，就是它是六行六列的，這六行就是六個檢視，然後那個六列其實相當於六種不同的視角，就是每六個視角構成一個檢視，加在一起，這塊兒就是說你在B端做軟體，不是隻看需求，不是隻看一個功能，你應該看企業整體，就是我們做軟體是為了企業整體的管理服務的，在這個基礎上你才能真正做好B端軟體，那麼這個思路應該算是一個開創性的思路了。

那麼這兩條線，隨著時間推移還是繼續發展，就是大家有了初步模型，儘管算是有了一個工程模型了。但不是很合適，因為這瀑布模型太慢，不到交付，看不到東西，所以有人就給他改進了一下，變成了螺旋模型。

這螺旋模型就是對著原型去設計，每隔一定時間交付一次模型，但是好像這個螺旋模型人員每次交付都是全量，這是一次一次的話，那這樣的話就是解決了一下這個軟體看不著這個問題。螺旋模型與TOGAF模型這兩個模型很好，很全面，但是落地比較困難，維護成本高。

所以軟體工程的發展趨勢是組合拳。

這個模型重點就是屬於敏捷，有的時候大家就是在整個產品集做出來之後，對這個功能規劃提出來之後，就在這功能裡邊開啟，然後就把這功能裡邊羅列出來，然後就開始計劃後開始快速迭代。

尤其的好的傳統企業做敏捷做的不太到位的時候，就就記住這一個速度，就看中了這個兩到四周的速度，其實對這個過程來講是不完整的，也是有缺陷的，那麼敏捷過程來講，其實在這兒在這兒它稍微有一點弱項，因為他沒有給出一個好的有列控能力點的方法，他主張的是頭腦風暴，大家在一塊兒快速講，反正他第一版那個東西做得有缺陷也沒事。我可以後邊留一把這缺陷補充。

就是說這塊兒其實缺少一個紮實的方法。所以有人提出了DDD領域驅動開發，提的這種設計方式他認為跟敏捷很配。因為他這個方式其實對於做其實他也算是分期的方法，那麼這種方法你覺得操作性的速度的，如果做的熟練的情況，操作起來速度確實很快，而且隔開，而且跟後面設計的直接對應，所以他確實能解決這個層面。

但這個方式一開始出來的時候不是太好理解，所以技術人員並沒有把它拿起來用，就是沒有一開始就讓那個敏捷配上，這到什麼時候呢？到這個後邊這個微服務架構出現之後，這個微服務架構出現之後，大家就會服務確實挺好，整個上線速度挺快，跟敏捷開發是被說這塊程式碼寫的快，這邊部署也快。

嗯，但這就有一個問題，就是大家也都知道啊，這個微服務，問題就是多大的服務叫微服務，什麼叫微服務，我們怎麼切分企業的服務，就是這時候大家又想起來說，那是不是可以再走一走的這個層面。那麼有人又專門去寫著怎麼用給你一種方式DDD來設計為微服務，所以就這幾種方向之間是可以組合在一起去共同來提升這個軟體開發速度。

雖然是一個組合拳吧，就是敏捷方法，就用的是過程管理，然後DDD注重的是產品的架構設計，然後微服務是支撐他這個實踐。

那這塊我們也看到了一個趨勢，就是剛才我們說從軟體架構到企業架構，這是一個架構發展的趨勢。另外一個趨勢就是出現這種架構方法之間的組合是，大家越來越覺得說一個方法去把他填一下，不一定合適。你能大一統的方法不一定合適，那麼我們可以發了各種方法的優勢，各種方法結合起來，解決我們面對的種種複雜問題，那麼最終組合拳，就是現在有一種例子，其實我個人覺得這種這種方式本身也非常好。

而且做方法論呢其實你也需要有這種態度，方法論上的不是用來吵架了，做方法論了，其實最重要的是給你一條主線，去吸收別人的優秀經驗和你自己的經驗，方法論之間互相之間並不是排斥，它只是給你一種吸收經驗的指導。

這個工程剛才咱們說敏捷那一塊的工程發展呢，如火如荼的，但是這個就是咱們是傳統的一個笨重的架構領域啊，這個架構領域後邊相對就慢了一些。

在這裡講一下DoDAF的，這個架構這種總結起來，其實主要就是他用換了一個視角去看架構這個問題，就是說他不太限制軟體上設計。他關注的是什麼呢？關注的是資訊，就是資料。它強調說用體系結構資料取代體系結構產品就是做出一套類似於資料模型的東西。

那麼上面我們就是簡單回顧了一下這個軟體工程和軟體架構的一個發展過程。

企業級業務架構方法論的介紹

接下來我們來看一看企業級業務架構方法論的介紹。

關於數字化，砸煙囪，複用，雙模開發，減低成本，企業轉型這些困難，我們是否可以找到一個共同的發力點來解決這些問題呢？那咱們做計算機的一直有這種抽象思維，在不同的問題裡面找到共性的東西，那咱們可以挑一個發力點，透過問題的解決，讓咱們的問題都有一個好的解決方法，為一些問題的解決提供一些支撐，那麼這個問題我們又回到了企業的發力點上，做企業就要關注企業管理，那麼我們這個找到所有問題的共同點，那其實就是提高企業的整體性。

那我現在也覺得就是網際網路企業的成功其實被一些宣傳誤讀了，大家就會覺得是網際網路企業就是快速的試錯，然後賭中一個就發達了，那麼跟傳統企業的注重整體性沒有關係，那我個人的觀點其實不是這樣的，雖然我個人不是這個網際網路行業的，我是傳統行業的，但是咱們群裡有一些人是網際網路行業的，那麼我們企業肯定是要做整體管理的，這種企業管理邏輯我們是打破不了的，你到了數字化時代，我們這種邏輯也是打破不了的。所以我覺得這個所有問題的共同點還是如何用一種方法來提高企業的整體性，如果能提高企業的整體性的話，那左邊的問題都能得到一定程度的解決。

那麼這個方法是什麼呢？那這個方法自然是企業級業務架構。

這張圖的其實就是我給出企業級業務架構的一個定義。那麼我給的定義是操作性的定義，那麼你為了落地企業的戰略，對企業的能力進行整體的規劃，並把它傳遞到it端實現的一個結構方法，那麼一個關鍵詞就是整體規劃，對企業進行整體規劃，然後傳遞的it實驗，那麼最終我們所需要的就是結構化，那麼你落地企業戰略的首先是要對戰略進行把一個大的戰略化整為0，化成一個小的需求，畫成一個一個清晰的戰略能力需求，這樣我們才能一個一個往下落。否則的話，這個戰略就是一堆漂亮的PPT，往牆上一貼就沒事了。當然我們在執行的時候，我們還要去找能力的執行者，要找有能力的人來完成這一個戰略的落地實現。

那我們先需要把現有的業務先解構了結構了，然後跟這個戰略能力去做一個對比，然後跟我們現有的業務競爭進行一個對比，哪一些業務是需要砍掉的，那些業務是保持不動的，哪些業務是需要新增的？

先把現有的業務結構了，然後從結構到結構，我們就有了一套新的結構。那麼這一塊其實已經融合了戰略能力的需求進來，可能更具體的，那麼這個時候我們在it那邊實現的話，就會發現與任務已經匹配上了。

那我這一個業務架構最大改進之處就是強調業務架構的獨立性。

那麼剛剛那張圖我們可以回憶一下，就是從戰略到業務再到it我們來看一下就是戰略到業務，我們是不是可以發現業務架構可以獨立的解決戰略的問題，那本來這種融合了業務能力的需求，也不需要每個人都會開it開發的。所以理論上來講，業務架構的範圍給那個it開發的比it開發的範圍其實是要大的。我們會融合一些線下的任務任務，比如說一些不需要it支撐的任務，但這些業務互相之間都有關聯，業務架構分析的是一個完整的業務視角，他其實解決的是管理問題，所以業務架構我認為它是可以進入管理裡面的，幫助業務一策，把業務理清楚，最終生成這種業務能力。

包括很多人都想做中臺，那很多人就會問的一個問題，就是中臺裡面會放什麼，包括中臺的那一套技術，你只要有錢，然後你的工作人員有技術，你就可以獲得，就像你拿了一把槍一樣槍裡面沒子彈，你拿了業務之後你沒有你沒有業務的話，你會發現槍裡面是沒有子彈的，那光有it這個容器沒有業務，那麼這個軟體資產其實沒有價值的，所以說業務架構對於IT架構來說，它是架構的真正的靈魂，它梳理的是裡面真正有價值的東西。

業務架構的一般設計過程

那接下來我們來看一下業務架構的一般設計過程，那麼業務架構是一個有實操性的東西。真正做業務架構這種分析的話，它是需要有案例來支撐的。對今天這個分享到給我說的這一個分享，其實更多的還是讓大家理解這個方法的作用和它的總體過程。

我們會看到戰略設計變革組織設計，組織設計影響戰略設計，業務分析推導元件設計，元件設計最佳化業務分析。戰略與組織設計約束業務架構設計，業務架構設計實現戰略與組織設計。

接下來我們看一下設計起點：戰略分析。

那麼我們其實能看出來底下這個就是商業畫布，上面這個就是房頂是戰略部分，這個家的房子，其實他的目的是為了做一個沙盤推演，透過這種沙盤的方式來定戰略，這是可執行的。

接下來我們看一下加強協同，組織分析。我們看到企業級前與企業級後是有很大的區別的，加強協同需要各部門的配合，或者需要強有力的領導的支援，加強協同後其實我們很容易就意識到協同的好處與便利，隨著時間的推移，這些便利會一步一步加強。

接下來我們來看一下流程設計：價值鏈分析。

價值鏈就是讓企業各個領域意識到我就是這麼創造價值的，我這個企業總體而言就是這麼創造價值的，然後你自己看看你這個領域是怎麼按照這條路徑走的。

這是一個思維對標過程，簡單規劃完之後，就是你各個領域就是按照這個價值量去把你的業務活動，我們分環節每個環節裡邊到底有多少個業務活動，而每個使用者，用這種方法去把它展開，看下邊有多少個任務要設計多少個，結算多少個任務，其實這塊是一個傳統的一種分析，如果單看這個的話，我們這方面就沒什麼。

這個方法的分析就是流程的資料的結果，也就是說我們畫一個任務的邊界或者判斷一個任務，到底是不是一個評定企業業績唯一的任務，其實要看的是這個任務處理的資料是什麼，把資料和任務結合在一起來看，那麼這樣的話我們就產生了這種業務元件，那麼元件大家知道這個計算機設計上面我們其實關注的是什麼，就是行為和資料，你設計功能的時候或者就設計這個子系統的時候，你會考慮什麼把關係相近的資料聚合在一起，就類似於資料端的主題，那麼這種資料聚集在一起之後，你再把相應的行為也就是說我們說這個任務對吧，這個工作梳理，到一起那麼這樣的話就形成了這個有業務元件。

接下來我們來看一下元件設計的：5W1H

透過When,Who,Where,Why,How,What來做分析，分析到底為什麼要幹這件事，這件事到底有沒有價值？其實有時候我們判斷價值的時候，用一個簡單粗暴的方式去判斷的話，就是你產生一個新活動，產生一個新任務了，有沒有產生新資料，如果沒有產生資料的話，那這個任務本身它的價值就沒有那麼高了。

單從一個領域去分析的話，其實你還看不出來它的優勢，那麼當你把兩個領域，或者三個領域4個領域疊加起來，像這樣把不同的領域在這個價值鏈環節上疊加起來的時候，這個時候那麼這經過任務和資料的標準化，你就容易找到，我覺得公共的能力是什麼，那有些任務可能只有一個活動，或者只有一個活動在用，但有些任務就有可能被多個公司這就出現了這種公共，然後前面咱們提過的是希望軟體市場等複用也好啊，我其實還是希望著提高開發速度也好，其實你不能照著等等，那綜臺素質也這樣對吧，中臺也不也是在這工作，就是一個那個相當於整個業務的視角，從那個價值創造過程到你每個領域的具體活動任務，然後到了你這個任務產生的結果就是一個業務市場，對吧，反過來從下往上看呢，其實相當於是一個基礎事件，因為這個業務元件要處理哪些，資料處理的過程是什麼樣的，那麼我這個組合在一起的這個零件支撐了哪些業務活動，對吧？有沒有哪些業務我們都要用，於是這一張圖，從上往下的業務資源和從下往上的基礎資料就是結合在一起的，而且最後結合成了一個企業的全網。

接下來我們來看一下設計難點：標準化

標準化確實是一個難點。不僅僅是說說這個判斷這個東西本身再一個呢就是它這個範圍帶來的複雜度，當你的範圍太大的時候，這個標準化就比較困難。

接下來我們來看看企業的特殊價值：企業能力地圖。

這個企業級架構設計落地的過程裡邊，它可以成為一個更有效更容易吸引爭端火力的這麼一個溝通工具，就是你相當於有一個統一語言，大家在統一的一個藍圖上去互相去去看這個問題。地圖上意味著什麼呢？你就容易走丟對吧？你旅遊還需要旅遊地，出來做這麼大的專案，給一個大企業做的專案，我們都不是大企業，中小企業也可以啊，只要規模到一定程度的話，做這麼大的專案，你連個地圖都沒有了，那是對企業自身不利的。

接下來我們來看看，長期管理：持續融合。

然後這個長期融合的話，其實業務架構師就是我們在做業務架構過程裡邊培養的這個業務架構師，不僅僅是讓他們去做高額和高效益好的PPT就完事了，其實他們要參與到專案實現裡邊，對這個技術要對整個實現要有一個深入的瞭解，那麼在這個專案，其實我個人認為它是跑到業務部門去，尤其是對於我們傳統企業的轉型來講，你需要一些在業務和技術兩邊都能來幫助業務人員去更好的理解企業級軟體，該如何開發新技術的人。

接下里我們來看看演進式架構。

然後他是第1次做完了之後，要持續地應用這個架構，每次業務需求來的時候，透過一個業務架構設計分析，然後再到落地，那麼逐漸的這麼看到整個企業演進的過程，那麼這種的話對於我們，就是新來的人員的迭代其實是有好處的，因為新來的人我也有機會看到架構迭代的過程，我們好多企業或者專案新人進去之後依然懵，因為你想熟悉這個企業的系統要好長時間，因為這個整體架構好多時候都是貌似有，實際上沒有，那我們就會造成什麼呢？就是一個是以往經驗的流失和浪費，所以以前踩過的坑也沒有人能記住，這樣也會造成團隊的低效益。

接下來我們看一下，打造自己的方法論：知行合一。

我們要注重業務架構的“知行合一”，知線是指架構方法論的持續改良，行線是指戰略分析，架構設計，架構落地，長期管理。

接下來我們來看一下“知行合一”的延伸：方法間的融合。

架構發展的一個趨勢，就是方法性的融合

接下來我們來看一下軟體的“供求曲線”

如果兩條曲線同時上升的話，那它就意味著均衡價格的上升，對我們來講就是軟體開發的這個材料的質量的共同上升，所以這一塊這塊還是需要這個啊，大家要多多思考一下，所以你也看看我在技術瑣話裡面寫的另一篇文章，談的這個問題就這一塊呢，其實架構這個東西我個人認為，如果大家希望以後軟體生產的這個數量速度增長上來的話，那架構本身就是一個全域性思維，當然我說的時候不是說高等級的那個架構師那種，但是大多數人來講，其實都應該有一定的這種架構思維。

在這有這麼4個思維了，

比較重要的第1個是整體思維，就是說企業技術加入，你要看全面可以整體什麼樣的，

然後是洞察能力，其實洞察能力最簡單的來自於什麼，就是來聊來自於交流，因為這塊其實我們好多技術人員沒有機會做到說，有機會跟有現場在業務現場看一看，看看客戶交易怎麼跑到客戶那邊去的，這些事就是你多聊一聊多聊一聊，其實就是很好的洞察能力，洞察本身不一定是那麼深奧的東西。

我就相當於裡邊這個這個藍色的小T逐漸長到外邊，灰色這個大體它是需要一個過程的，所以說這個事誰也避免不了他都需要時間，需要時間去支撐這個發展，但是我們往往是企業不給時間是吧，這塊是一個很大的矛盾。

然後最後一點就是開放是為我們將來的價格都是開放式架構的，就是每個企業都有它，自己的一個T，一家公司也都有它自己的一個T，那麼如何把家公司的T相連起來，就是把這個4T串起來，相當於這就是T型的世界，這種開放的思維其實非常重要。

接下來我們要看到架構驅動的銀行數字化轉型，

從圖中我們可以看出戰略視野看出核心戰略，再將核心戰略進行分解，最後進行落實。

聊聊中臺

2015年大動作要解決的“痛點”

缺少業務全鏈路視角的需求管理機制，協同效率低。

業務與平臺沒有很好分離，無法支撐業務自助式發展

平臺准入門檻高，新小業務無法快速是錯

缺少可複用業務資產

當時設定的目標

需求結構化，業務配置化，業務全鏈路可視，業務測試一體化，業務監控，故障排查

業務架構的作用：

輿論裡的“中臺”：

新的中臺理念

多掌握點方法論，就都有助於瞭解這個中臺現象吧，我提供這張圖是不是為了大家去爭論中臺為什麼叫中臺而不叫平臺，不要太關注裡面的名詞，而是關注裡面所做的什麼設想，認為它還是做企業架構的這種設計，它還是一種挺好的探索，在企業架構落地實踐上是一種挺好的概述，那麼大家按照中臺這個思路了繼續探索咱們自己的架構方法論和工程理論，這是值得需要我們鼓勵的。