基于云的跨企业信息系统会取代企业外部网吗？

云计算正在快速成为当代最耀眼的技术之一。它悄悄起源于若干先进技术，例如网格计算、虚拟化、SalesForce.com 新型基于订购的业务或者 Amazon 的电子商务平台。最近，大型软件厂商对云计算表现出了浓厚的兴趣，其定义如下：

“一种新型的计算模型，数据和服务分布于大规模可扩展的数据中心，可以通过任何连接的网络设备访问。”

就个人而言，我认为云计算令人兴奋，它会刺激大量的创新，一方面是因为它提供了根据使用付费（pay-per-use）的基础设施，降低了创新的成本和风险，但更主要是因为它提供了一种构建信息系统的基础设施，由需要协作实现共同目标的不同组织分享，例如，跨企业信息系统。

本文专注于云计算领域的跨企业信息系统架构。第一部分简要介绍了云计算，第二部分则研究了云计算中的跨企业信息系统。

云计算介绍

云计算在很多方面把通常“痛苦”的问题留给了别人：

• 资本投入和风险
• 基于用户需求和工作负载的向上或向下扩展
• 管理服务等级协议（Service Level Agreement）
• 管理问题和事故
• 能够无缝升级到软件新版本，特别是基于兼容的原因
• 保证数据、流程和基础设施安全
• 支持用于灾难恢复目的的冗余数据中心
• 有效管理基础设施老化问题
• …

我们可以把云计算模型分为三种：

• 基础设施即服务（Infrastructure-as-a-Service，IaaS）
• 平台即服务（Platform-as-a-Service，PaaS）
• 软件即服务（Software-as-a-Service，SaaS）

IaaS的最佳例子是 Amazon Web 服务。Amazon 提供了三种基本服务：存储（S3）、计算（EC2）和队列（SQS）。基础设施即服务的关键价值是“弹性”，例如，可以基于特定时间点上的使用情况购买或放弃基础设施元素（存储、服务器…）。例如，Amazon 对服务器按小时收费，对存储按 Gb/ 月收费。

PaaS则是提供了一系列工具，构建于 IaaS 基础之上，并享受它的灵活性、健壮性和安全性，资金投入却不多。PaaS 的目标是使开发人员创建由云托管的信息系统。现代 PaaS 的目标是能够利用云提供的服务，表现层应该与 Web 和 mashup 技术很好的集成。

例如，BPM-as-a-Service 是一种特殊的 PaaS。现在，大多数 PaaS 是以数据为中心，而不是以过程为中心。它们通常允许你定义数据模型和不同的形式和外表以协作。业务逻辑通常在动作中定义，遵循 MVC 模式。以数据为中心的 PaaS 可能难以构建用于协同业务伙伴之间活动的系统。

PaaS 背后的一个核心创新是 Dev 2.0 模式（应用 Web 2.0 技术的开发工具、敏捷方法和域特定语言的大量使用，而不是多用途程序设计语言）的出现。Dev 2.0 使开发人员更具生产力，让非开发人员参与业务逻辑关键元素的定义和验证，例如业务流程、业务规则或者表单定义。

另一个很多 PaaS 的核心创新是能够通过表现层或者一系列服务（组成新的解决方案）透明的展示信息系统，不论是不是基于云。

SalesForce.com 是SaaS的开拓者，用事实表明了采用“软件即服务”是可行的、节约成本的、安全的。他们在云计算刚刚萌芽时就展现了这种模式的强大力量并建立了整个云计算生态系统。

如今，云计算在很多方面表现出了活力：

• 从财务角度来看，云计算集中了大量难题并把这些风险施加到拥有这些资产的人身上。企业变成了基于自身需要租赁特定资产的佃户。试问哪一位首席财务官不乐于把 IT 资本支出转为运营成本呢？毕竟平均有 50% 的购买软件从来没有真正用起来。
• 从开发角度来看，云计算结合 Web 2.0 使拥有业务逻辑的任何人都可以参与开发或者质量保证过程。变化可以在数分钟或者数小时内发生，而不是几周或者几个月之后。
• 从工作活动角度来看，云计算使企业能够跨越组织界限把人们聚集到一起并提供必要的知识来执行任务。

跨企业信息系统

MEIS 的目标是快速建立一种合作伙伴关系，不论是为了提高知名度、管理意外、促进电子数据交换、协助兼容或是加速合资或合并。

直到今天，跨企业信息系统往往采用由为了某一目的多方协作中的一方托管的门户网站来实现，无论是供应商的 OEM 门户，还是零售商的分销门户。

这种方法导致了明显的低效性、风险和缺乏灵活性，因为其中一方要承担所有的建设、维护和运营成本。业务流程通常会尽可能地简单以满足所有参与方的共同需求。最后但并非最不重要的一点是，门户网已经被证明难以与参与方的系统和流程集成，因为它们没有公开与表示层关联的服务。

如今，云计算通过跨企业信息系统使这一点成为可能，相关各方都能够参与系统的开发，从根本上平衡了开发成本，同时提供了更优异的能力与任意一方的现存系统和基于 web 的企业内部网集成。

图 1 MEIS 技术架构

图 1 显示了构建于平台即服务基础之上的跨企业信息系统。其中包括：

1. 灵活的表现层
2. 高级 Dev 2.0 工具，由开发人员或者非开发人员使用
3. 业务活动监控和报告工具
4. 运行 PaaS 引擎的先进基础设施
5. 单登陆服务
6. 服务注册
7. 与 SaaS（如 SalesForce.com、Dun&Bradstreet、FedEx…）的连接器
8. 与现存系统的集成

显示层需要足够灵活以支持通过不同的技术和跨域广泛的设备（浏览器、手机、RFID…）执行用户任务。

开发工具必须从某种程度上是技术中立的、基于标准的、直观的、支持快速实现、质量保证和部署过程。

业务活动监控和报告必须易于定制以满足各方的需求。

理想情况下，MEIS 的基础 PaaS 运行在一个先进的 IaaS 上，保证了灵活性、健壮性、可靠性和安全性。

组织和角色必须易于管理，并且可能依赖于单登陆基础设施。各方必须能够无需其他方协助即可管理自己的用户。

面向流行服务和解决方案的连接器是开发高品质 MEIS 的一个基本因素，不论是收集物流或者市场信息。这些连接器将提供一种技术访问服务，融合了基于 web 的技术（SOAP、ReST、ftp、http 等等）和格式（EDI、XML 等）。

人力工作流必须无缝集成到 MEIS 中。在 MEIS 流程环境中构建是高度迭代的，流程可能从以人为中心进化为部分自动化：这种演变必须尽可能地简单。

最后但并非最不重要的一点是，平台必须确保与每一方现存系统的有效整合。特别是这意味着平台必须支持开放的协作流程和私有的整合流程。

以过程为中心的 PaaS 的逻辑架构如图 2 所示。许多 PaaS 过于以数据为中心了，没有提供建模和执行过程的能力。这种业务逻辑必须单调的用 MVC 框架编码，难以改变、监控和报告。

使用以过程为中心的 PaaS 对跨企业信息系统至关重要，因为它们帮助企业协同工作并同步其活动。如今，这种同步通常用过电子邮件或者传真的方式完成，会导致错误和低效。例如在航天工业中，多企业的一个关键流程是运输和接收部分。对于如何运输和接收，供应商和买家必须衡量关键指标（尺寸…），然后比较它们的结果。这会有测量误差、真正的差异…会引起异常，未来需要管理和审计这些。这表明跨企业可跟踪性非常重要，比如化学品或者制药行业。

图 2 以过程为中心的 PaaS 逻辑架构

结论

通常来说，在一个商业圈中（比如供应链或者一个产业），没有哪一个独立的商业伙伴有能力（或者愿望）为整个商业圈提供所需的 IT 资源。以过程为中心的平台即服务结合成的云计算提供了开发一种新型企业系统——跨企业信息系统的难得机会。

关于作者

Matthieu Hug 是 RunMyProcess.com 的首席执行官，RunMyProcess.com 是一家以过程为中心的 PaaS 供应商。他毕业于 SupElec，并在 Georgia Tech 获得硕士学位。

查看原文： Will Cloud-based Multi-Enterprise Information Systems Replace Extranets?

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。