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