? ? ? ?最近忙著給一個客戶編制方案，主要是針對客戶已經初具規模的信息化系統群，規劃和建設了 業務中臺和數據中臺，以此而形成這個客戶自己的企業中臺。在交流和溝通的過程中，發現很多人（客戶，競爭對手，甚至是自己人）對于中臺的概念都存在比較明顯的誤區，特此簡述一下。

? ? ? ?首先很多人認為了，我如果采用了微服務，比如什么Spring Cloud ，dubbo 框架來構建了自己的業務系統了，就可以稱之為已經擁有了業務中臺。理由很簡單：你看，我所有的業務，不光是關鍵業務，而是所有業務，都下層到后面的服務，有這樣的服務資源集合，難道不就是中臺嗎？對于數據中臺也是同樣，先上hadoop，把所有的數據庫匯總，甚至再開發一個爬蟲，去搞一些非結構化的數據，那么數據中臺也形成了。

? ? ? ? 按照我的理解，上面這些都不是中臺，而是打著中臺的幌子，做的其他的事，當然也有可能是承建人也沒搞清楚什么中臺，所以看什么熱就套什么名字。中臺的概念來自于阿里巴巴，最著名的中臺事件應該是阿里在前兩年提出的“大中臺，小前臺”的口號和概念。那么到底應該怎么解讀中臺呢？首先我們要理解中臺不是一個產品，也不是一個技術，而是一個方法論。所以中臺不是拘泥于具體形式的，既不能認為我引進了什么產品或技術就認為我已經有了中臺了。那么這個方法論到底是解決一個什么問題了？我的理解是為了希望解決企業在信息化建設中能敏捷地，快速地，更少資源地構建一個業務應用這樣一個愿景而提出的方法論。如果認同這個問題是中臺提出的緣由，那么我們就可以得出符合中臺概念的幾個必要條件。

1，對于信息化建設一定需要能夠沉淀信息化的資產。

2，對于基于中臺的信息化建設必須快速。

3，對于基于中臺的信息化建設必須足夠降低門檻。

? ? ? ? 基于上面這三個方面，我們可以引入相應的產品和系統建設，但有了這部分硬的東西，還只是實現了中臺的基礎。如果只是有了基礎，而沒有相應的組織保障和中臺的文化保障，實際上中臺也只是一個空殼子。因此在硬件的基礎之上，必須同時針對組織架構和員工以及企業文化等進行相應的中臺改造，只有這些軟的東西的落地，才能形成一個真正有效的中臺。

? ? ? 當然每個企業軟的東西都是不一樣的，也不是一篇文章就能夠解釋清楚的，所以本文的落腳點還是關注硬的東西，也就是上面三點，應該有哪些具體的產品？

很久沒有更新文章了，最近忙于給一個國企做頂規，所以工作很忙。

繼續上面的話題，最近看過一篇文章，指出目前很多公司的敏捷開發其實都是錯誤的，因為很多的時候，只是強調了交付的敏捷，而忽略的了業務的敏捷，其實這個觀點和中臺的建設目的不謀而合，因為中臺的誕生不僅僅只是為了交付的便捷，而是針對業務性敏捷蔡更加有意義。為什么這么說？下面我來例舉個人經歷的真實案例。

? ? ? ? 某個二線城市，已經有了城市大腦的項目，而且該項目已經建設了好幾年，而且這個城市大腦在業務歸屬上也屬于該城市的數據局統管。這是業務背景之一。這兩年筆者做為前期專家，接洽了該城市某一個業務局的業務系統，通過需求分析和趨勢判斷，發現該業務模塊也需要有中臺在背后支撐，那么在項目的論證階段，就有兩個觀點。一個觀點：城市已經建立了城市大腦項目，而且城市大腦下面已經有了相應的中臺存在了，那么對于該委辦局的業務中涉及到中臺的部分，應該利用原有的系統行建設避免重復建設；而另一個觀點是：業務應該由自己的獨立中臺，因為中臺是服務于業務的，而不是業務為了中臺，不能本末倒置，中臺應該緊近業務方，而不是遠遠的獨立于業務。

? ? ? 本人的觀點當時是第二個觀點的支持者，為什么？其實就是前面論述的總結，中臺不是為了中臺而誕生的，還是為了業務，進一步明確就是為了業務的敏捷性而誕生的。如果脫離的業務，那么中臺就是完全失去了其價值，起不到應有的作用。所以支撐業務的敏捷性就是中臺最核心的價值。