伊利诺伊州，芝加哥：正如 Cap Gemini Ernst & Young (CGEY) 的解决方案设计师经理在芝加哥加速开发中心所声称的，Ashvin Vellody 的工作围绕着使企业软件系统相互对话。“我们开发的大型项目，需要以不同的行业规范类型提供给客户，”Ashvin 解释道。“CGEY 使用了世界上遵循 CMM 3 和 ISO 9000 的开发工具来提供任何类型的软件项目—自定义编码的 J2EE 产品、PeopleSoft 打包实施、集成项目或任何可能的情况。在我们的中心，我们提供方法、工具和人员以可预知的方式快速提供复杂系统。”
加速开发中心是 CGEY 交付方法学中的一个重要组件。它不仅提供专业环境中的基础架构、过程和人员，有助于满足合约中客户的严格最终期限，还为其设计人员提供工具和技术，通过更高的生产率支持加速交付。Ashvin 说，“由于环境很灵活，所以人们来到中心工作；您可以在利用我们的工具和环境的同时配置自己的项目小组工作空间。诸如此类的微小改变会带来生产率显而易见的提升，并可提供卓越的工作空间。还有一个完整的工具小组坐镇后方，帮助多个项目成功地完成交付。”
中心大部分的时间和资源都投入到构建系统间的连接。这就意味着为自定义构建的连接器进行编码，或使用即取即用的集成解决方案，或通常两者兼有。但对于所有进行中的编码和软件工作来说，Ashvin 的大部分时间都投入到了不涉及削减代码的任务；诸如计划、建模、设计，甚至协议之类的任务—软件集成后的“软知识”。
不同对象的不同集成需要
开始一个项目时，Ashvin 多项任务中的首要任务之一是，当新的集成系统完成时评估它的首要业务目标，以及什么类型的对象使用它—系统将首先服务内部用户、其它业务，还是服务终端客户？
“企业到企业 (B2B) 系统与企业到消费者 (B2C) 系统完全不同，”Ashvin 解释说。“B2C 系统就是我们通常说的“深入接触”系统。它直接与终端客户交互，因此它必须是面向用户的；界面外观应该十分友好，这就意味着格外注重用户界面。B2C 系统还提供对大量人员的服务。它的事务处理量不会很大，但会有大量人员利用这些服务。”
Ashvin 将此系统与 B2B 系统进行了比较，后者通常意味着简化复杂的商务处理，如自动化库存和订购，通常基于纸张（至少一部分）的过程，以及或许涉及到的旧的原有系统。
“界面外观的问题在 B2B 集成项目中并不总是很重要，但由于目标是简化做事的旧方法，因此涉及到的过程更加复杂。”Ashvin 说。“例如，我最近项目的客户是一家电信公司。该公司希望更好地处理客户的呼叫，使其呼叫中心的操作与后端计费系统之间的过程更加自动化。因此我们紧张忙碌了 11 个月，对 CRM 前端、后端计费系统进行了评估，并将一些体系结构部署到位。该项目用来简化商务过程，并且处理两个系统（原有计费系统和更现代化的 CRM）间的复杂事务。”
原有系统、Spaghetti 代码、金苹果，以及大的飞跃
根据 Ashvin 的说法，CGEY 已经看到了公司整个客户群集成项目的增长。这些集成中的大部分分为两大类—客户或者扩展原有系统，或者自动化过程，努力争取提高生产率。有时二者都需要。
由于目前预算紧缩的现实，各公司正试图一丝不漏地发掘原有系统的全部生产力。旧的应用程序并不总是在头脑中用现代的体系结构构建，并且将新旧应用程序相混合几乎是疯狂的。
Ashvin 说，“我们所面临的集成原有系统的挑战是双重的。首先，我们必须从系统中抽取出 spaghetti 代码和逻辑，而系统在过去的 30 年中可能已被反复构建或修改过多次。了解系统的人不总是可以接受改变，他们也可能不愿意共享知识。另一个挑战是识别所谓的项目“金成果”—新的做事方法的前提或全部意义。”
Ashvin 针对其最近的电信公司计费系统的项目指出，“计费十分复杂，一个过程可能涉及 20 个不同的领域。一些部门可能每星期更新一次原有计费系统。其它部门可能每日更新，不论怎样，这些过程一段时间后都一起进入了 spaghetti 代码集，我们必须从该代码集抽取逻辑。确定谁拥有这些数据，以及数据如何以一种简单的、“黄金标准”的方式在各部门间共享—为解决此问题，我们奔波了两个半月。”
当公司试图大幅提高生产率而集成系统时，其它的集成难题出现了。Ashvin 主持的一个有关汽车金融问题的现有项目就是一个很好的例子。
Ashvin 解释说，“该项目旨在根据汽车购买经验以及取得信贷审批来自动化客户和经销商交互的方式。这是三个汽车制造商的经销商协作努力的结果。假设一位客户想要购买一辆通用汽车公司的卡车或一辆福特轿车，不论情况怎样。通过此项目，经销商可以迅速地对贷款应用程序、信贷审批及 APR 等级等事物做出反应。该项目还可以确保三大汽车制造商的任何一个后端系统能够以一致的格式接收信息，并一致地向任何经销商发回信息。”
这样的项目通过自动化过程减少了书面工作和低效率的过程，从而获得了生产力的巨大飞跃。要确保经销商和汽车制造商都使用类似的数据、类似的格式，并通过类似的过程使用数据—获得生产力的飞跃—需要清楚的了解 B2B 集成问题。
了解 B2B 系统
汽车行业是面临集成挑战这一大趋势的行业之一。要帮助厂家和公司构建交互式 B2B 系统，一些行业提出了他们自己的标准—如汽车行业的 STAR 标准。
Ashvin 说，“STAR 是特定于汽车零售行业的、符合 SOAP 的最出色的 xml 模式。例如，另一个纵向标准用于商业采购供给空间—那就是 ebXML 标准。”
这些纵向标准说明了系统如何定义数据，需要什么数据，什么数据是可选的，以及应该如何治理消息。其它行业正在采用诸如 RosettaNet 一类的通用标准。根据客户端状况，一个或多个这种标准的要求可以支配适用于设计人员的集成方法。
其它 B2B 集成方法包括通常所说的 私有交易，其中行业中的某个大公司有足够的惯性要求其供给商仅采用一个基础架构。“私有交易由一个具有金融和行业影响力的主要参与者建立‘这就是我作为企业与你交流的方式’”Ashvin 解释说。
图：集成体系结构
Ashvin 将沃尔玛作为实践中一个私有交易的实例。“沃尔玛说，其所有的供给商都必须使用这种电子交易系统来与沃尔玛进行交易。然后供给商必须实施特定的一年或一段时间，并预备好通过沃尔玛的交易系统进行交易。这一切仅通过邀请来实现，并且进行集成相对比较轻易”。但是 Ashvin 很快解释了沃尔玛工作的内部系统决定了集成过程，而不是单一的外部方法（如 ebXML）。
解决 B2B 集成难题的另一方面是了解贸易合作伙伴治理 (TPM)。TPM 是 B2B 过程的集合，它明确地解决了供给商和厂商交易过程中的工作流和交互问题。TPM 还提供一致的方法与商务处理通信。Ashvin 说“TPM 设计用于解决公司的销售和供给链问题。例如，作为公司怎样在供给链中治理所有不同的贸易合作伙伴？怎样维护他们？怎样与他们进行交易？与他们进行调解的过程怎样？TPM 是 B2B 集成中的一个重要部分”
建模的重要性
不论您集成了行业标准、开放标准，还是受限于私有交易的体系结构，作为设计人员最终您必须开始定义数据、创建对象，并且开发出治理其余项目的模型。
“这是我最无法忍受的事情，” Ashvin 说。“集成项目的一大难题是确定真实的记录和实体存在何处。例如，一家电话公司有十个不同的部门与名为“客户”的抽象对象交互。每个部门组织客户的方式不同，识别客户的方式也不同。对这些不同的部门采用一个通用的定义很难。”
Ashvin 最近的电信公司计费系统项目证实了建模是十分复杂的工作。“在知道了客户的地址和位置的前提下我们才能为他们建模。这对所有的部门都适用，在计划过程中所有的商业用户也都适用，但是没有人了解直到我们开始实施它才能起作用。假如您仅通过一个人居住的位置来识别他/她，那么假如他们换了地方该怎么办？你打算获得多条记录，然后通过两个不同的位置识别那个人？这是关于人们的电力计费的系统，因此系统中的问题将影响到人们的日常生活。”
Ashvin 的小组最终构建了一个变通方法，经过一夜的努力解决了地址/位置的难题。这种现实世界的实例说明了在实施开始前和整个实施过程中，完全在系统模型上工作非常重要。建模应该是优先考虑的问题，并且应该从尽可能多的角度对工作流和过程检查给予预期时间。Ashvin 建议，对于一个历时 1 年的复杂项目来说，在编写代码前应该花费大约 3 个月的时间来为工作流和过程建模。
商务过程治理
新的商务过程治理 (BPM) 工具有助于公司组织模型以及商务过程在应用程序中工作。Ashvin 解释道，“BPM 是一层说明，它位于集成代码之上。BPM 为商务用户提供调整模型和改变工作流的功能。BPM 工具是十分图形化的，并且探查代码更改在底层透明地进行—或者至少应该透明地进行。BPM 出现的时间尚短，但这些工具为商务用户提供了用图形化方式处理事务的能力，例如改变购买订单的工作流。一个商务用户—并且从事此行的人应该非常具有商业头脑—可以改变 PO 过程，因此能够通过在 BPM 工具中改变图形模型在不同的部门中共享 PO。”
Ashvin 指出，只需使用即取即用的解决方案（如 webMethods 或 SeeBeyond）就可以很好地连接代码，但是应用程序会发展或改变，因此商务用户需要能够治理那些改变并相应地改变商务过程。这就是增加的 BPM 对集成设计师的增值所在。它答应工作流为商务用户“按订单生产”。
改变预备就绪
设计人员应该意识到，
