《面向更加敏捷、更加灵活的行业解决方案和资产的通用业务》由会员分享，可在线阅读，更多相关《面向更加敏捷、更加灵活的行业解决方案和资产的通用业务（22页珍藏版）》请在金锄头文库上搜索。
1、 版权所有 IBM 公司 2009商标 面向更加敏捷、更加灵活的行业解决方案和资产的通用业务组件和 服务，第 1 部分: 共享业务服务 (SBS) 方法的基础知识 - 概述第 1 页，共 22面向更加敏捷、更加灵活的行业解决方案和资产的通用业务 组件和服务，第 1 部分: 共享业务服务 (SBS) 方法的基础知识 - 概述Min Luo 执行架构师 IBMJin Ge 咨询 I/T 架构师 IBMJia Tan 软件工程师 IBMLei Zhang 助理 I/T 架构师 IBMPeng Tang 软件工程师 IBMHeQing Guan (Hawking) 软件工程师 IBM2009 年 4
2、月 27 日面向服务的体系结构 (SOA) 以及模型驱动的体系结构和业务开发 (MDA/D) 通过重用和基于资产 的行业解决方案，在支持业务灵活性和敏捷性方面提供了功能强大的组合。这个分为两部分的系 列文章将讨论如何利用许多经过验证的最佳软件工程实践，特别是那些用来建模通用结构和某些 情况下非结构化业务实体的元数据驱动的体系结构类型。在本系列的第 1 部分中，我们将讨论软 件工程基础知识、建议的方法，同时还将解决一些明显影响业务灵活性、对更改的适应能力以及 敏捷性的关键业务和技术问题。developerW 服务，第 1 部分: 共享业务服务 (SBS) 方法的基础知识 - 概述第 2 页，共
3、221. 引言创建可以轻松采用的灵活而敏捷的系统以满足不断更改的业务需求，并以较低的 IT 成本真正提供期 望的业务价值，这使得公司在定位和利用 IT 的方式上发生着根本性的转变。我们在创造和重新发明 大量新旧烟道式呆板遗留系统方面的几十年拼搏足以证明这项任务非常不易。虽然我们针对全球所 有行业的类似业务问题设计、实施并管理了一些业务解决方案，但是无法轻松地将现有的解决方案 复制到类似的客户端，甚至无法用有效方式重用任何现有的已知解决方案。那些解决方案是根据具 体行业、业务领域和客户在其早期设计阶段的需求制定的，无法建立可追踪性。重用和更加重点管 理不断更改的业务需求变得几乎不可能。面向对象的
4、设计和编程的出现首先为我们带来了细粒度的 业务对象模型（如非常令人期望的 IBM San Francisco Project），然后是组件化的特定于行业的模型 和框架（例如，IBM 针对金融/保险行业的 IFW/IAA），但是，它们创建、建模的方法以及高效地将 其转换或应用于更改的笨重性、复杂性和呆板性使其很难自定义或将其扩展到特定的解决方案。1.1 业务敏捷性和高效性的两大问题正如许多行业调查所显示的那样，特别是 IBM 年度 CEO 调查（2008 年 1 中最近的一次调查）， 一些组织由于内部和外部更改而被弄得焦头烂额，许多组织一直在努力挣扎，以便在不断变化而又 不确定的全球新经济中求得
5、生存机会。几乎所有的 CEO 都在尝试采用其业务模型来满足其客户不断 变化的业务需求，同时以更加敏捷和有效的方法创新和改进业务解决方案。另一方面，1 确认，其 适应这些变化的能力与所面临的挑战之间的差距（即所谓的“更改差距”）正在加大，从 2006 年到 2008 年，几乎增加了 3 倍。有效地管理这些更改并将这些更改转换为实际机遇变得非常重要。遗憾的是，处理更改一般被视为概念性难题，从技术层面讲很难而且具有风险。从业务角度看，更 改的可见性差，更改的原因不明显、模糊，以及缺乏有效要求、更改表示和管理机制使得将自动化 程序应用于这些更改成为一项棘手的事。在 IT 方面，没有正式的转换机制将需求
6、及其不断的更改 转换为可执行的结构化程序。更糟的是，这些更改无法提前知道，并且可能会在很长一段时间之后 作用于软件，也很难建立和维护从源到程序的可追溯性，而必要的修改产生的连锁影响会引发大量 的结构、编程和潜在的部署工作。缺乏可稳定发展且具有普遍适应性的软件表示形式，缺乏充分而 有效的软件工程设计过程和工具，当然还有不断加快的更改步伐，所有这一切进一步恶化了这种情 况。1 中的另一个重要发现是对我们的方法提出了进一步要求，CEO 不能再只关注小范围的问题，而是 要管理更不确定的范围更广的业务领域，这是因为他们必须与其合作伙伴和客户协作来实现双赢。 对于大多数组织来说做到这一点并非易事，因为直到
7、现在，还没有人能够真正拥有一个合理、易于 操纵的业务视图：组织、流程，特别是更改在各个方面造成的影响。而且，我们现有的 IT 系统，尤 其是我们所设计、开发和集成现有系统的方法与此“全局”和“更加宽泛的业务视图和机会”不一致。应用经常使用的分解（“分治处理”）技术以减少问题复杂性在克服软件复杂性方面不如硬件那么成 功，这是因为对于业务问题或支持软件系统而言，实现充分且干净的可分解性要困难得多，支持业 务需求的更改一般比较频繁，且多数情况下这些更改更加显著。此外，更加困难的是关联和映射所 作的更改，以及是否需要调整系统的其他部分，有些更改会显著地重组系统，这会使事情变得更加 困难。另一方面，众所
8、周知，跨行业和业务领域有大量业务相似点。但是在过去，我们几乎从未有意或成 功地利用这些丰富的信息创建、重用我们的知识和拓展我们的能力。更糟糕的是，几乎所有的企业 都允许各个部门和项目组设计和实施仅满足其自己需要的业务功能，而没有更多地考虑可能会重用 服务，第 1 部分: 共享业务服务 (SBS) 方法的基础知识 - 概述第 3 页，共 22和可以支持它的适当体系结构。因而，企业中会激增大量类似的组件，从而导致整个软件系统结构 进一步降级，使业务转换和集成非常困难。更甚的是，类似的模型和代码片段经常是仅做一些修改 就被复制到一个程序的许多位置，而跨应用程序或系统复制时就更具破坏性，这使跟踪和适应
9、非常 难，维护成本明显提高。高效重用和基于资产的开发需要清楚地看到各种需求及其变化和更改。如果能够高效利用这些已知 的类似点，并且能够以人可以理解、机器可以使用并且可再利用的方式表示它们，我们不仅可以改 善需求管理，更重要的是，可以在所有精度级别将这些业务类似点转化为组件甚至是软件类似点， 从而消除或减少跨系统的冗余。这可以通过利用通用的结构将不断发展的需求和更改的类似模式统 一起来实现，因而，重用从过去的经验中获得的知识并且能够在未来进行高效地实施将变得切实可 行。我们建议的方法是要促进对业务类似点的使用，并将它们转化为可重用和可扩展的组件或软件模 式。我们以许多知名的软件工程实践为基础，计
10、划实施一个新的灵活和可扩展的业务驱动型且与行 业一致的框架，该框架可帮助 CEO 了解更改及其影响，帮助 CIO 制定实际规划，以便在资源限制范 围内应对这些更改，同时最大化对现有投资的潜在利用，帮助架构师和开发人员节省时间和精力， 将不断变化的更改需求转化为可适应的解决方案。1.2 业务流程优化将产生更高的效益业务流程优化将产生比任何 IT 系统改进更高的业务效益。一般情况下，问题是我们将如何协调业务 目标和机会以通过业务和系统转化实现潜在的改进，在何处以及如何管理和处理这些更改，如何快 速将机会转化为灵活的 IT 解决方案，以便更加高效地支持不断发展的业务需求。面向服务的体系结构、模型驱动
11、的业务开发都为我们提供了新的、功能强大的方法，通过更加高效 地将业务问题与 IT 实现相关联，特别是通过重用和基于资产的行业解决方案设计和开发，加速实现 业务过程的连续提高或优化。但是，如果不对流程、组件和服务的建模、链接或关联、映射到 IT 系 统的方法进行大量修改，以便在出现任何更改时用方便的可追溯性评估影响，此类转化很难实现。我们的方法将提供一个自然基础，以加速从业务流程到 IT 能力的有效映射和转化，同时各自在业务 流程中利用固有的类似点。1.3 利用现有的 IT 投资建议的方法还将减少在过去几十年让企业饱受其害的那些“经典”老问题。该方法将更加方便地加快 对此类遗留系统的转化，并在我
12、们的通用且可扩展的解决方案框架之上支持对它们的服务。例如， 我们可以利用许多内部 IBM 资产（例如，IFW、IAA、WCC、SanFransisco 等）和许多业务建模工作 （如可为实际客户项目交付的 Component Business Modeling (CBM) 和行业图、GBS 合作）。外部行 业参考模型和标准（如 ACCORD、IxRetail）也可以成为我们的方法的关键增补。此项工作基于我们跨许多行业领导和设计大型端到端客户合作的经验总结，同时又对各种行业领先 的软件工程最佳实践进行了完善。2. 共享业务服务 (SBS) 方法的基础知识 概述过去几十年来软件工程设计方面的重要改良
13、发展已为我们提供了各种能力，促使我们从以下几方面 讨论所建议的方法：developerW 服务，第 1 部分: 共享业务服务 (SBS) 方法的基础知识 - 概述第 4 页，共 222.1 面向对象的分析和设计 (OOAD) 2从单片式大型机应用程序到客户端-服务器体系结构，我们看到了从系统驱动用户到用户驱动系统开 发的发展，而面向对象的技术使我们更接近业务驱动型系统。对象就是对实际业务概念（例如人员、帐户或汽车）的抽象以及对这些实体之间关系的捕获。它提 供一种业务用户友好的机制，可以将现实世界的映像与可能的系统实现联系起来。OOAD 中的关键 技术包括抽象、分解和分离关系（行为与静态特征）、
14、模块化以及潜在的内部可操作组件。从编程人员角度看，抽象可以隐藏某些基本复杂性，但是仍需要先填充所有省略的详细信息，然后 才能从抽象的模型或程序规范中（自动）生成完整且可执行的程序。仅在某些狭窄的应用领域中， 我们可以对应用程序域语义进行假设并有效表示它们，但应用这些基于生成器的解决方案是否可以 极大地提高编程人员的工作效率？分解是使复杂问题变得易于处理的最常见的技术之一。我们可以将复杂的系统分解为几个协作部 分，进一步简化可以获得更多重用的建模和开发流程。实际上，这些“部分”就是粒度更粗的对象， 我们通常称其为“组件”。它们是低级细粒度对象的更加紧密耦合的聚合体。因此，基于组件的业务 软件开发
15、 (CBD) 3 可以进一步将业务和技术实体抽象到一个可以简化建模流程和开发的级别。总之，为了取得不断发展，我们需要能够用易于理解的分类法将业务需求、必要的程序设计和代码 合并为一个统一的表示形式，同时设计信息可广泛应用，易于扩展，且能够降低维护成本和极大地 改进程序的可理解性。2.2 分析和设计模式通常，模式 4 是指那些解决某些重复出现的业务分析/设计问题的完全确定的且经过验证的解决方 案。4 侧重于软件的“设计模式”（如对象结构、创建和行为），它们使架构师和开发人员能够成功 重用现有的经验证的软件设计或解决方案组件，以便在不增加工作量的同时更加高效地创建质量更 高的应用程序。5 引入了“分析模式”这一概念，这些模式是通用的面向业务的对象模型及其作为元 类与定型的属性和操作的交互，它们代表在更多面向业务的建模中可能经常遇到的某些情形。一旦 掌握了这些模式，软件专家就可以轻松地超越他人，因为他能够认识这些重复出现的业务和技术问 题，知道是否有经验证的解决方案可用，以及如何有效地应用它们。2.2.1 分层系统体系结构一种最经常使用的体系结构模式是分层系统体系结构，其中系统被分为一系列半独立层，且每个阵 列都向上层提供一项服务，并可利用由下层提供的其他服务。最著名的此类结构是 OSI 的 7 层网络 模型 6。2.3 原型 7正如前面所讨论的那样，业务类似性
