這里談的平臺一體化，非傳統意義上大家所了解的像微軟.NET架構的Sharepoint平臺，Oracle收購SUN公司J2E架構Java平臺以及IBM Lotus Domino平臺。雖然在地產行業Sharepoint和Java平臺的應用明顯高于Domino平臺。但是，筆者在這里所討論的并不是簡單的選擇用哪個平臺開發產品搭建企業信息化平臺，而是借用其“平臺”理念來簡單探討一種應用模式。為避免枯燥的技術語言闡述，盡量用圖形的形式呈現，先來看看兩個概念：

SOA：Service Oriented Architecture，一種以服務為基礎的架構。具有可重用、松耦合、明確定義的接口、無狀態服務設計和基于開放標準的特點。而面向服務的實體結構扮演三種角色：服務請求者、服務提供者、服務注冊中心。如下圖：

ESB：Enterprise Service Bus, 企業服務總線。是傳統中間件技術與XML和Web等技術結合的產物，是網絡服務中最基本的連接中樞，可以所上企業建設信息化系統神經中樞的必要元素。其功能具備事件驅動、文檔導向的處理模式，以分布式的運行管理機制，支持基于內容的路由和過濾，具備復雜數據的傳輸能力，并可以提供一系列的標準接口。

ESB是SOA架構思想的現實應用，是SOA架構平臺得以輕量級實現的中樞神經元。因此，利用ESB搭建企業基礎應用平臺，利用主數據、業務流程，整合企業已經在用的各業務系統，通過基于角色的Portal構建企業一體化信息平臺。

數據集成：有四種模式對數據庫和應用系統進行數據交互：

直接訪問數據庫，基于JDBC(Java Data Base Connectivity，是一種執行SQL語句的Java API，可以為多種關系型數據庫提供統一訪問接口)構建數據接口，直接訪問數據庫，進行數據交互。

通過數據接口訪問，基于ODBC(Open Data Base Connectigity ,開發數據庫鏈接標準)構建數據庫訪問標準，通過接口進行數據交互。

通過服務封裝訪問，通過SDO(Server Data Objects,服務數據對象)創建統一規范的數據接入層，將混雜的數據源整合到其框架和工具集當中，通過訪問其服務進行數據的交互，不直接訪問數據庫。

通過WebService數據訪問，WebService是一種基于XML、SOAP、WSDL、UDDI等技術的獨立于平臺、軟件供應商的標準。是創建可互操作的、分布式應用的新平臺，也是時下較為流行的應用與數據集成方式。

XML：Extensible Markup Language，可擴展標記語言。用于標記電子文件使其具有結構性的標記語言，可以用來標記數據、定義數據類型，是一種允許用戶對自己的標記語言進行定義的源語言，是SGML(標準通用標記語言)子集，非常適合Web傳輸，提供統一的方法來描述和交換獨立于應用程序或供應商的數據。

SOAP：Simple Object Access Protocol，簡單對象訪問協議。一種輕量的、簡單的、基于HTTP、 XML 的協議，它被設計成在 Web 上交換結構化和固化的信息。

WSDL：Web Services Description Language，Web服務描述語言一種接口定義語言，用來描述WebService的接口信息。

UDDI：Universal Description Discovery and Integration，統一描述、發現與集成協議。它是一種規范，用于Web服務的注冊與發現機制，為Web服務提供三個重要的技術支持：①標準、透明、專門描述Web服務的機制;②調用Web服務的機制;③可以訪問的Web服務注冊中心。

以上四種集成模式，從本質上歸納，數據交互要么直接操作數據庫，要么通過構建一定的服務標準調用數據庫(如:WebService模式)，再進行數據交互。各有其優缺點：

利用ESB實現SOA架構平臺，對于主數據的規劃就有一定程度的要求，這也是為什么我們開篇就重點講述主數據需要嚴謹統一的原因。而管理軟件的世界巨頭SAP，據說早你那R3里面屬性開關就多達2萬個，更有甚者所其數據表的數量是同類企業的2--3倍。當然，我本人并沒有深入到SAP系統里面去驗證，但是SAP系統功能之強大、靈活。如果沒有這些數據屬性開關，沒有那么多復雜邏輯關系的數據表，是很難實現其多維、復雜、可配置、擴展性的要求。大家也了然，SAP等跨國軟件巨頭自身專注于產品研發與技術創新，通過培養實施服務合作伙伴，來提高對客戶的服務質量。走的就是專注、專一、專業的發展路徑，不單是在行業專注，更在行業價值連上專注，各取所長，三方共贏，紅利共享。這種合作與分享的模式也是值得國內軟件供應商學習和借鑒的。而近期國內軟件廠商瀕臨困境，但反觀SAP等跨國軟件公司，其在法蘭克福資本市場上，近期已經遙居成為德國市值最高公司，超過了一百多年的西門子，而蘋果公司則更是全球市值最高的公司，這些公司無不是專注于產品和技術創新，將產品實現、服務部分交由全球合作伙伴，打造互生共贏的產業生態鏈。而國內軟件廠商在這些地方顯然是有所欠缺的，自身在價值連的定位上較模糊。

以上從數據、流程、平臺或架構三個維度，淺薄的談了在房企進行一體化信息系統規劃和實施方面，筆者的一些淺顯實踐經驗、思路。這些信息化思想的落地，在IT領域已有眾多成功案例，如筆者了解的某大型汽車集團，就利用ESB、Portal整合了十多套業務系統，而房地產行業起步比較晚。但是，近兩年我們欣然看到一些比較前沿的房企，已經開始在主數據、統一流程、架構平臺方面逐步統一，而在此基礎上進行業務子系統的規劃與實施。在主數據規劃方面，除了組織管理單元和項目管理單元，有的開始整合研發與客服，規劃企業產品缺陷庫、質量問題庫等。而非前幾年那樣倉促為上系統而上系統，從最初的財務、OA、售樓三件套，到后來盲目成風的上ERP全套系統，結果苦不堪言。

從行業發展的角度，我們也看到一些廠商開始進行價值連的前向一體化衍生。提出適配型管理，咨詢與IT系統結合的一體化模式。這種管理思想的提出，無疑對于當前房地產行業管理參差不齊的情況下一劑良方。正如，筆者前面提到在權責模糊、制度缺乏、個人經驗盛行的發展型房企，標準化的系統無疑是對業務發展的束縛，系統最終也胎死腹中。這種模式的提出，對廠商要求極高，除了具備咨詢實力外，對IT系統本身要求也極高，在實施成果交付方面提出了前所未有的挑戰。

通篇筆者并未就房地產企業信息化應該如何上馬做出論述，也未就選型提供參考。筆者認為IT系統是技術為先，應用為本。夯實基礎了，才能系統化建設，至于先上售樓還是成本、計劃運營、采購招標、知識管理等要看各家業務發展戰略和管理成熟度，即：業務架構是凌駕于系統架構之上的。項目實施方面杜絕現在“藍圖很美好、實施很辛苦、交付很痛苦、服務很渺茫”的現狀。