[ 導讀 ] 對智慧城市的理解是這樣的。現在的城市有什么問題，未來城市應該是怎樣的。從現在城市角度來講，剛剛很多人講了是以部門為中心的，是條塊分割的。

    SOA已成為我國各行業及區域信息化建設中打破信息孤島、實現業務協同的有效方式。為了促進國際、國內SOA標準工作的有效推進，促進SOA標準成果在我國產業及行業信息化的應用推廣，6月27日，“第五屆中國SOA標準和應用研討會”在北京新世紀日航飯店世紀廳舉行。

    北京大學信息化與信息管理研究中心秘書長姚樂先生在研討會上做了《智慧城市的頂層設計探索》的主題演講，以下為演講實錄：

    尊敬的各位領導、各位專家，大家中午好！我知道現在是吃午飯的時間，我會很快過一下內容。

    今天很多專家都提到了頂層設計問題，今天我給大家匯報的題目也是智慧城市的頂層設計探索。只能用“探索”這個詞，為什么？因為確實是在探索的過程。我介紹的部分包括：什么是智慧城市；智慧城市體系架構；基于EA的智慧城市頂層設計。

北京大學信息化與信息管理研究中心秘書長 姚樂

    對智慧城市的理解是這樣的。現在的城市有什么問題，未來城市應該是怎樣的。從現在城市角度來講，剛剛很多人講了是以部門為中心的，是條塊分割的。分散管控、反映遲鈍、盲目決策等等一系列的問題。我們希望通過技術進步，包括云計算、物聯網、移動互聯網等等技術應用，希望未來城市是以公眾為中心，而不是以部門為中心的，它是單一的政府，它是統一管控、快速反映、智能決策的政府。像咱們講的天人合一，人能快速反映、自動做出決策，是由于大腦發達，那智慧城市，也希望通過網絡快速感知、反映，通過云中心做出快速反映。智慧城市寄托了人們對于未來城市發展方向的憧憬。

    這里有一個簡單的定義。智慧城市是指在現代信息與通信技術的支持下，通過更加透徹的感知、更加廣泛的連接和更加深入的計算，使得整個城市的運營和發展更加智能化，從而達到使市民更加幸福，企業更加繁榮，社會更加和諧的城市形態。智慧城市是城市信息化的遠景目標。它是一個沒有終點的進程。跟信息化一樣。

    智慧城市本身是信息化當中的一個領域。它面臨的問題跟我們信息化過程當中面臨的問題是一樣的。比如大量重復建設、浪費，大量信息孤島和煙囪。大量的推倒重來和失敗，大量投資黑洞和陷阱。沒有革命的理論就沒有革命的實踐！我想信息化這個事一定要有相應理論指導，這個也來源于實踐。智慧城市建設需要總體架構和頂層設計。我這里提一個方法，利用體系架構方法進行智慧城[FS:PAGE]市的頂層設計。

    什么是體系架構？任何事情有它的架構，蓋房屋、造汽車有各自的架構。這些都是我們對于架構的認識。我們對任何事物架構認識的水平決定了我們對于它利用的水平。

    體系架構（EA）指一個組織單元的業務、應用、數據及技術基礎設施等之間的關系，包括基線的、目標的及過渡的動態關系描述。它有什么作用呢？有了體系架構，可以使我們對信息化相關的任何事情都有一個更加整體性的視圖與思考。還有它將復雜的問題簡單化。將復雜的整體劃分成一個個小的邏輯塊來分別處理。把業務、數據、技術等等分成塊，把復雜的問題簡單化。還有就是將高層的戰略、原則與指導轉換成單個系統設計與設計需求；政府有自己的戰略、使命，這些東西怎么約束下面項目需求，需要進行分解對于項目進行約束。比如說有沒有違背相關原則等等。還有將單個的IT需求與高層的驅動力與約束相匹配。我們每個需求的提出不是有需求就做什么，而是每個需求要受到上面的約束。

    體系架構會有很多框架，框架就代表一種方法，作為一種框架一般定義了模型的結構、通用詞匯以及開發方法和怎么做架構。使用成熟的體系架構與方法，可以重用業界的最佳實踐，從而快速地開發智慧城市的體系架構。

    架構發展歷程我就不說的。我們簡單看幾個：比如zachman這個框架（PPT），就是一大堆人訪問一大堆功能，一大堆功能訪問著一大堆數據，這里面涉及到什么時間、什么地點和為什么要做這件事六個要素。zachman框架里有幾個核心要素。第一它是關于體系架構本質內容，本身的重點不在于方法論。在信息化建設中一定要考慮如何“以不變應萬變”，所以它有原子件和復合件的概念。跟SOA是不謀而合的。建系統只是考慮復合件但是沒有考慮原子件，那么這個復合件是不可重用的。建復合件的時候，如果考慮它的原子件是什么，這個原子件才有重用的價值。如果只是按照需求建系統，而不考慮架構，這樣系統會無限增多。大家也都有這樣的體會，信息化到一定程度，就發現不能只按照需求建系統，一定要考慮架構。因為需求是無限的，需求會不斷的增加，我們這樣建會有大量的重復、冗余。越復雜的越是變化的，越需要架構支持。這是zachman的核心思想。

    TOGAF也是一個框架，可以作為開放架構。它有ADM開發方法，有10個輪子。還有內容框架，有了方法和流程，那么架構內容是什么樣？也有很多參考內容。（PPT）還有兩個很重[FS:PAGE]要的參考模型。還有方法中的方法，每個領域架構怎么做，方法中間還有方法，就是ADM指南與技巧。還有架構能力框架等方面的介紹。

    TOGAF的ADM是一個完整的EA開發流程，可以作為自上而下的IT規劃方法，也可以作為自下而上的企業級需求管理方法。ADM中間就是需求管理，從驅動力到架構的開發和實施治理，中間是需求管理。架構內容框架只是作為架構開發內容的參考，而不要作為輸出成果的標準。這是我個人的體會。TOGAF內容框架不能作為標準，不是說一定把這些東西全部做出來，只是根據需要作為參考。TOGAF參考模型和連續序列為架構資產的分類、存儲和利用提供了很好的指導。

    我們再看一下FEA，這是美國聯邦政府在用的。最初他們做的是FEAF，后來在美國政府基本沒有推開，因為他們每個部門都有自己的框架。2001年2003年美國推出了頂層設計，就是FEA參考模型。還有分塊架構方法，有頂層東西把復雜問題簡單化，一個一個分塊。還有聯邦過渡框架，這是什么東西呢？因為有很多東西需要大家共享、協同或合作，它分析出來需要大家共同協作的東西放在聯邦過渡框架里面，會隨時發布。每一個部門在做它的EA，一定要把聯邦過渡框架里面的內容整合到其中。還有EA評估框架，評估使用狀況、完整性、使用效果等等。還有聯邦SOA，怎么做好SOA這個事情？也是面向服務的。國內很多做SOA的也有體會，最難的就是什么東西重用，粒度怎么劃分。如果沒有面向服務的企業架構，我們是用了SOA的軟件，用了這些東西，理論上是可以重用，但到底怎么重用，如果沒有上面的指導下面是空的。所以整個架構設計要能指導下面面向服務的基礎設施。

    FEA核心要素有幾個方面，比如說FEA參考模型是核心，相當于美國聯邦政府電子政務的頂層設計，目的是作為投資立項的依據，發現合作、重用和共享的機會。EA評估框架和過渡框架是美國聯邦政府通過EA來保證IT項目與各機構戰略及跨機構戰略的匹配。分塊架構方法論作為一個分塊架構標準開發方法，它為解決方案的開發提供了最直接的指導。

    （PPT）這是我們提出的信息化體系架構框架（IEAF）。從流程的架構準備、架構目標、架構定義、架構使用、架構維護，每個流程都有相關的使用技巧。還有交付物是什么東西。這是國家社科基金在支持我們做的。

    我們怎么使用EA框架來開發城市EA？根據我個人理解做了一個簡單的分析。如果城市級，使用的框架可以是FEA，因[FS:PAGE]為核心交付物是頂層參考模型，可以幫你分析什么東西應該重用、共享等等。如果是部門級，比如說工商局、稅務局，TOGAF、DoDAF兩個框架是更合適一些，因為它的核心交付物就是企業及分塊架構，主要是解決IT需求與戰略及使命匹配的問題。比如我的部門戰略、使命是什么等等，數據到應用，它們之間的匹配關系。如果是項目級后系統級，zachman比較合適。特別是供應商要考慮的。它主要是解決方案架構，解決構件重用問題。當然不完全是這樣，但我覺得側重點可以這么考慮。

    再看基于EA的智慧城市頂層設計。頂層設計的作用是什么？為什么要有頂層設計？它的作用，根據我的理解，首先是可以做好IT需求管理。很多地方、部門單位信息化建設都走過類似的階段，剛開始是大家都面臨需求不足，到一定時候就IT需求過剩，這個時候最重要的是需求管控。怎么做好IT需求管理？沒有依據怎么審批項目？項目該不該批？就沒有審核依據。還有就是指導IT預算與項目審批。很多部門作為城市級，你想統一管控，依據是什么？沒有依據就只能拍腦袋。還有一個是指導重大IT項目建設。比如說做共享平臺、云計算平臺。我想這些是我們做頂層設計的主要驅動力。

    IT需求管理我們看這個圖（PPT）。這四張圖反映的是什么的？他從做這個事情，到這個事情不應該做，但他還在做。這也是我們平時所遇到的問題。還有這張圖（PPT）“盲人摸象”，我們每個做項目的人都是盲人摸象，只是看到了整體的一部分。中國古訓是“不謀萬世者，不足以謀一時；不謀全局者，不足以謀一域。”講的也這樣的道理。我們的需求是多變的，我們需要更加全面、長遠的來看待，怎么來驗證這些需求。

    （PPT）這個圖大家也很熟悉，不同人對需求的不同認識。大家都是不一致的。

    還有是IT能力與業務需求的不匹配。我們的戰略業務是什么？我們構建的能力是什么？這些都沒有一個清晰的匹配。我們對需求有很多的假設和誤解。我們誤認為某個人能把需求做好，我們誤認為只有一套需求，我們誤認為需求定義問題及其解決方案等等。那么需求正確理解是什么？需求是動態變化的，不是一成不變的。智慧城市需求一定是會發生變化的。真實的需求需要再一個完整的體系架構中驗證。什么是真實的需求？不是提出需求的人就拿來作為驗證標準。企業級需求不等于系統級需求，更不等于軟件級需求。需求有來自于自上而下的規劃，也有來自自下而上的要求，但都必須得到體系[FS:PAGE]架構的審核。企業級需求管理的方法就是體系架構方法。

    （PPT）比如用TOGAF做自上而下的需求。用TOGAF進行IT戰略規劃。從IT使命與愿景；IT目標與目的、IT發起項目、IT行動計劃，對實施項目的控制到根據環境變化的變更。整個是通過兩個一致性，項目跟架構的一致，架構跟變化需求保持一致，通過兩個一致性來保證IT業務匹配需求。

    我們再看一下自下而上的需求。除了戰略規劃里面，大家知道需求不是規劃了，一般規劃都是宏觀層面的，例如“十二五”規劃。但是我們的需求是隨時改變的，這些需求不是規劃好了就不處理這些需求。例如，這是美國HHS（健康與人類服務部）相當于我們的衛生部。這個部門利用快速分塊的方法，它有自己的EA，當新需求來了之后，用快速分塊方法來快速定義需求和解決方案。美國法案頒布也會牽扯到很多改變，比如哪些東西要向公眾公布，這是一個非常開放透明的做法。這是2009年的例子，2009年頒布了《美國復蘇與再投資法案》。這個時候它不可能像我們這樣，一個法令變化，整個系統又重新開發。這是2009年的例子，通過這個方法來做，橫向縱向進行分析，哪些數據可以直接出來，哪些需要做修改等等，馬上就分析出來。

    下面我們講講怎么指導IT預算與項目審批。FEA的例子（PPT）。這里有五個參考模型：績效參考模型、業務參考模型、服務構建參考模型、技術參考模型、數據參考模型。看看績效參考模型的使用，舉個例子，比如國土安全部要建一個邊境檢測系統。過去通過邊境要花兩個小時，現在是需要半個小時。這個帶來了怎樣的客戶結果？過去客戶滿意度大概是80%，現在是達到了90%、甚至98%。當然還有使命、業務的結果，比如說每年通過邊境進入到美國槍支擁有量減少多少、犯罪率減少多少，你的使命就是保護美國本土安全。所以一方面有客戶結果，一方面有使命和業務結果。

    還有一個是指導重大IT項目建設。例如做云計算平臺，到底要做什么樣的平臺？IaaS，可以做個基礎。作為平臺來講，是做共同系統平臺。還有一個是行業平臺，例如醫療、制造業、政府的。第四層是組織特定的。我們的PaaS就要考慮這些層次怎么劃分，到底支持什么。

    最后我畫了這樣一張云計算生態鏈圖（PPT）。從芯片到服務，整個里面涉及到哪些層級我們用EA的方法論。比如說SaaS跟DaaS做的分離。我們為什么做這個分離呢？在云計算平臺下這兩個是分離的趨勢。在云計算平臺下，[FS:PAGE]這里面是要產生分離的。為什么呢？現在部署在云端，好多中小企業的SaaS服務不敢用，如果說數據是存在有資質認證的大企業，這是可以用的。過去很多企業要講標準化，我們做了很多數據標準的工作。但是每個企業都是根據自己來做的，都是自己的標準。現在云計算平臺給了這樣一個機會，大家可以共用數據標準。還有我們也考慮過國際分工的問題。云計算平臺現在外資不允許在中國運營，因為涉及到很多問題，如數據主權和安全問題。我在想國外廠商SaaS跟國內DaaS結合，國外廠商只提供軟件服務，我想從國際分工來講也是一個解決思路。

    最后提兩點建議：利用EA與SOA做好智慧城市頂層設計。這個對下一步智慧城市建設是非常有利的。另外一個是利用頂層設計，開展基于云計算平臺的智慧城市建設。有了這些頂層設計的東西，才能真正開展好我們的建設。借用工信部楊學山副部長在第六屆中國電子政務高峰論壇所講的話，講到電子政務及發展模式的轉變，一個轉變是技術架構上走向云模式。從業務角度就是要回歸到政府履行職責的本質而不是部門分工。過去信息化建設都是按部門分工做的。大家看到我們要處理為民服務的東西等等都是跨部門的。最后一個是信息資源開發利用走向大數據模式。我們的智慧城市建設要考慮這種新的模式轉變。謝謝大家！

【聲明】物流產品網轉載本文目的在于傳遞信息，并不代表贊同其觀點或對真實性負責，物流產品網倡導尊重與保護知識產權。如發現文章存在版權問題，煩請聯系小編電話：010-82387008，我們將及時進行處理。