2012年6月16—17日，由工业和信息化部信息化推进司指导、北京大学信息化与信息管理研究中心主办、中央机构编制委员会办公室电子政务中心协办、CIO时代网和锐捷网络承办、北大CIO班和北达软特别支持的“第六届中国电子政务高峰论坛”在北京大学隆重开幕。
在17号下午的“政府体系架构与顶层设计”分论坛上，北京大学信息化与信息管理研究中心秘书长姚乐先生在论坛上做了关于《政府体系架构与顶层设计探索》的主题演讲，以下为演讲实录：
各位领导、各位专家，大家下午好！刚刚两位专家做了很精辟的发言，应该讲，刚刚讲的两个实际上都是实际在用的两个例子。DoDAF不仅仅是框架、方法，是美国国防部在用的。刚才陈主任也把国家税务总局怎么做架构的方法包括取得的成果给大家做了分享。
北京大学信息化与信息管理研究中心秘书长 姚乐先生
我下面的演讲会更加宏观、更加虚一点。这个题目叫“政府体系架构与顶层设计探索”。我觉得这个题目有点大，所以就叫“探索”。分三个部分介绍：第一，介绍体系架构。第二，介绍主要的框架和方法。第三，基于体系架构的顶层设计方法。
什么是体系架构？我经常用这张图表述，做什么事情都有架构，盖房子有房子的架构，造汽车要有汽车的架构，建城市也要有城市的架构。我们对任何事物认识的水平决定了对它利用的能力。所以一件事物你能利用它到什么程度，看你对它的架构认识到了多大程度，这个起了决定的作用。我们叫政府体系架构，其实在其它行业里我们经常叫企业架构。Enterprise翻译成中文叫“企业”，但是政府部门不认，所以我们在这里叫体系架构。大家要知道体系架构Enterprise Architecture里Enterprise这个词，它不仅仅包括我们所理解的企业，也包括政府部门，甚至部门中的一个分支机构，它是指具有共同使命的组织单元。
这里我对EA也下了一个简单的定义。为什么它的定义会有很多？因为大家是从不同的侧面来看的。它是指组织单元的业务、应用、数据及技术基础设施等之间的关系。首先是讲它们的关系，包括基线的、目标的及渡过的动态关系描述。也就是说，这个企业它的基线现在是个什么样的，它未来又是什么样的。从现在到未来这个过渡又是怎样？它们之间的关系是怎么样？
体系架构的作用，我总结了三点：第一，它是我们对信息化相关的任何事情都有一个更加整体性的视图与思考。我们讲很多人说把EA做一个集成管理的框架。过去我们做项目管理、服务管理、安全管理都有各自的框架，我们做很多很多的工作都有相应的管理框架和标准。但是这些框架、标准都是分散的，大家在做它，还有做质量的。那么这些工作之间它们应该有一些逻辑的联系。而实际过程当中大家只顾自己做自己的。没有一个集成管理的框架。当我做一个事情的时候，这个事跟其他事情是什么关系，没有。那么体系架构给了我们一个视图，让我们知道做任何事情的相关约束是什么，跟其他要素之间的关系是什么。
第二，将复杂问题简单化，也就是将复杂整体划分成一个个小的逻辑块，分别处理。这个好理解。为什么需要EA？因为复杂的系统我们很难凭经验、常识去处理，就需要有科学的方法。越复杂的东西，解决复杂的东西最基本方案就是复杂问题简单化，先把它变成一个一个块。例如信息化里面涉及的要素有很多，我们把业务分一块、数据分成一块、技术分一块等等，甚至再把服务、应用、标准等等细分成很多块，甚至业务里面还有很多块，比如按照业务职责可以划分块，等等，最终要把复杂问题简单化。把它化成块再找出它们之间的关系，才能解决复杂的问题。
第三，将高层的战略、原则与指导转换成单个系统设计与实现的需求，将单个的IT需求与高层的驱动力与约束相匹配。任何组织都有高层的战略目标、原则。以信息化来讲，很多企业做出规划的时候，也确立很多原则。但是当上项目的时候这些原则就变的虚了，没有用。高层组织确定的战略，例如“十二五”规划、原则、指导，它怎么约束这些项目？我们要靠架构。
因为只有把这些关系梳理出来，当我任何一个项目，比如它支持怎样的业务，这个业务是怎样支持战略，只有这些架构内容，才能把高层战略的东西、约束性、指导性的内容真正变成对项目的约束。
再一个就是要讲单个的IT需求与高层的战略驱动力或者约束相匹配。反过来说当我有一个业务需求时，需求是不是有一个就做一个系统？不能是这样。任何一个需求进来的时候，它有约束的，这就是架构约束。这个约束包括高层驱动力，为什么做这个事情？事情要达到什么样的愿景？投资回报是否合适？架构符不符合标准？有没有受到其他约束的限制？等等。
简单给大家介绍了一下EA是个什么样的东西。下面给大家介绍一下几个主要的框架和方法。
刚刚麦老师讲了DoDAF框架，还有FEA，TOGAF，Zachman框架。框架是代表一个方法论，框架里面包含了哪些要素，我们要了解。一般框架包括定义了模型的结构，就是里面到底有哪些模型；还有定义了通用的词汇，用什么表示什么；这是业务、服务，有了通用的词汇、能力等等。还有一个是定义了开发的方法。一般的框架会定义了开发的方法，但不是所有的。比如Zachman它就是一个内容的框架。这是EA框架的发展历程。最早是Zachman，被誉为“企业架构之父”。这里有一个虚线，上面是美国国防部最早推出了TAFIM框架，之后捐给了一个国际组织The Open Group。TOGAF最早就是基于它这个框架做的。美国国防部后来也在继续开发自己的框架，这就是后来的DoDAF。
图上虚线下面的这条线表现的主要是美国政府部门，他们作为一个很复杂的组织、体系，早就意识到EA非常重要，所以他们推动EA发展起了非常重要的作用。这个下面描述的是美国政府最早推出了FEAF，他们各个部门都形成了自己的框架，因为FEAF相对太简单了，基本上没有把它推开。到2001年左右开始做整个联邦政府层面的顶层设计，作为联邦政府层面，他们觉得这个很重要。现在，美国联邦政府也面临着一个问题，去年我在美国时就听说联邦政府政府任命了一个联邦的首席架构师，任命他的目的是什么呢？希望把美国联邦政府的EA统一起来，但据说难度很大。所以他们也走了弯路。最初没有统一框架，现在他们还是想统一，因为不统一还是有很多问题。难度也非常高。
这里我讲的是发展的脉络。第一个是Zachman框架。很多人都很熟悉。36个格子。它就表述了架构非常抽象的一种本质的内容。用他自己的话说“我的框架就是信息化的本质的东西。”纵向是六个要素，连起来就是一大堆人使用一大堆的功能，功能访问着一大堆数据，这里面涉及什么时间、什么地点，为什么做这个事情。横向是五类利益相关者的不同层面，他需要看到什么内容，做什么决策。最后一行是根据架构做出来的产品。
Zachman最核心的要素：一是Zachman是关于体系架构的本质内容，本身的重点不在方法论。很多人写EA相关的方法或框架，他们都谈“我做了Zachman框架的哪些东西”，所以它更多的是关于内容框架的。包括TOGAF在9.0之前，在8.0级的时候，很多人都是用ADM+Zachman框架，用这样的方法做架构。美国有的很多部门机构还在延续这样的方法。当然它的ADM跟TOGAF的ADM还是有点区别。
二是在信息化建设当中一定要考虑“以不变应万变”。这是Zachman非常核心的思想。其中两个重要的概念是：原子件与复合件。我们建系统建的是复合件，要考虑与原子件的关系是什么。复合件要建立在原子件的使用基础上，只有这样当发生变化的时候，我们才能随需应变，也就是通过原子件的重新组合去满足新的需求。如果不考虑原子件，可能原来所有的东西都要抛掉，系统也会很脆弱，到一定时候，往往牵一发而动全身，不得不推倒重来。
三是如果只是按照需求去建系统，而不考虑架构，这样的系统将无限地增多，复杂性也会指数级增长。很多国外大的企业包括美国联邦政府，他们面临的问题都是一样的。在信息化建设初期，大家都只是拼命建系统，对架构认识都会很肤浅。因为那个时候问题还没那么多。如果只是按照业务建系统，到一定程度会发现系统越建越多，系统会无限增加。你有一个需求就做一个系统，这样系统会不断增加，系统复杂性也会指数级增长。每建新的系统与旧系统之间的关系是怎么样，必须要用架构来考虑。
人类处理复杂性和变化就是架构。盖房子也是这样。房子没有架构的东西，这个地方动了，那楼就可能垮了。同样的道理。越复杂的，越是变化的，越需要架构支持的。
再看一下TOGAF9，它的影响力最大，也是参与最多的框架。左上角就是ADM开发方法。从预备到愿景，到业务架构、信息系统架构、技术架构、再到机会与解决方案、迁移计划、实施治理和变更管理等等，包括中间的需求管理。这十个步骤就是十个轮子，有详细的输入、输出和步骤方法。
上面的中间是它内容框架。这是9.0。没有这个之前很多都是ADM+Zachman，把Zachman做内容框架。现在TOGAF有自己的内容框架，刚刚卖老师展示了DoDAF的52个视点，而TOGAF里面有56个。它还有两个非常著名的参考模型，是非常好的。今天云计算也没逃离它的三层划分。左下角是ADM指南与技巧，指南就是方法的方法。如利益相关者管理等等一系列的指南和技巧。
下面的中间是连续序列，就是把架构做一个分类。它对我们架构内容做了一种非常科学的分类。这个分类不仅指导相应的解决方案，也会指导包括我们做云计算平台的划分，连续序列也是很有用的。最后是能力框架。你做架构事情需要相应的能力。如人的技能框架，流程中的架构委员会，还有工具等等内容。这都是能力的组成部分。
TOGAF9的核心要素有哪些呢？ADM是一个完整的EA开发流程，既可以作为自上而下的IT规划方法，也可以作为自下而上的企业级需求管理方法。为什么这个方法用的比较多？首先它作为完整EA的开发流程，这个流程还是很完整的。它这么完整，从愿景到解决方案出来，是作为IT规划的方法，自上而下的。同时还有一个自下而上的需求管理。比如说这个部门做了架构等内容东西，你做的目的是什么？是控制整个项目，需要控制这些需求、审核需求，那么这些需求ADM这个方法论就是企业级的需求和方法，ADM中间就是需求管理。这个跟我们传统讲的系统的需求管理有很大区别。
比如我们有一个学员跟我讲过他的例子，他说现在信息化到了什么样的阶段呢？原来是需求不足，靠我们推动。现在需求过剩，已经应付不过来。需求怎么管理、管控是最头疼的问题。为了解决这个问题，他在网上查阅找到专门做需求管理的培训机构，给他们讲了三个整天，他们觉得讲的很科学，很是那么回事儿，从调研、分析、设计、建模等等一套方法讲得很科学。但是听完之后他说，这些东西还是没有解决我的问题。我说：它肯定解决不了你的问题，因为你俩说的不是一个层面的问题。他告诉你是系统级的需求管理方法。系统及需求是针对明确的目标，你要做什么事情？你可以用这样的方法做需求管理。但是你面临的需求管理是企业级的，是我需求审核、验证，这个需求该不该满足，怎么满足它。所以这不是一个层面的需求管理，这个层面的需求管理要靠企业架构方法来解决。
TOGAF9第二个核心要素，架构内容框架只是作为架构开发内容的参考，而不要作为输出成果的标准。包括刚才麦老师讲的52个视点，包括TOGAF56个视点也都是这样，只能作为参考，不能作为标准。这是我给大家的建议。很多人觉得，架构就是把这些东西做出来。错了。这只是参考，千万不能把它作为做架构的输出标准。TOGAF参考模型和连续序列为架构资产的分类、存储和利用提供了很好的指导。这几个参考模型从技术参考模型上做了一个分类，连续系列从整个架构的，从特定的到通用的到4个层级，都提供了很好的指导。比如说架构资产，怎么分类、存储、利用它。
我们再看FEA，这个相当于美国联邦政府的顶层设计。包括了FEF框架，这里面的六个内容其实不是标准的东西，但是我觉得这六部分是最重要的。FEF就是作为一个框架，但是这个框架实际上没怎么被用起来。核心是FEA的参考模型，这五个参考模型非常有用，就是管理企业级需求。还有一个最重要的就是，它做顶层设计，比如说政府有哪些东西可以重用，哪些东西不需要做重复建设，还有发现合作的机会，比如说这个东西需要跟谁合作，发现共享的机会。它这几个参考模型核心是这样的。当然还有绩效差距，就是说这些事情，我能知道为什么它值得做。这些参考模型蛮有用的。
后面的几个，包括分块架构方法、联邦过渡框架、EA评估框架，都是FEA落地的指南和技巧。当然只看这几个参考模型看不出有什么用，我们要通过后面的几个东西才知道参考模型有什么用。比如说联邦过渡框架，就是联邦政府，不是某个部门而是联邦政府，从现在到未来转型过程中大家需要共同做的东西，就是跨部门的东西。这些东西它有一个个的分块，比如IPv6这个分块，比如说财务作为分块，例如做预算会做分块，人力资源作为一个分块，因为人力资源管理大家都要管，都是类似的。涉及到大家共同参与的分块放到联邦过渡框架里面。比如说发现这个方块里面有我的内容，我要做我的框架和过渡计划时就要把它纳入我的EA，我报项目时就知道，他会看过渡框架的东西怎么考虑的，是怎么整合到EA里面的。
还有EA的评估框架，就是联邦政府评估各个部门的时候，主要通过EA手段评估。一个是EA的完整性。EA开发的越完整，说明你使用基础越好。还有使用状况，你用它做什么，比如说支持投资决策、支持项目管理、支持做安全工作等等，它是一个集成的框架。最后是结果，就是你用了这个框架节省了多少钱、支撑了什么很好的决策等等。这是三个维度，每年分三个阶段来评估。
还有一个是联邦的SOA。SOA面向服务的架构，怎么在联邦政府落地。很多企业知道说上SOA，买一套工具，做很多承诺。但是什么东西需要组装重用等等就不知道了，这就更难了。服务更多了。它一定在上面要有指导，面向服务企业、到面向服务的架构，再到面向服务的基础设施。有很多企业满足了基础设施，但没有考虑面向服务的企业和架构，SOA就很难真正落地。
FEA核心要素，一个是FEA参考模型是核心，相当于美国联邦政府的电子政务的顶层设计，它的主要目的是作为投资立项的依据，发现合作、重用和共享的机会。
DoDAF在一个部门内部主要处理这个部门里面需要协同的东西。但是部门之间需要协同的，我们现在很多，包括杨部长昨天也讲到了，现在的电子政务建设为什么要发生模式的转变。过去依据部门职责建一个个系统，现在技术条件发生了变化，我们要处理的业务都是综合的，跨部门的。这个时候怎么办？这里投资立项就发生了很大的变化。比如说一个事情涉及到工商、税务等等部门都要参与处理。
EA的评估框架和过渡框架是美国联邦政府通过EA来保证IT项目与各机构战略及跨机构战略的匹配。通过EA手段来保证IT项目，不管你做什么项目，这些项目跟你本身机构的EA、EA战略等等方面有匹配。通过这个方式保证。分块架构方法论作为一个分块架构的标准开发方法，它为解决方案的开发提供了最直接的指导。它也是十几个部门最佳实践的总结。
下面给大家介绍一下我们正在做的信息化体系架构框架（IEAF），这是国家社科基金支持的一个项目，我们在做EA的本地化。这个还不成熟，把这个单独拿出来跟大家分享一下。因为在流程方面我们从架构准备、架构目标、架构定义、架构使用、架构维护等等，类似一个生命周期进行准备。每一个流程里面到底用了什么样的技巧，比如说架构准备里面有驱动力分析、架构分割等等，每一个流程里面都利用了哪些技巧。还有就是每一个阶段里面要交付什么，每个阶段要交付什么内容。这是在做这样一个框架。大家一谈这个就说美国的。所以我们试图做中国EA框架的东西。当然这是一个很简单的框架。
对EA框架的选择。有几个标准：第一，EA开发的主要目的。就是你为什么要做EA？你不能为了做它而做它。你是市政府层面、省政府层面还是国家层面做立项审批。例如在部门内部，很复杂系统的，像TOGAF这种的可能比较适用。主要目的不一样。第二，EA开发范围。你是在整个政府层面还是在部门层面、项目层面。第三，EA开发的细节程度。主要支持领导决策还是要落地到做项目的开发，甚至系统的生成，那么开发细节程度也不一样。第四，EA开发的能力。比如说你学了DoDAF等等一些东西，你了解哪些，你的能力决定了你对框架的选择。
最后回到主题，基于体系架构的顶层设计。国内谈“顶层设计”比较多，大家觉得顶层设计很重要。但是在国外来讲，这个领域谈顶层设计这次词相对比较少。曾经有个专家问我，这里面的区别是什么。我觉得是这样，当然这不是我分析的，国外专门把这个做对比进行分析。最主要的区别是，设计处理的是相对静止的目标，相对明确的目标。而架构处理的是相对动态甚至不明确的。比如信息化的目标到底要做成什么样。它的战略、目标会随时调整。从设计角度来讲，就是非常明确的。比如说造宇宙飞船，盖一座桥，这些是相对静止的目标。这个时候我们通过顶层设计进行分解，然后再一个一个做什么。但是对于一个企业，你说信息化到底把它做成什么程度？我相信现在没有谁敢说，只能说一个相对的愿景是什么样，但是这里有动态调整，因为技术、业务环境在不断变化。说不定法律颁发会改变很多东西。处理相对动态的需要有架构。
动态变化中也有相对稳定的内容，我们可以把它加顶层架构、战略架构或顶层设计。政府也需要顶层设计，FEA，我们把它作顶层设计。无所谓叫什么名字。关键是为什么需要它？从我的判断分析来讲是这样的：第一，做好IT需求管理。很多企业项目，这个人做那个，那个人做那个，需要需求管控。需要顶层设计指导。第二，指导IT预算与项目审批。就是说这个IT明年到底花多少钱。还有依据什么做项目审批。各个部门报这么多项目，我依据什么审批。第三，指导重大IT项目建设。比如说大家都很热衷于搞云计算，做云计算平台。那么这个平台到底要支撑什么，也需要顶层设计来指导。
下面我分别谈一下我的一些看法和例子，做需求管理有两张图。左边的图最上面这个人在拖水管要浇花，当时还没有下雨；第二张图是这个人在拖水管，种花的地方已经下雨了，但是他不知道；第三张图是这个地方在下雨了，他那个地方也下雨了，但是他还在拖水管；第四张图是一边下雨一边浇花。这反映的是我们决定做一个事情时，环境发生了变化，但是实际过程当中我们没有处理这个变化。这在政府里是很常见的。比如说这个项目审批完之后，这个项目钱必须得花掉，他没有考虑到环境发生了变化，不允许这些项目做变更，不允许这些项目动态的处理。这就是需求的多变性。还有一个是需求的片面性。看右边的图大家应该很熟悉，是盲人摸象。大家认为这个事是什么，就是什么。摸到什么就像什么。中国古训：不谋万世者，不足以谋一时。不谋全局者，不足以谋一域。说的也是这个，其实是相通的。
关于“需求”有很多的假设和误解。我们认为只有一套需求；某人能够真正定义需求；需求定义问题及其解决方案；预先声明的需求保持不变；需求代表验证标准；需求必须的：所以它们与成本和风险是独立的，等等。关于“需求”的正确理解是以下这样的：需求是动态变化的，不是一成不变的；真实的需求需要在一个完整的体系架构中去验证；企业级需求不等于系统级需求，更不等于软件级需求；需求有来自自上而下的规划，也有来自自下而上的要求，但都必须得到体系架构的审核。也就是说，需求来自两个方面，一个是规划的东西。还有来自自下而上的，随时出来的需求。比如说一个领导的想法，一个法律的颁布都可能会带来需求。那我们搞技术的人不应该觉得这不符合我的需求就不响应。企业级需求管理的方法就是体系架构方法。
自上而下的方法以ADM方法为例。从架构愿景开始，到业务架构，通过业务得到相关目的控制等等，一直到行动计划。这里有张表，列出了交付物（以及用什么东西表示它）。
自下而上的需求，就是随时的在现实过程当中遇到的。比如说美国颁布了《美国复苏与再投资法案》，奥巴马说“美国每次危机可以通过这样的法案使美国经济再一次快速增长。”可见这个法案的重要性。这个新法律的颁布在企业里怎么快速响应、落地。最早提出的愿景是构建一个快速响应的政府。ARRA就是《美国复苏与再投资法案》。图中红色的部分，有横向面和宽度，这里面有架构基础也做了很多分块和内容。这个法案的落实它在我这个部门的落地会影响到哪些分块，每个分块影响多深，哪些系统需要调整，哪些数据需要重用，这里就可以做出快速响应。
刚才讲的是需求管理，还有就是投资预算与项目审批。FEA参考模型就起这样的作用。比如说绩效参考模型，比如投资一个技术，这个中间有怎样的过程和活动，支持怎样的结果，使命结果等等。比如说上国土安全部要上一个边境检测系统，这里面有一系列技术指标。这些东西大家都好找。正好这个边境检测系统上线它主要支持什么流程和活动，用什么检测它。边境检的是国外人进入到美国。比如说过去是通过边境需要一个小时。而这个系统只要半个小时就通过了。上这么一个系统，不能说它快就好。比如说，通过它客户满意度从80%提高到90%。当然也不能只有满意就可以了，而你的使命是保护美国本土安全。美国本土安全用什么指标衡量呢？比如说通过这套检测系统，美国枪支使用、犯罪率降低了多少等等。这是使命要保护美国本土安全。
例如53的说明表格，关于表格的填报、申报，这个表格里面有唯一的编码，这些编码有什么用呢？它会自动分析出来，例如我这一类项目有多少机构在做，还有在同一个机构过去做了什么现在又做了什么，都能分析出来。
除了53项目整个列表之外对每个项目也有一个分析表300。服务参考模型，上这个项目用了什么服务构件，里面有一个相关分类。你用了什么。如果是需要重新开发就要标注。技术参考模型就是上这个项目用什么技术标准，比如说他想用这个技术标准，你这个是这个技术标准，不一样，它也能分析出来。
最后给大家讲一下指导重大IT项目建设。我以云计算平台建设为例。很多人讲了很多云，我只谈两点我的看法。从经济学角度来讲，云计算是集约化、规模化的运用，体现了规模经济、范围经济、专业化经济。规模经济不难理解，越规模越经济。范围经济就是长尾理论，做的东西越来越多，反而越经济。因为平台的特点。专业化经济是用专业的人做专业的事情。所以云计算有很强的经济学驱动力。从哲学角度来讲，学化学的知道，不光量变引起质变，结构的变化也会引起质变。就像金刚石跟石墨，只是结构变化导致这两种物质相去甚远，一个非常黑，一个非常透明，一个非常硬的，一个非常粉沫状的。我们的云计算也是结构变化，这种结构变化也会导致质变。所以很多人只是从技术角度理解它，很难理解它带来的变化。因为结构变化确实可以引起质变。关于云计算平台来讲，例如TOGAF连续系列，这四层的划分。比如Iaas放在基础架构层面。PaaS可以做两种，一种是安全、财务、人力资源，不分行业的，属于共同系统PaaS。还有一种是行业的PaaS，比如说医疗云、制造云等等。SaaS也分两种，一种是行业SaaS，还有一种就是组织特定SaaS，比如某个企业或政府特有的SaaS。这个也有利于我们分析，到底建哪层的PaaS。
这是我们根据对EA的理解画的云计算生态链图。我们把基本所能想到的软硬件和服务厂商都放到里面。这里面很复杂，我就只给大家讲几点。比如说看Iaas、SaaS和PaaS。还有一个是Daas，为什么单列出来？过去传统开发模式数据很难标准化，都是不同厂家开发，他们把数据一并拉进去考虑。而云的开发模式使我们有了这样一个条件，大家在云上面开发，数据是统一调用，可以标准化。给了这样一个技术的条件。还有一个是从数据的安全和数据的主权角度来考虑也必须要有这样一种机制。过去我们把数据这块都归为厂商，因为系统部署在我本地。但是现在不行了，比如你们用一些小的SaaS，大家不敢用，就是因为它很小，觉得它无法承担我的风险。我的数据比如存在百度、中国移动这类的，那么大家会敢用。他也接触不到我的数据，这是一种需求。还有从数据主权角度来讲，过去国外厂商都来中国提供这样的服务。现在云的服务，他们为什么不能很容易提供。因为数据也要在他那，如果没有Daas和SaaS分离，这个就涉及到数据主权的问题，还有数据安全的问题。
中间的PaaS也是作为云计算来讲，我们觉得云计算代表包括统一开发的平台，统一集成作为服务，包括上面DaaS。例如在政府行业，人口库、法人裤、视频等等，都是作为大的数据资源在上面提供服务，让老百姓、中小企业去参与做服务的提供和创新。苹果就是典型的模式，包括新浪微博的模式。新浪微博开放接口不是把个人隐私泄露，但是你也可以开发各种各样的应用。其实我们政府也可以这样，资源供社会使用。例如说我们有法人库等等，很多企业利用这些资源开发很多应用为大家服务。
比如说欧洲有家银行，他就是提供这样的平台。平台把客户资源数据共享起来，但是保护客户隐私。只是调用接口，然后针对这些也开发了很多小的应用，就满足了大家很多需求。这样一种平台的搭建，像银行只是把数据资源开放出来，为他也带来了客户的黏性。相信政府也有很多可以做的工作。
最后提两点建议：第一，利用体系架构方法，做好电子政务顶层设计。第二，利用顶层设计，开展基于云计算的下一代电子政务建设。谢谢大家！