中台實際上就是一個餐廳中配菜的小工，職責就是負責向前臺的各位大廚配菜，，但在梳理中台需求的時候，我們必須要清楚的知道前臺到底有多少位廚師？各個廚師的偏好是什麼樣子的？我們怎麼樣的工作才能配合上每位廚師的炒菜節奏？也就是完成一次新的企業架構定義。
談到設計中台繞不過去的一個概念就是企業架構！
為什麼這麼說呢？
是因為設計中台就不能像以往設計傳統的單一產品線的產品那樣，僅僅是面向特定的人群進行思考，而是需要站在公司的視角，面向於整個公司業務對象與公司內部生產關係進行設計。實現對內提升企業運作效率，對外提升產品交付效率。
記得在本系列的第一篇文章里我已經給大家闡明瞭中台實際上就是一個餐廳中配菜的小工，職責就是負責向前臺的各位大廚配菜，但是在梳理中台需求的時候，我們必須要清楚的知道前臺到底有多少位廚師？各個廚師的偏好是什麼樣子的？我們怎麼樣的工作才能配合上每位廚師的炒菜節奏？也就是完成一次新的企業架構定義。
再用更白的話說一下就是，我們搭個工棚可能不需要設計，拿著磚就幹了，但是如果我們要建個迪拜塔就必須要好好設計了，整個建築的上下水，電怎麼接等都需要思考，而這就是企業架構的活。
一、我們先來看看企業架構到底是個什麼東西？
企業架構(Enterprise Architecture)這一概念最早是由IBM的咨詢顧問John Zachman，於1987年提出的。
也就是在隨著企業管理精細化，企業內部引入了多套不同領域的管理軟件之後，絕大多數企業出現了相類似的信息化企業病，我稱之為“人肉接口”與“為系統工作”的兩種病癥。
具體來說這兩者的根本癥結就是存在當公司內部採購了多個軟件後，由於各個軟件之間數據無法互相傳遞，事件狀態無法相互推進，導致不得不由員工將上一個系統產生的結果手動輸入到另一個系統進行下一步流轉。
此外由於系統間天然的隔離性，導致在上一個系統做過的審批以及操作，在下一個系統中很有可能還需要進行。
舉個例子來看，某公司的信息系統體系如下：
- HRM：類似italent等系統
- OA：企業某信+郵件
- 郵箱：內部搭建
- 產品研發管理：JIRA
- 財務系統：財務
- 銷售管理：某CRM
以員工離職這個場景來看，當我們要為某員工做個退工操作時：
- 第一步：需要進入HRM系統進行退工封檔；
- 第二步：需要進入OA系統里關閉權限；
- 第三步：關閉郵箱權限；
- 第四步：關閉JIRA項目權限；
- ……
這正是由於數據無法互通，導致我們不得不在多個系統之間進行操作，尤其註意的是這其中任何一個系統的權限遺漏都有可能會造成不可輓回的損失。
可以說上述的場景在現在的很多企業中都是非常常見的，那麼現在企業中是怎麼解決這個問題的呢？
由於無法實現系統間的互聯，因此往往是由公司人事部門整理了一份離職list，在每個人員離職的時候，按照list進行逐個手動關閉系統權限。
大家回想下自己離職的時候，是不是也會收到這樣一份list要你按照上面的流程去找不同的人關閉權限並簽字確認。可以說這大大加大企業內部的風險與對應人員工作流被打斷次數。
其實這個問題並不是這幾年才暴露出來的，早在1987年這位咨詢師就已經發現了這樣的問題，並給出了自己的解決方案這就是企業架構：他認為在企業信息化建設之初就應該考慮到多個部門之間的協作，並且在系統上體現出來，也就是A部門的協作結果很有可能成為B部門的信息來源，所以在系統之間必須有。對應的數據接口進行數據傳遞，此外還必須要為系統的後續迭代保留可拓展的部分。
讓我們具體來看看企業架構到底是由什麼組成的，如果繞過那些特別繁瑣的實施方法，僅從產出物上來看，我引用一張在我書中的圖來概括企業架構是什麼東西：
- 業務架構：如何將企業抽象的商業理論變為具體的執行層面，例如馬雲提出的讓天下沒有難做的生意落實到具體的執行層面，就是建立一個由支付體系（支付寶）+全球交易平臺（泛淘寶平臺）+物流體系（菜鳥驛站）組成的業務架構；
- IT架構：如何管理企業內部在運作中產生的數據，不同的應用軟件，以及底層的實現技術。
當然完整的企業架構構造不會這麼簡單，按照John Zachman的理論，企業架構具體分為這6類角色：
- 企業擁有者
- 業務管理者
- 系統分析者
- 系統設計者
- 系統建設者
- 系統本身
而這6類角色各自關註的問題也是有所不同的，具體關註的問題如下表所示（可點擊放大哈）：
既然聊企業架構，我就再展開點引用一位明白人談談目前發展的現狀：
工業和信息化部副部長楊學山在一次內部座談時提到：與西方發達國家比，國內的信息化建設在硬件方面已經不相上下，在軟件方面有5年的差距，在信息化管理方面有大概10年的差距，在企業架構方面則有20年的差距。
二、瞭解了企業架構後的中台建設
瞭解完了企業架構的概念後，我們再回到中台建設思考上，中台本質也是一個業務系統。
所以當我們研製中台的時候我們就需要考慮企業原有的企業架構（業務+現有IT系統），在中台加入後的新企業架構會是什麼樣的？
如何既符合原有業務架構又能封裝整個IT架構，為產品交付提供便利。
當然我們不需要像傳統的軟件咨詢行業一樣去規劃企業藍圖，中台建設中更多關註的是企業的業務現有流程，以及現有各系統之間的關係，在中台層面需要如何進行支撐與服務。
舉個例子我們作為一個外賣APP，我們內部有商城系統，商戶管理系統，物流調度系統，客服系統，當我們新拓展出的外賣派送、同城派送與超市派送等業務時，雖然應用場景各不相同，但這背後的業務核心流程是完全相同的：都是為用戶提供周邊5公里的派送服務。
對此我們可以將這派送機制抽離並整合進中臺中，由中台提供一個全公司業務的派送調度服務，而由不同的前臺業務線來根據具體場景設計對於的用戶交互流程與訂單的下單與進度顯示。
這其中本質上就是要梳理企業各業務線中原有的調度系統關聯關係，以及原來的派單業務的運營模式、流程體系、業務人員的組織結構。
讓我們再來看中台的完整建設流程（也就是在我的書中介紹過的MSS建設模型）：
該流程的前三步其實就是在進行業務架構的梳理（當然本系列中台實戰文章的寫作路徑也就是在按照企業架構的梳理方法進行一步步展開的）。
例如在上一篇文章《中台實戰（6）：業務邊界的劃定》里，我們其實談的就是企業架構里業務架構的梳理，我們結合前面學習過的商業模式識別與已經標準化的企業流程，對我們各業務線的SOP進行評估以及最終產出了一個業務標準建模：
Part1：生鮮電商商業模式（業務架構）
Part2：業務架構承載方：業務線定義（業務標準建模步驟1）
Part3：業務線SOP梳理（業務標準建模步驟2）
經過這些的梳理我們得出的是一家公司中的完整業務架構，併在此基礎上去進行中台系統的定義。
中台在IT架構中起到的作用用一個詞概括就是封裝底層。
具體來說建設完成後的業務中台與前臺的交互模式，由業務中台負責去定義需求的範圍與內容，並將具體的業務數據與處理結果返回給前臺，由前臺業務線負責具體展示形式。
如果用我們經常聽到的產品設計五層模型來對應的話，加入中台後的企業IT架構就如下圖所示：
可以清楚的看出業務中台是五層模型里的結構層，而框架層與表現層由前臺業務團隊進行定義。
最後
中台建設本質上就是對企業業務架構了一次升級，所以如果我們想要建設一個好的中台，就必須對企業架構特別是業務架構進行充分的梳理與歸整，只有這樣中台才能發揮起自己的作用。
PS：本文是即將出版的《中台產品經理寶典》10.1節企業架構概念的拓展，建議可以再結合書第10章一起閱讀。
#相關閱讀#
中台實戰（0）：最近處處惹人愛的中台到底是什麼
中台實戰（1）：看懂企業業務演進路線
中台實戰（2）：中台的建設核心原則
中台實戰（3）：數據中心中台化案例
中台實戰（4）：業務的抽象建模
中台實戰（5）：數據指標體系創建思維
中台實戰（6）：業務邊界的劃定
#專欄作家#
三爺，微信公眾號：三爺茶館，人人都是產品經理專欄作家。曾萬達高級產品、MBA特約講師、獨立創業者，現某支付公司產品線負責人，擁有多款集團項目從零到一經驗並帶領實現商業化佈局。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議