? ? ? ?最近忙著給一個客戶編制方案,主要是針對客戶已經初具規模的信息化系統群,規劃和建設了 業務中臺和數據中臺,以此而形成這個客戶自己的企業中臺。在交流和溝通的過程中,發現很多人(客戶,競爭對手,甚至是自己人)對于中臺的概念都存在比較明顯的誤區,特此簡述一下。
? ? ? ?首先很多人認為了,我如果采用了微服務,比如什么Spring Cloud ,dubbo 框架來構建了自己的業務系統了,就可以稱之為已經擁有了業務中臺。理由很簡單:你看,我所有的業務,不光是關鍵業務,而是所有業務,都下層到后面的服務,有這樣的服務資源集合,難道不就是中臺嗎?對于數據中臺也是同樣,先上hadoop,把所有的數據庫匯總,甚至再開發一個爬蟲,去搞一些非結構化的數據,那么數據中臺也形成了。
? ? ? ? 按照我的理解,上面這些都不是中臺,而是打著中臺的幌子,做的其他的事,當然也有可能是承建人也沒搞清楚什么中臺,所以看什么熱就套什么名字。中臺的概念來自于阿里巴巴,最著名的中臺事件應該是阿里在前兩年提出的“大中臺,小前臺”的口號和概念。那么到底應該怎么解讀中臺呢?首先我們要理解中臺不是一個產品,也不是一個技術,而是一個方法論。所以中臺不是拘泥于具體形式的,既不能認為我引進了什么產品或技術就認為我已經有了中臺了。那么這個方法論到底是解決一個什么問題了?我的理解是為了希望解決企業在信息化建設中能敏捷地,快速地,更少資源地構建一個業務應用這樣一個愿景而提出的方法論。如果認同這個問題是中臺提出的緣由,那么我們就可以得出符合中臺概念的幾個必要條件。
1,對于信息化建設一定需要能夠沉淀信息化的資產。
2,對于基于中臺的信息化建設必須快速。
3,對于基于中臺的信息化建設必須足夠降低門檻。
? ? ? ? 基于上面這三個方面,我們可以引入相應的產品和系統建設,但有了這部分硬的東西,還只是實現了中臺的基礎。如果只是有了基礎,而沒有相應的組織保障和中臺的文化保障,實際上中臺也只是一個空殼子。因此在硬件的基礎之上,必須同時針對組織架構和員工以及企業文化等進行相應的中臺改造,只有這些軟的東西的落地,才能形成一個真正有效的中臺。
? ? ? 當然每個企業軟的東西都是不一樣的,也不是一篇文章就能夠解釋清楚的,所以本文的落腳點還是關注硬的東西,也就是上面三點,應該有哪些具體的產品?
很久沒有更新文章了,最近忙于給一個國企做頂規,所以工作很忙。
繼續上面的話題,最近看過一篇文章,指出目前很多公司的敏捷開發其實都是錯誤的,因為很多的時候,只是強調了交付的敏捷,而忽略的了業務的敏捷,其實這個觀點和中臺的建設目的不謀而合,因為中臺的誕生不僅僅只是為了交付的便捷,而是針對業務性敏捷蔡更加有意義。為什么這么說?下面我來例舉個人經歷的真實案例。
? ? ? ? 某個二線城市,已經有了城市大腦的項目,而且該項目已經建設了好幾年,而且這個城市大腦在業務歸屬上也屬于該城市的數據局統管。這是業務背景之一。這兩年筆者做為前期專家,接洽了該城市某一個業務局的業務系統,通過需求分析和趨勢判斷,發現該業務模塊也需要有中臺在背后支撐,那么在項目的論證階段,就有兩個觀點。一個觀點:城市已經建立了城市大腦項目,而且城市大腦下面已經有了相應的中臺存在了,那么對于該委辦局的業務中涉及到中臺的部分,應該利用原有的系統行建設避免重復建設;而另一個觀點是:業務應該由自己的獨立中臺,因為中臺是服務于業務的,而不是業務為了中臺,不能本末倒置,中臺應該緊近業務方,而不是遠遠的獨立于業務。
? ? ? 本人的觀點當時是第二個觀點的支持者,為什么?其實就是前面論述的總結,中臺不是為了中臺而誕生的,還是為了業務,進一步明確就是為了業務的敏捷性而誕生的。如果脫離的業務,那么中臺就是完全失去了其價值,起不到應有的作用。所以支撐業務的敏捷性就是中臺最核心的價值。