<b>1.2 企業資訊中心發展的症結</b>
筆者初次了解到阿裡巴巴共享業務事業部的發展史時，就有很大觸動，一部分原因是我親眼見證了阿裡巴巴為了更好地滿足集團業務快速發展的需要對組織架構的多次調整，這個過程充滿了集團上司的思考和智慧，也經曆了艱辛的嘗試，才使得阿裡巴巴集團在今天充滿殘酷競争的中國網際網路時代屹立于強者之列；另一個原因則是我發現阿裡巴巴在2008年面臨的問題跟現在很多企業面臨的困境非常相似，而經過阿裡巴巴多年打磨和驗證過的這套共享服務體系可能是讓非網際網路行業的企業擺脫困境的最好出路。
我為什麼會産生這樣的想法呢？讓我把前面漫畫中的一些問題和現象與現在企業中的問題和面臨的處境做一下映射。
1.?“煙囪式”系統建設模式
在圖1-2上左中，大家看到了2008年時淘寶的技術團隊同時支援着淘寶和天貓兩大電商平台。1999年成立的b2b電商平台1688一直擁有自己的技術支援團隊。阿裡巴巴集團三大電商體系的技術支援架構如圖1-4所示。
圖1-4 阿裡巴巴集團三大電商體系的技術支援架構
正如之前所述，三套電商體系的架構完全獨立，各自應用獨立開發和運維。在電商平台上有過購物經曆的讀者都能想到，一個标準的電商平台至少提供了會員服務、商品的資訊、交易支付，不管是b2b、c2c或者b2c的電商平台都需要提供，為什麼阿裡巴巴的三大電商平台會獨立建設和維護，這其中沒有任何公共和通用的功能嗎?
我想導緻這種建設模式的因素有很多，個人認為其中主要原因是開發團隊考慮到電商模式的不同，是以需要獨立建設；或者是新的業務團隊認為在之前的電商平台基礎上改造成支援新模式的電商平台會有太多的技術和業務的曆史包袱，還不如重新建構。不管原因如何，最終促成了當時我們看到的三座“煙囪”分别矗立支撐着當時阿裡巴巴集團最為核心的電商業務。
而這樣的故事實際上在中國企業it建設20多年的曆程中幾乎天天都在上演，今天企業it系統建設的模式是：當業務部門提出業務需求，資訊中心部門進行系統內建商的招投标（如自身有開發團隊的企業則無需此流程），再進入到需求收集、需求分析、開發、測試、上線的項目周期中，某種程度上每個新系統的上線都預示着一座新的煙囪矗立而成，這種完全基于業務需求建設系統的方式已經成為過去20多年企業建設it系統的标準流程，導緻it系統建設早的企業内部系統煙囪林立。這正是今天很多企業面臨網際網路轉型難的根節所在。
其實對于“煙囪式”系統建設帶來的弊端在十年前就已經有人提出，以這樣的方式建設系統對企業的“傷害”有三大弊端：
1）重複功能建設和維護帶來的重複投資。大家都不用太仔細去梳理這些“煙囪式”建設起來的系統，就能發現大量的功能和業務在多個系統中同時存在，單單從開發和運維兩方面成本投入的角度，對于企業來說就是一種很顯性的成本和資源浪費。但這一點對企業帶來的傷害卻是最小的，隻是成本的損失。
2）打通“煙囪式”系統間互動的內建和協作成本高昂。随着很多企業業務的發展，要打通這些“煙囪式”系統之間的連接配接，以提高或優化企業營運效率，這樣的場景在2005年後（是因為在這個時間點上很多大型企業已經進行了多年的it建設，有了不少的煙囪）逐漸湧現，特别在如今的網際網路時代，如何更好地整合内部資源、更好地提升使用者體驗，實作各個系統間的互動成為必然發生的事情。
最為典型的例子發生在零售快消行業，很多的品牌商在2008年天貓出現後，立馬上線了一個系統用于對接天貓平台，與自己企業的商品、庫存、物流打通；随着後期京東、微商的出現，相繼建設了相關系統；同時企業還有幾千家門店以及分銷商需要管理，是以都要建立對應的pos、crm等系統。2013年電商對傳統零售商的分銷模式産生了巨大沖擊，這些品牌商就着急要擷取到最終使用者的消費行為、愛好等資訊，進而為使用者的精準營銷做有力的資料支援，但發現使用者的會員資訊、商品資訊、訂單資訊、消費行為資訊等都被之前“煙囪式”的系統建設方式拆分到了不同的系統中，是以不得不開始打通這些“煙囪”，進而獲得品牌商所需的全局會員以及消費資料。
面對這樣的業務需求和系統處境，業界早在十幾年前就提出了soa的理念，出現了各大廠商紛紛推出了各自的esb産品及解決方案，重點就是來解決此類異構系統之間互動的問題。一時間，各大企業紛紛上馬soa項目，建構企業服務總線，基于服務的方式實作了這些“煙囪”間互動的問題。
縱觀各個soa項目的實施，平均來說企業為了系統的打通所花費的成本是比較高昂的，這其中牽涉大量的協同和開發成本。
3）不利于業務的沉澱和持續發展。從傳統it系統建設的生命周期來看，一旦系統上線以後，就進入了運維階段。在運維階段，也會有對系統功能完善和新業務需求的更新；是以我們看到了平均周期均在幾個月，甚至半年進行一次功能的更新。而事實上業務的需求是與日俱增的，特别在現今的網際網路時代，來自客戶、市場的回報和資訊都要求系統進行快速的響應，而傳統項目的疊代周期對業務的響應和支援越來越吃力。
上面提到很多企業通過esb系統很好地實作了多個獨立系統間的打通，不可否認esb的架構很好地屏蔽了服務接口變化給服務消費者帶來的影響，是解決不同系統間實作互聯互通的很好的架構，但這樣的項目在企業中落地後，後面的發展就讓soa價值的展現出現本末倒置的現象！
企業實施soa內建項目上線後，各個系統按照标準封裝的這些“服務”就進入一個“穩定”狀态。這裡的“穩定”當然不是指服務運作的穩定，而是這些服務對外提供的功能變得“穩定”，也就是說，很多服務在初次上線後，在接下來幾年的時間裡就幾乎沒有新的服務功能的增加或提升。
産生這種現象的根本原因就要追溯到企業實施soa的方式，典型的項目實施模式，在确定了貫穿多個系統的主業務流程後，就要求各個相關的系統進行服務的封裝和改造，這種模式就是典型的“自頂向下”的建設模式，而這個時候，各個需要提供服務封裝和改造的系統無不均屬于各自的運維期，對于服務開發相關的工作，運維人員的心态往往是協助和配合，并且多數情況下這些服務封裝的工作跟運維人員自身的kpi考核是沒有多大關系的。正是基于這樣的背景，我們很少看到在功能性和擴充性方面做得足夠好的服務。另一個更嚴重的問題則是當此期soa成功實施結束後，後續有新的業務系統希望接入這些服務，而新的業務系統又發現現有的服務不能很好地滿足他們的要求，希望提供更多功能或更好體驗的服務要求時，在現實中就會出現下面兩種情況：
1）服務提供者團隊不管是從kpi考核的角度，還是從認知上認為服務封裝的任務已經完成，是以當他們收到新的服務需求時，心理上是拒絕的，會出于多一事不如少一事的心态，告訴新業務系統的需求方：“我們目前僅能提供這樣的服務”，導緻最終的結果是新業務系統認為該服務不可用，逼着他們在自己的系統中重新又實作了一套跟這個服務差不多的功能子產品，也就是産生了一個新的煙囪。
2）服務提供者團隊擁有不錯做事的态度，也願意改造服務以滿足新業務的需求，但受限于之前服務設計時的通用性和業務前瞻性的不足，造成如果要滿足新業務的需求，就要對現有服務的資料模型、業務邏輯做較大的改造，在改造帶來的風險和滿足新業務需求的選擇中，更多的團隊選擇了放棄對新業務需求的支援，而保持現有服務提供的穩定，其結果跟第一種情況完全一樣。
不管是傳統項目建設方式帶來業務疊代能力的不足，還是現有企業内soa“項目制”建設的效果最終導緻三個弊端，而其中第三個弊端“it系統建設中實作的業務得不到沉澱和持續發展”是對企業傷害最大的。
前面兩個弊端是基于成本和效率的角度，第三個弊端則是基于發展的角度。采用“煙囪式”方式建設的系統體系，企業中一個業務領域的資料和業務往往就被打散在不同的系統中，采用系統打通的方式解決了眼前相關業務間的互動問題，但這樣的方式治标不治本。随着業務的發展，這樣的方式最終無法滿足業務快速響應和業務模式創新的需求。這也就是過去很多年中，在很多企業經常上演的一幕：一個系統上線運作5～8年後，企業的資訊中心會向企業更高上司人提出随着業務的快速發展，現有系統不管是技術架構還是業務模型都不能滿足現在業務發展的需求，需要整體系統更新，而這樣的更新往往意味着對原有系統推倒重建。且不論這樣推倒式重建對于現有業務帶來影響的大小，多少基礎功能的重複建設和資源投入，更重要的是對于之前多年業務的沉澱能保留多少，這對于企業來說可能是最大的資産流失。
這個問題本質上是由于系統所提供的服務能力沒有随着企業業務的發展做到與時俱進。在任何一個企業中，業務需求是一直存在的，傳統it系統建設模式下，上線的系統就進入了系統維護期，這個時間段實際上是系統對業務需求響應非常不敏感的階段，一般半年或一年才會進行一次系統的更新。也就是說，系統業務需求響應的能力和企業本身業務發展對系統建設的要求不成比例。如果說過去，業務需求的增長态勢還算比較平滑，沒有展現出系統的響應能力有多大差距，那麼在今天，網際網路時代業務需求的增長越來越迅猛，原有系統對業務響應的能力就顯得更加捉襟見肘，如圖1-5所示。到了一個時間點，量變産生質變，就會出現企業核心業務系統運作多年後被推倒重來的現象。
圖1-5 業務需求和系統響應能力
2.?業務支援一直是企業資訊中心的組織職能
如圖1-2上中，阿裡巴巴集團将原來淘寶的技術團隊從淘寶事業部劃分出來成立了單獨的共享業務事業部，成為一個中立的、同時支援淘寶、天貓兩大業務單獨的部門。集團的這種舉措與今天的企業一樣，無一不認可資訊技術部門對于企業發展的重要地位，每家企業中資訊中心部門的行政級别均和核心業務部門的級别相當。但實際上，行政級别的平等并不代表着具有同樣平等的部門話語權！
正如圖1-2上右，共享業務事業部在兩個業務部門間處境悲慘。試想一下，在董事會的桌子上，企業高層上司者希望各部門的上司能提出對業務發展各抒己見的時候，一定是業務部門的上司們基于對業務發展的了解高談闊論之時，此時有幾位cio或it資訊部門的上司能在業務上提出獨到的見地？結果相信大家都能猜到，業務部門的上司因為自己的想法被上司采納，争取到好的建功立業的機會，也自然擷取到公司高層的不少好感，這些好感也無形中為部門的話語權增加了不少籌碼。而it資訊中心則擷取的工作任務是配合該業務部門完成該業務目标中it系統的建設。
我聽說過一個真實的故事，一個大型國企的資訊中心主任在3個月間都沒有給董事長做過一次工作彙報，不是資訊中心主任不想做彙報，而是這位董事長總推辭沒有時間，而分管銷售的部門經理（與資訊中心主任管理級别平級）則幾乎每周給董事長做一次當面的彙報。相信這樣的事情在很多企業中都有，我認為這個問題的核心就是我們it資訊部門在現有的模式下已經被更高的上司層定位成了業務支援的部門，是一個花錢的成本中心。
造成這樣處境的原因是什麼？我認為是因為it資訊部門的人員不懂業務！我說出這個觀點，可能會引來很多it資訊中心人員的反駁和不認同，“我對系統的核心業務流程最熟悉，甚至比那些業務部門的人更懂”、“系統的資料模型都是我們設計的，怎麼說我們不懂業務？”……
我承認在對業務系統的具體流程、操作、資料模型方面it人員比業務部門更懂，因為這些系統是it人員負責建設的，但我所說的懂業務是指，能對業務的下一步發展有着自己的了解和看法，對業務流程如何進一步優化能更好地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。
而造成it資訊中心不懂業務的根本原因又是什麼呢？很多大型企業的it資訊化部門已經存在了超過20多年，一成不變的就是項目制的系統建設模式，這樣建設項目的模式除了帶來前面所提到的“煙囪式”建設的一系列弊端，同時使得it資訊化部門一直處于“業務支援”的職能位置，即隻是為了滿足業務部門需求而進行it系統建設的實施和運維部門。這樣模式下造成我們今天看到的很多企業it資訊化部門的員工大多數的工作内容就是進行項目管理，負責開發商招投标、開發商與業務團隊間的協作溝通、緊盯項目進度。當一個項目順利上線驗收後，這些員工開始投入到下一個項目的工作中。這樣的工作确實也非常鍛煉人的組織、協調能力，但這樣能力的提升與工作時間的長短并不是呈線性增長的，更多的時候，我們看到能力較強的員工能展現自己價值的地方在于負責的項目更大，甚至同時負責多個項目，而這在我看來終歸是增加了項目經驗，并不能在某一專業領域得到知識和經驗的沉澱，我相信随着時間的流逝，越來越多的人會慢慢失去最初的工作積極性和創造性。這樣的最終結果是it資訊中心的員工很少有能在一個業務領域做足夠的深入了解和業務沉澱，更多的是對業務知其然，而不知其是以然，也談不上成為業務領域專家，更不可能對業務發展有創新想法和獨到見解。
上面講的故事說明，在2008年阿裡巴巴業務系統的建設模式、組織架構包括遇到的問題都與如今企業并無二緻，而如何擺脫這樣的困境，選擇什麼樣的it業務架構以及基于哪些技術原則為企業真正打造一個在網際網路時代滿足業務發展的it基礎架構，将是接下來幾個章節詳細闡述的重點。
![更改LYNC SIP位址[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)