现在，企业正掀起Web 2.0应用的初次浪潮。而国际商业机器公司（IBM）、甲骨文公司（Oracle）、微软公司（Microsoft）和太阳计算机系统公司（Sun）等一批大名鼎鼎的公司已经发布了各自的企业级社区构建工具，包括Wiki、网络日志（Blog）、大众分类法、论坛、搜索、即时通讯（IM）、混搭应用工具，等等。所有这些工具都基于安全的、可管理的、并且集成的软件基础之上。而且，思爱普公司（SAP）、毕益辉系统公司（BEA Systems）、红帽公司（Red Hat）、Vignette公司，乃至思科公司（Cisco）和英特尔公司（Intel）也开始加入到这一阵营中来，这些公司通过收购Web 2.0公司，已经开始提供面向企业的社区软件产品。

　　但是，在将友好但难以控制的Wiki应用于你的ERP系统之前，不妨思考一下下列建议——企业应用Web 2.0的7项规则。

　　在服务导向架构（SOA）框架上构建Wiki。无论你是否是SOA部门，都要确保基于SOA，采用JSR 168规范、业务流程执行语言（Business Process &#101xecution Language）、简单对象访问协议（SOAP）和Web服务描述语言（Web Services Description Language），部署Web 2.0应用。最重要的是，确保你的解决方案使用或带有一个UDDI（统一描述、发现和集成协议）注册，用户因而能迅速地构建混搭应用，而开发人员也可以将那些混合应用集成到更广泛的业务流程中。同时，这也会有助于用户和开发人员达到合规要求。

　　对访问控制进行优先级排列。我们绝不仅仅是在谈论单点登录，而是切实地对基于角色的、不知来源的内容和数据安全进行管理。确保你的Web 2.0框架采用Sun的Java System Identity Server等集中化的身份和访问管理解决方案，或能与之进行集成；至少，它要保证源（数据库、搜索索引、ERP系统等）的安全性。否则，如果你的首个混搭应用将知识产权或遵从健康保险流通与责任法案(HIPAA)的客户记录公之于众的话，那它必定也是你所构建最后一个。

　　不要恐惧对消息服务器的依赖。有些解决方案是在Lotus Sametime等电子邮件和日历解决方案的基础上开发的。从长期灵活性的角度看，这听起来不免有些奢侈，比如如果出现厂商锁定的情况，你的Web 2.0系统也会受到影响。但是，将消息、日历和Web 2.0技术结合起来，实现协同，是值得的，尽管这也许会阻碍任何从消息平台迁移至其他平台的计划的执行。

　　信任你的用户，但要进行验证。确保你的Web 2.0软件始终对其新用户建立的复合应用（混搭应用）进行监测。你必须能对允许他们分隔、使用哪些原材料进行控制，并监控所有应用源的应用等级，以符合规定的关键性能指标和服务水平协议。参见本文与UDDI服务器集成相关的第一条规则。

　　有利于商业用户。选择那些可以激励你的员工通过RSS种子利用数据源构建混搭应用、在其销售流程中嵌入即时通讯（IM）功能、或者能对你的应用软件的Wiki风格发表评论的软件。

　　如果你试图避开通常的软件开发周期，会即刻受到惩罚。秘诀在于，要确保你的Web 2.0解决方案可以对用户的想法进行控制。参见有关监控的第四条规则。

　　你不一定需要门户软件，但它们确实能帮上大忙。你选择的Web 2.0解决方案应是IBM、BEA、Oracle、Sun或其他厂商提供的门户解决方案的一部分，或者能与之协同工作。因为这些门户解决方案已经具备相当的Web 2.0功能，因此可以充当许多用户界面开发工作的推送平台，特别是对Wiki、网络日志（Blog）和大众分类法而言，尤其如此。这样，开发时即可在节省大量时间和精力的同时极大地提高解决方案的灵活性，比如说，你就可以将混搭应用作为可嵌入式的Portalet组件输出给用户。

　　重视用户。千万别指望弄个网络日志或大众分类法网站就坐等天下掉馅饼。选择那些按照用法进行某种形式的等级排列，并为内容、服务、以及与之互动的人赋值的软件，每个人都有一个值，而每个元素都被以标签标记，从而建立起令人信赖、又兼具权威和专业知识的网站，就像Digg.com一样。而网站收集到的用户信息再被反馈到系统，进行优先级排列，以弄清哪些信息对现有的商业流程最有益。

　　在选择Web 2.0解决方案时，牢记这些规则，你就能抓住良机，全面满足IT管理和风险管理的要求。你也就能给那些普通商业用户留下深刻印象，也许还能以“我”的威力对那些成熟的商业实践产生影响。聆听内心的声音，直到它心满意足为止。