创建可以轻松采用的灵活而敏捷的系统以满足不断更改的业务需求，并以较低的 IT 成本真正提供期望的业务价值，这使得公司在定位和利用 IT 的方式上发生着根本性的转变。我们在创造和重新发明大量新旧烟道式呆板遗留系统方面的几十年拼搏足以证明这项任务非常不易。虽然我们针对全球所有行业的类似业务问题设计、实施并管理了一些业务解决方案，但是无法轻松地将现有的解决方案复制到类似的客户端，甚至无法用有效方式重用任何现有的已知解决方案。那些解决方案是根据具体行业、业务领域和客户在其早期设计阶段的需求制定的，无法建立可追踪性。重用和更加重点管理不断更改的业务需求变得几乎不可能。面向对象的设计和编程的出现首先为我们带来了细粒度的业务对象模型（如非常令人期望的 IBM San Francisco Project），然后是组件化的特定于行业的模型和框架（例如，IBM 针对金融/保险行业的 IFW/IAA），但是，它们创建、建模的方法以及高效地将其转换或应用于更改的笨重性、复杂性和呆板性使其很难自定义或将其扩展到特定的解决方案。
正如许多行业调查所显示的那样，特别是 IBM 年度 CEO 调查（2008 年 [1] 中最近的一次调查），一些组织由于内部和外部更改而被弄得焦头烂额，许多组织一直在努力挣扎，以便在不断变化而又不确定的全球新经济中求得生存机会。几乎所有的 CEO 都在尝试采用其业务模型来满足其客户不断变化的业务需求，同时以更加敏捷和有效的方法创新和改进业务解决方案。另一方面，[1]确认，其适应这些变化的能力与所面临的挑战之间的差距（即所谓的“更改差距”）正在加大，从 2006 年到 2008 年，几乎增加了 3 倍。有效地管理这些更改并将这些更改转换为实际机遇变得非常重要。
遗憾的是，处理更改一般被视为概念性难题，从技术层面讲很难而且具有风险。从业务角度看，更改的可见性差，更改的原因不明显、模糊，以及缺乏有效要求、更改表示和管理机制使得将自动化程序应用于这些更改成为一项棘手的事。在 IT 方面，没有正式的转换机制将需求及其不断的更改转换为可执行的结构化程序。更糟的是，这些更改无法提前知道，并且可能会在很长一段时间之后作用于软件，也很难建立和维护从源到程序的可追溯性，而必要的修改产生的连锁影响会引发大量的结构、编程和潜在的部署工作。缺乏可稳定发展且具有普遍适应性的软件表示形式，缺乏充分而有效的软件工程设计过程和工具，当然还有不断加快的更改步伐，所有这一切进一步恶化了这种情况。
[1] 中的另一个重要发现是对我们的方法提出了进一步要求，CEO 不能再只关注小范围的问题，而是要管理更不确定的范围更广的业务领域，这是因为他们必须与其合作伙伴和客户协作来实现双赢。对于大多数组织来说做到这一点并非易事，因为直到现在，还没有人能够真正拥有一个合理、易于操纵的业务视图：组织、流程，特别是更改在各个方面造成的影响。而且，我们现有的 IT 系统，尤其是我们所设计、开发和集成现有系统的方法与此“全局”和“更加宽泛的业务视图和机会”不一致。
应用经常使用的分解（“分治处理”）技术以减少问题复杂性在克服软件复杂性方面不如硬件那么成功，这是因为对于业务问题或支持软件系统而言，实现充分且干净的可分解性要困难得多，支持业务需求的更改一般比较频繁，且多数情况下这些更改更加显著。此外，更加困难的是关联和映射所作的更改，以及是否需要调整系统的其他部分，有些更改会显著地重组系统，这会使事情变得更加困难。
另一方面，众所周知，跨行业和业务领域有大量业务相似点。但是在过去，我们几乎从未有意或成功地利用这些丰富的信息创建、重用我们的知识和拓展我们的能力。更糟糕的是，几乎所有的企业都允许各个部门和项目组设计和实施仅满足其自己需要的业务功能，而没有更多地考虑可能会重用和可以支持它的适当体系结构。因而，企业中会激增大量类似的组件，从而导致整个软件系统结构进一步降级，使业务转换和集成非常困难。更甚的是，类似的模型和代码片段经常是仅做一些修改就被复制到一个程序的许多位置，而跨应用程序或系统复制时就更具破坏性，这使跟踪和适应非常难，维护成本明显提高。
高效重用和基于资产的开发需要清楚地看到各种需求及其变化和更改。如果能够高效利用这些已知的类似点，并且能够以人可以理解、机器可以使用并且可再利用的方式表示它们，我们不仅可以改善需求管理，更重要的是，可以在所有精度级别将这些业务类似点转化为组件甚至是软件类似点，从而消除或减少跨系统的冗余。这可以通过利用通用的结构将不断发展的需求和更改的类似模式统一起来实现，因而，重用从过去的经验中获得的知识并且能够在未来进行高效地实施将变得切实可行。
我们建议的方法是要促进对业务类似点的使用，并将它们转化为可重用和可扩展的组件或软件模式。我们以许多知名的软件工程实践为基础，计划实施一个新的灵活和可扩展的业务驱动型且与行业一致的框架，该框架可帮助 CEO 了解更改及其影响，帮助 CIO 制定实际规划，以便在资源限制范围内应对这些更改，同时最大化对现有投资的潜在利用，帮助架构师和开发人员节省时间和精力，将不断变化的更改需求转化为可适应的解决方案。
业务流程优化将产生比任何 IT 系统改进更高的业务效益。一般情况下，问题是我们将如何协调业务目标和机会以通过业务和系统转化实现潜在的改进，在何处以及如何管理和处理这些更改，如何快速将机会转化为灵活的 IT 解决方案，以便更加高效地支持不断发展的业务需求。
面向服务的体系结构、模型驱动的业务开发都为我们提供了新的、功能强大的方法，通过更加高效地将业务问题与 IT 实现相关联，特别是通过重用和基于资产的行业解决方案设计和开发，加速实现业务过程的连续提高或优化。但是，如果不对流程、组件和服务的建模、链接或关联、映射到 IT 系统的方法进行大量修改，以便在出现任何更改时用方便的可追溯性评估影响，此类转化很难实现。
我们的方法将提供一个自然基础，以加速从业务流程到 IT 能力的有效映射和转化，同时各自在业务流程中利用固有的类似点。
建议的方法还将减少在过去几十年让企业饱受其害的那些“经典”老问题。该方法将更加方便地加快对此类遗留系统的转化，并在我们的通用且可扩展的解决方案框架之上支持对它们的服务。例如，我们可以利用许多内部 IBM 资产（例如，IFW、IAA、WCC、SanFransisco 等）和许多业务建模工作（如可为实际客户项目交付的 Component Business Modeling (CBM) 和行业图、GBS 合作）。外部行业参考模型和标准（如 ACCORD、IxRetail）也可以成为我们的方法的关键增补。
此项工作基于我们跨许多行业领导和设计大型端到端客户合作的经验总结，同时又对各种行业领先的软件工程最佳实践进行了完善。
  |
|
过去几十年来软件工程设计方面的重要改良发展已为我们提供了各种能力，促使我们从以下几方面讨论所建议的方法：
从单片式大型机应用程序到客户端-服务器体系结构，我们看到了从系统驱动用户到用户驱动系统开发的发展，而面向对象的技术使我们更接近业务驱动型系统。
对象就是对实际业务概念（例如人员、帐户或汽车）的抽象以及对这些实体之间关系的捕获。它提供一种业务用户友好的机制，可以将现实世界的映像与可能的系统实现联系起来。OOAD 中的关键技术包括抽象、分解和分离关系（行为与静态特征）、模块化以及潜在的内部可操作组件。
从编程人员角度看，抽象可以隐藏某些基本复杂性，但是仍需要先填充所有省略的详细信息，然后才能从抽象的模型或程序规范中（自动）生成完整且可执行的程序。仅在某些狭窄的应用领域中，我们可以对应用程序域语义进行假设并有效表示它们，但应用这些基于生成器的解决方案是否可以极大地提高编程人员的工作效率？
分解是使复杂问题变得易于处理的最常见的技术之一。我们可以将复杂的系统分解为几个协作部分，进一步简化可以获得更多重用的建模和开发流程。实际上，这些“部分”就是粒度更粗的对象，我们通常称其为“组件”。它们是低级细粒度对象的更加紧密耦合的聚合体。因此，基于组件的业务软件开发 (CBD) [3] 可以进一步将业务和技术实体抽象到一个可以简化建模流程和开发的级别。
总之，为了取得不断发展，我们需要能够用易于理解的分类法将业务需求、必要的程序设计和代码合并为一个统一的表示形式，同时设计信息可广泛应用，易于扩展，且能够降低维护成本和极大地改进程序的可理解性。
通常，模式 [4] 是指那些解决某些重复出现的业务分析/设计问题的完全确定的且经过验证的解决方案。[4] 侧重于软件的“设计模式”（如对象结构、创建和行为），它们使架构师和开发人员能够成功重用现有的经验证的软件设计或解决方案组件，以便在不增加工作量的同时更加高效地创建质量更高的应用程序。[5] 引入了“分析模式”这一概念，这些模式是通用的面向业务的对象模型及其作为元类与定型的属性和操作的交互，它们代表在更多面向业务的建模中可能经常遇到的某些情形。一旦掌握了这些模式，软件专家就可以轻松地超越他人，因为他能够认识这些重复出现的业务和技术问题，知道是否有经验证的解决方案可用，以及如何有效地应用它们。
2.2.1 分层系统体系结构
一种最经常使用的体系结构模式是分层系统体系结构，其中系统被分为一系列半独立层，且每个阵列都向上层提供一项服务，并可利用由下层提供的其他服务。最著名的此类结构是 OSI 的 7 层网络模型 [6]。
正如前面所讨论的那样，业务类似性模式一般未被利用，在各种构件中复制这些类似点给重用、维护和适应更改的能力带来了诸多问题。如果我们能够将许多已知的业务领域和流程类似点转化为本质上可代表和利用这些类似点的业务组件或软件，就可以进一步减少交付解决方案时的复杂性。另一方面，由于这些类似点是隐含的且分散存在的，它们也增加了程序复杂性。对于软件简化来说，将类似点从负面影响转化为有效机制的关键是能够以通用和可适应的形式表示类似点的技术。我们还需要一种在发展业务流程和软件系统方面支持类似模式系统标识的方法，需要用一些通用、可适应的程序结构统一这些类似模式。[7] 扩展了业务领域中的分析模式并将“业务体系结构类型”设计为“原型”，以帮助我们处理重复发生和类似的业务问题。如果应用正确，经验证的原型 ([7]) 可以基于重用简化设计和编程。这将是我们的方法的基础。
原型是一种专门的分析模式类型，可以帮助我们处理类似问题，并使我们能够在不同的粒度创建统一的可用模式，从而有足够的能力进行扩展或自定义。原型背后的基本假定是许多或者大部分业务实体具有大量共同特征（或者是静态属性或者是动态行为）。因此，当我们将原型应用于新项目中的类似概念或新上下文时，能够利用新功能通过迭代增加或扩展原型从“部分了解”中获得“完整知识”。由于我们知道业务问题并构建了业务应用程序来解决它们，我们可以逐渐获得足够的知识，因此汇集的知识足够满足应用程序/部门/组织中甚至跨这些单位的许多类似需求。原型能够更改其行为以适应特定的业务上下文需求，同时其核心语义和分类方法仍保持不变。这适于在当前的 SOA 浪潮中提供必要的服务透明度，因为我们确实需要展示来自（业务）服务的几乎同样的特征，以促进实际的重用和方便地重用这些业务服务。此外，原型概念还可以很好地促进必要的业务敏捷性和业务合作伙伴之间的协作，这是因为基于原型的构件已经为业务通信提供核心语义，同时还能够轻松地适应更改 － 通过利用当今基于 XML 的元数据和模型驱动的开发技术，此类功能可以得到进一步扩展，这一点我们稍后将讨论。
在 UML 术语中，原型只不过是一个“定型”的类，它可以进一步将实际实体抽象为真正可重复利用并可轻松扩展的分析/设计和实施构件。根据 [7]，（业务）原型就是“一个在业务领域和业务软件系统中一致并普遍出现的原始事物”。这里提供了一个以“人员”为原型的示例，其中所有的属性均被建模为 <<o>>（“可选”），且计划为完整属性（或者尽可能完整），软件架构师最终所要做的大部分决定是为给定的业务问题选择某些可选的功能。为简单起见，此处没有显示与其相关的任何操作。
图 1. 原型示例 － 人员
如果我们按照 OOAD 方法，应用适当的分解、聚合、继承技术，我们可以将此“部分”扩展为一个更加抽象但却完整的原型，该原型可以将诸如带有许多共性和其他高度一致性原型及其关系的组织、人员之类的集合体建模到所谓的“原型模式”之中，如图 2 中所演示的“部分”那样：
图 2. 原型模式示例－“部分”
表示和指定这些统一应用实体仅是在应用原型中的一个中间步骤。在各种业务上下文中进行协作才是至关重要的。在业务环境和软件系统中，业务原型之间发生的一致性和统一性协作被称为“业务原型（协作）模式”。图 3 中描述了某些典型原型之间协作的一个简单示例。
图 3. 业务原型协作模式示例
为了提高其适应更改的能力，需要引入各种“可变性”机制，以便设计者能够选择（[7] 中称为“配置”）或者修改这些统一适应的原型和模式的结构和行为方面。现代化的体系结构和设计工具（如带有适当扩展插件的 IBM Rational Software Architect）允许捕获这些统一概念及其相关属性，以及针对特定业务领域/问题的扩展和可选用途。我们使用 <<o>>（可选），<<其他固定类型>> 表示所有可枚举的属性和行为，然后通过支持“模式配置规则”(PCL [[7]) 规范的简单语言解析可变性。此类 PCL 可方便地用 XML 表示并通过原型插件解释，以方便对现有功能的自定义（选择和扩展）。
软件包供应商已经创建了以广泛的行业为目标的特定业务领域应用程序（如针对 CRM、ERP 等的应用程序），并且通常提供有限的扩展技术来解决某些扩展变化。例如，Siebel 在体系结构中跨所有层提供了丰富的配置，从而 1) 能够通过向现有元素添加新属性、新元素和创建新关系来配置业务对象 (Business Object)；2) 并能够通过将更改应用于相关业务对象来配置业务组件 (Business Component)；3) 以类似的方式配置面向用户的屏幕。但是，由于其内部实现对大多数客户来说仍然是一无所知，因此为集成、自定义和维护这些系统带来了困难并令人感到失望。此外，很难评估引入的更改给这些 IT 组件或更改后的业务本身造成的影响。因此，难以在设计或服务/组件级别实现重用。我们建议的方法将有助于缓解这一问题。
随着 SOA 的出现，那些跨项目、业务领域和组织运行的可重复和可能可重用的业务任务已有望被设计和实施为（业务）服务，以便能够方便地公开、共享和重用、修改并使之适用于更改。利用 SOA，服务提供商和使用者所关心的问题将被正确地区分，从而可提供实现业务和 IT 敏捷性和灵活性所必需的必要封装、分离和模块化。此外，在必要时，此类服务还可以轻松地聚合为新的复合业务应用程序或服务。
通过将业务（和某些 IT）功能作为服务交付，SOA 使业务执行人员或流程所有者能够推动此类服务的定义、创建和实行。能够快速修改和实施这些服务将使组织能够更加高效地进行竞争。所以，SOA 是对传统业务应用程序开发范例的一次革命，它避开了单机式、刻板的应用程序体系结构，且省去了与经济合算和高效的业务流程驱动的体系结构相关的高昂维护成本。
为了实现最大利益，我们需要优化传统或现代的迭代和增量软件工程设计流程，以加快不断发展、面向业务的服务和基于资产的解析流程。目前流行的此类优化流程是 IBM 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）([9][8])，www.ibm.com 上提供了最新优化。SBS 方法将通过提供功能强大而灵活和可扩展的基础框架以及具体和可重用的模型构件对 SOMA 加以补充，并且已使用更方便的服务标识、实现和必要的转化功能对其进行了增强。
2.4.1 SOA 解决方案参考体系结构
为充分利用 SOA，建议企业建立或采用经过验证的体系结构标准和治理流程来设计和管理服务资产。此类参考体系结构之一就是 IBM 的 SOA Solution Stack Reference Model（S3 [9]，图 4），这是一个分为 9 层的模型，可提供跨所有层的 SOA 解决方案的详细体系结构定义。它将提供一个或多个组件或产品可以实现的基础体系结构构造块、可重用的功能元素，以及这些构造块和层、交互模式、选项和体系结构决策之间的关系。S3 不仅枚举 SOA 解决方案的基础元素，而且还以最适合特定组织的方法提供建模、构造、装配、部署和管理该解决方案的要素和灵活性 [9]。
图 4. SOA 解决方案参考体系结构
这 9 个层相对独立，其允许组织选择使用者和提供者集成的程度。例如，SOA 解决方案可以不包括业务流程层，让使用者层与服务层直接交互。较低层（服务、服务组件和操作系统）与提供者有关，而较上层（服务、业务流程和使用者）与使用者有关。
以下是对 9 个层的简要解释 [9]：
- 操作系统
此层包括在支持业务活动层的 IT 操作环境中运行的所有应用程序资产，不管它们是自定义构建的，还是成品。 - 服务组件
此层包括软件组件，每一个组件都是服务的实现或对服务的操作。服务组件同时反映了它们所代表的每项服务的功能和服务质量 (QoS)。 - 服务
服务层由 SOA 中定义的所有服务构成，其中，服务仅仅是对一个或多个与业务一致的 IT 功能（操作）的抽象规范。此类规范将为使用者提供足够详细的信息来调用由服务提供者公开的业务功能。 - 业务流程
组织可以将服务层中公开的服务装配成复合服务，以模拟重要业务流程。在非 SOA 环境中，这些业务流程类似于自定义应用程序。填写和提交贷款申请流程就是这样一个示例，组织一般通过一个自定义的应用程序执行此过程。但 SOA 与之相反，它通过创建可编排由一组服务和人员参与者构成的信息流的复合服务来支持该流程。 - 使用者
使用者层处理与用户或 SOA 生态系统中的其他程序的交互。通过它，组织可以根据特定的用户参数向应用程序或用户提供现有的 IT 功能和数据。因此，组织可以快速创建前端业务流程和复合应用程序来响应市场变化，支持对在给定的 SOA 中公开的业务流程和服务的独立于渠道的访问。进而允许选择丰富的客户端用户界面，这些界面可以使用允许从使用者层调用 Web 服务的技术。此类界面提供一个框架，内容提供商可以用来为门户编写一致、可以互操作的 Web 服务。 - 集成
此层主要集成了 2 到 4 层，因而对 SOA 来说至关重要。其集成功能让组织能够通过中介传送、路由和传输从服务请求者到正确的服务提供者的服务请求。此类功能包括但不限于企业服务总线 (ESB) 中的那些功能。 - QoS
QoS 层可让 SOA 对每个 SOA 层中的服务质量不一致性发出信号。这样，它就可以捕获（在操作层面）、监控、记录与这些服务质量相关的非功能性需求不一致的信息，并发出信号。在某些情况下（如安全性），QoS 层可以实际实现此类非功能性需求。 - 信息体系结构
此层可确保组织包含影响数据和信息体系结构的关键注意事项，组织还可以通过数据集市和仓库利用它们创建业务智能。该层包括存储的元数据内容。 - 治理和策略
治理和策略层覆盖了管理业务操作生命周期的所有方面。此层包括从手动治理到 WS-Policy（服务层与治理和策略层在此相交）的所有策略。它提供了管理服务级别协议（包括容量、性能、安全性和监控）的指南和策略。
2.4.2 SOA 价值主张
正如图 5 中所描述的那样，SOA 最大的潜能来自于以下两个主要方面：首先是在过去几年的 SOA 实践中重点强调的“业务服务”，这些实践可以真正帮助弥补 IT 和业务界之间的差距，从比较孤立、紧密耦合的软件系统体系结构发展到多层、松散耦合的体系结构支持重用现有资产，并跨现有的操作和业务边界无缝集成业务操作。
图 5. 提高了从单机到 SOA 的业务价值主张
2.5 模型驱动的体系结构和利用基于 XML 的元数据开发 (MDA/D) [12]
MDA/D 进一步提高了抽象和重用的级别。通过对从独立于以业务为中心的平台/技术 (PIM) 模型到特定于平台和最终依赖于环境/实现技术的模型 (PSM) 进行一系列的更新，MDA 提供了建模实际业务问题的最佳实践，同时还便利了向可部署代码资产的必要映射和转换。这样，MDA 至少可在传统的分析级别真正为解决方案模型提供设计时间的互操作性。
MDA 的重点是在不同的抽象级别创建不同的模型，然后将它们连接起来实现这一概念。其中有些模型将独立于软件平台而存在，而有些特定于具体的平台。每个模型都将用文本和多个互为补充且关联的建模构件组成的组合来表示。
目前，UML 是首选的建模语言。但是，还有需要使用 MDA 框架来定义特定领域的语言 (DSL)。虽然仍是非正式的，但原型和支持交互模式与模式配置语言可以看作是某种 DSL。
另外一个重要开发是敏捷性实践 [13] 与 MDA 的合并。敏捷性 MDA [14] 可解决 MDA 与敏捷方法之间的潜在冲突，它主张通过尽快提供少量运行代码解决与“验证差距”相关的问题（当业务所有者或 SME 编写的需求文档无法验证为可实行或可执行时）。此运行功能对于可以与之交互的客户来说非常有用；这会提高对需要构建的客户系统部分的了解。由于这些交付周期可能很短（即一周或两周），所以系统的开发流程能够适应不断变化的情形并仅提供客户想要的内容。
通过提供业务对象/组件和服务的 xml 数据驱动的可配置性，我们的方法完全利用并扩展了原型概念和面向服务的 MDA/D 方法。图 6 显示了 SBS 方法的高级视图。我们将在此部分中解释其主要组件以及如何建立和应用它们。
图 6. SBS 方法概述
正如前面所讨论的那样，原型背后的基本假定之一是许多或者全部实际概念及其关系都相似，因此可以对它们充分了解和建模，并有选择地将其用于任何特定的业务上下文中。利用发展的方法，我们可以从小处着手，以实际实体的子集为起点，逐渐增长我们的体系。因此，需要各种现有原型的库（存储库）及其模式。
3.1.1 4 层通用业务组件和服务模型
对复杂业务情况进行适当分解（尤其是实现普遍适用的业务模型和体系结构的目标）对实现建议的方法至关重要。正如第 2 部分所讨论的，基于对象/组件的技术和元数据结构驱动的体系结构类型（原型）使我们能够使用原型中统一的可扩展表示形式对业务实体进行建模。为了处理从特定行业模型中抽象这些普通元素造成的结果，并且能够方便地支持基于元数据的转化，我们基于类似/通用的模型及其各自的内在关系初步建议将业务组件分为以下四个层：
- 通用层
- 特定的业务领域
- 特定的行业
- 特定的客户端/项目
图 7. 4 层原型模型
请注意，我们在各层之间使用了虚线，来表示所有可能的继承关系的连接。使用此分解方式，我们能够跨业务领域、行业、特定于客户端的需求、上下文或环境提取共性和差异。
3.1.2 层定义和说明
3.1.2.1 基本通用业务组件和服务
此层包含以抽象形式表示最普遍适用的业务概念的通用基本原型（包括可以公开为服务的属性及其操作/服务）。它非常具有普遍性，没有任何业务领域或行业特定的限制。因此，它们可以广泛地重用。
例如，在许多业务应用程序中，我们经常遇到或必须处理产品、订单、参与方、组织、帐户之类的概念。
3.1.2.2 业务（子业务）领域特定的组件和服务
业务领域表示一组特定的、通常相互紧密联系的业务实体，该业务实体相互协作，完成某一业务功能。例如，金融和保险业通常需要处理产品管理、财务管理、帐户管理、客户关系管理之类的业务领域。
您会很容易地看到其中的许多业务领域实际上也适用于许多其他行业。例如，客户关系管理在每个行业中几乎是通用的。
3.1.2.3 特定于行业的业务组件和服务
为创建可重用的特定于行业的解决方案，我们还必须确定各种业务问题及其可能的解决方案构件的共性，然后对基础和业务领域层进行适当扩展，以满足特定行业的独特需求。
在第 3.1.3 部分中，我们将进一步说明如何在行业层和业务领域层之间进行正确地建模。
3.1.2.4 特定于客户端/项目的业务组件和服务
我们的构想是能够使用前三个层中广泛重用的、基于原型的构造块构建业务解决方案。在理想情况下，可以通过这些层中的构件来配置特定于客户端或项目的任何组件和服务。当然，由于通过这些普通业务实体难以获得全面的知识，所以任何特定的业务解决方案的实现还通常需要某些扩展。但是，随着我们解决更多的问题，并基于建议的方法构建自已的解决方案，我们会增加和提升解决方案资产，获得更大的覆盖范围。
3.1.3 设计和体系结构注意事项
3.1.3.1 行业和领域的比较
我们在初始模型中遇到的较早设计决策之一是将行业层和业务领域层交换一下位置是否会更好。按照严格的分层机制，阻断这两个层的双向交互会非常困难。因此，我们实际上将对这两个层采用扩展分层机制，不需要区别哪个层实际上构建在另一层之上。
我们初步的考虑是特定于行业的流程和模型趋向于更有组织地关联，某一特定行业中的业务子领域可以更容易地抽象和专门化，这样可促进更好地重用。
3.1.3.2 完全扩展的模型
为了应对所有潜在的问题和提供更加坚实的基础，我们建议对 L2 和 L3 提供双向映射和可跟踪性，从而使 SBS 模型框架成为扩展的分层体系结构，其中：
- L2 和 L3 都可以使用 L1 提供的服务，并为 L4 提供服务；
- L2 和 L3 可以相互提供或使用服务；
- 允许不同的 L2/L3 组件相互提供或使用服务。
图 8. 完全扩展的 4 层原型模型
使用扩展模型，我们可以显著提高在这两个核心层中建模构件的灵活性和可跟踪性，使之更容易与业务用户通信，也更容易将现有业务领域特定的资产调整为可重用的资产。
3.1.3.3 与 S3 参考模型保持一致
将 4 层业务模型与 S3 参考体系结构进行比较，我们可以很容易地看到，基于业务组件和服务模型的 4 层原型覆盖了 S3 中的业务服务和服务组件层，并且有限地覆盖和连接到业务流程和集成。
正如图 9 中描述的，为加快 SBS 模型扩展流程，并使之更像一种工程设计实践，我们创建了模板集。在此方式中，所有层的新模型构件可以使用对应的模板来扩展该层的模型。使用 XML 元数据可促进差异分析到新扩展模型的转换。从本质上说，可以扩展传统的 MDA，拆分其中的模型，然后具体化为特定的 PIM，最后使用 SBS Enabler 转换这些模型并生成高百分比的代码（将在第 5 部分中解释）。
图 9. SBS 模型扩展框架
现在，我们已经对 SBS 模型及其方法有了一些基本了解，接下来我们将讨论如何使用它。
3.3.1 创建基础 SBS 模型（步骤 1）
在理想的情况中，原型模式库包含我们对业务问题建模所需的“全部”信息，并为给定的业务环境提供可自定义的实例化框架。因此，软件架构师/工程师通常需要做的就是选择/重用和扩展基础原型和模式。
但是，实际上我们必须在所有层从头创建基础模型。根据对最初关注领域的一些业务和技术决策，我们分析了若干行业（包括政府、银行、保险、零售业等）的许多现有资产（大部分来自于一些知名的/公开的以前项目），从中抽象了参与方、客户和产品之类的基本概念，并切实扩充了 [7] 的基础模型。还使用所需的连接表示了业务领域和行业层的差异。
而且，我们不仅建立了业务级别的组件模型，而且还建立了这些组件在基础模型中提供或使用的典型或标准业务服务。另外，我们还分析和连接了一些潜在的服务提供者（现有应用程序、诸如 IFW 的行业解决方案框架或第 3 方软件包）。
3.3.2 从现有基础模型选择正确的原型和模式并生成差异
-
我们已创建了 SBS Analyzer（当前仅为一些 Excel 电子表格和仍需要收集的预定义信息），可以促进对业务需求的分析、所需业务功能与现有 SBS 模型可提供的功能的匹配/映射，以及潜在服务提供者能够支持的功能。通过此工具，我们可以确定候选业务组件和服务，更重要的是确定需要弥补的不足，并最终确定一些实现选项（步骤 2-3）。
当前，Analyzer 由以下 3 个 Excel 电子表格组成：
- 所需的业务功能（特征）：我们在这里可能利用的最好信息来自业务流程分解和支持描述（最佳场景，但许多项目实际上没有这么丰富）、用例文档中使用的功能声明和关键字（对于大多数项目）。我们然后将确定的所需业务功能（特征）列在 Analyzer 中。
- 包括以下关键信息的 SBS 资产/库存映射：业务组件、业务服务和操作、输入和输出消息、来自可能的提供者的候选服务（现有资产和行业模型、第 3 方软件包等），以及现有输入和输出消息的表单。
- SBS 特征映射，其中包括业务必要性（基于给定的业务问题和业务/IT 环境）、就绪情况评估（包括模型和组件/服务）和基于跨行业和业务领域的潜在重用将这些资产转换为符合 SBS 的服务的需求。
这将能够方便地创建集成所有这些电子表格及其包含的信息的独立插件，并建立关系和一些导航/搜索功能，进一步帮助实现问题到模型的匹配和选择。
-
然后，使用这些信息，我们可以将每个所需业务功能映射到一些业务组件和候选服务。通常，我们将在所有层中选择某些模型组件（步骤 4）。这里可以应用将职责分配给对象的最佳做法（例如在 [15] 中讨论的 GRASP 模式）。请注意，原型模型可以包含给定业务问题可能不需要的许多可选功能（可定型为 <<o>>，它们可以是所有层的对象、关系、属性和操作）。
-
在上述步骤中，我们可能发现某些业务需求无法映射到现有业务组件或服务，有些业务需求可能需要对现有业务组件或服务进行显著增强。因此，我们将创建另一个电子表格来总结所有的不足和必要的更改。然后，我们将确定的不足和更改转换为基于 XML 的正式差异作为模式配置规则 (PCR)（步骤 5-6）。
3.3.3 配置所选的模型（步骤 7）
选择之后，所选基础模型构件将被实例化为配置的模型。此外，将建立的特定模式配置规则 (PCR) 应用到实例化的模型，以满足现有问题的特定需求。在初始 SBS 模型库中选择的所有可选属性 (<<o>>) 将变成 <<o-y>>，这意味着它们是必需属性并为给定的业务问题进行了此选择，所有其他 <<o>> 功能将被排除。
还进行了一些模型正确性验证，以确保所有模型构件具有良好的形式 [7]。
3.3.4 扩展配置的模型（步骤 8-9）
在 SBS 模型的当前版本中（甚至在经过充分争论和扩展后的可预见未来中），普遍适用的模型永远不会满足每个客户项目的需求。因此，通过差距分析，我们建议使用行为和属性扩展。
- 行为扩展：可以执行以下两个主要的行为扩展类型。
- 添加新的业务事务。例如，使用关联的 addReminder、getReminder 和 updateReminder 事务可以添加新的提醒业务对象。
- 自定义新的操作/功能，或者将其添加到现有事务中。例如，在特定事务的 postExecute 上发送通知。
- 属性扩展：例如，贷款应用程序需要对现有的常规客户对象添加风险评分属性。
在此阶段，可以通过业务和 IT 团队的联合评审，做出有关配置/扩展的 SBS 模型是否满足业务需求的建议和决策。请注意，当前已用更特别的方式将这些扩展合并到了配置的模型中，并且需要若干的评审和调整。
在所有这些转换之后，SBS 模型实际上会是什么样子？从本质上说，SBS 方法会有效地利用和扩展原型的概念，提供可配置的业务组件和服务。正如图 10 中所描述的，SBS 模型包含一组组件/对象/服务模型，其中添加了可以由 xml 元数据管理并受一些工具扩展支持的变量逻辑（用基于 xml 的模式配置规则 (Patter Configuration Rule) 表示）。
图 10. 基础模型 + 变量 = 配置的和扩展的 SBS 模型
业务组件 PartyManagement 的示例模型表示为纯对象模型，如下所示：
图 11. 可配置的和可扩展的 SBS 模型示例
正如您看到的，我们已创建了用于定义、表示和处理这些变量的若干新的原型。
完成这些步骤之后，将创建特定于所分配业务问题的第 4 层模型。
3.3.5 按照常规 MDA 方法扩展可部署的组件和服务
- （步骤 10）在创建第 4 层特定于问题的模型之后，接下来我们可以按照常规的 MDA 方法将其进一步扩展为独立于平台的模型。在此步骤中，我们主要尝试应用分析和设计模式，使模型形式更加良好，从而增加重用潜力。
- （步骤 11 – 12）这里我们将与客户业务团队和 IT 团队进行一次评审会谈，以了解他们在现有应用程序或基础结构功能中的偏好和约束，并将 PIM 转换成特定于平台和技术的模型，最终转换成可部署组件和服务并自动生成高百分比的代码。
为了支持这种基于 SOA 的模型和业务驱动的开发，还需要使用现有工具，尤其需要许多必需的转换和集成功能（Eclipse 或 RSA）对现有工具进行扩展。
如图 11 中所描述的那样，我们设计和实现了一个 SBS Enabler（RSA/Eclipse 插件），它能够接受自定义的 SBS 实例模型和生成相应的代码模块，如 .java、.wsdl、xsd 文件和其他配置文件。
- SBS Enabler 可接受从内置的基础 SBS 模型和技术配置规范自定义的第 4 层 SBS 实例模型（如前一部分中描述）；
- SBS Enabler 然后按照图中的描述为不同的层生成可运行的代码模块（与 S3 模型对应）。
事实上，我们已使用 Enabler 为 3 个初期实际项目（使用 SBS 作为实验）生成了约 100,000 行的优质代码（[7] 称为“专家级”代码）。它们全部通过了行业开发团队的测试，并已成功集成到各自的内部版本和发行版（将在第 5 部分中介绍）。
图 12. SBS Enabler – 从 SBS 模型和配置到可部署的代码
|
|
按照 SBS 方法创建新的可重用资产仅需要对常规迭代和增量开发流程进行很少的更改。正如图 13 中描述的那样，将多个新任务与资产发现关联 (1)，确定差距/差异 (2)，并配置/扩展基础 SBS 模块 (3-4)，如果新开发的模型元素具有与现有适用性类似的“通用适用性”，则将其收集到 SBS 库 (N+1)。最后，我们需要提升和训练新功能以增加重用机会。
图 13. 使用 SBS 方法增强迭代流程
建议方法的关键驱动因素之一是解决 IBM Global Services 面临的关键问题，即我们如何将许多经过验证的现有行业应用程序或资产转换为可重用的形式，以便类似的项目可以有效地重用它们。遗憾的是，大多数现有应用程序或资产很早就与客户的早期需求密切相关，与一些特定的业务领域紧密耦合，并且最初选择的开发平台（操作系统、编辑语言和 DBMS）以及操作环境在很大程度上约束了解决方案或资产本身。其中有些应用程序或资产已分解为组件，但有许多仅由细粒度对象的扁平集合组成，更糟糕的是，它们只是一堆意大利面条式的程序结构。要使它们变得可重用，我们需要应用 OOAD 原则，遵循 4 层的 SBS 模型，并且真正地将业务领域的关注内容、行业和特定客户端的注意事项隔离为可管理和可转换的表示形式。SBS 不仅提供经过验证的分层结构和模板，使转换、分析和设计工具支持变得切实可行，而且还可以充当业务分析人员和 IT 专业人员易于遵循的最佳实践。
使用建议的方法，我们可以利用多种格式的现有资产：UML 模型、逻辑或物理数据模型（ddl 格式）、XSD 模式和代码模块。此类资产可以是行业验证的解决方案框架（如 IBM 的 IFW、IAA 和 WCC）或从客户端合作中收集的交付内容（例如许多国家/地区的社会服务项目、核心银行或保险项目）。为便于重用，将这些资产转换为符合通用原型模型库的表示形式非常必要。在进行转换时，我们将力争符合（有时需要最小限度的扩展）主流行业参考模型和标准（如 ACCORD、Xretail 等）。使我们的高价值、大型行业模型和框架符合 SBS 可以克服复杂性和技术问题，并且还能够与业务执行人员、架构师和开发人员进行更有效的沟通。
另外，要使它们符合 SBS，还需要执行以下三个主要任务：
- 在所有层使用可用的模板将现有的解决方案/资产模型调整为符合 4 层 SBS 的模型，同时尽可能使用现有的 SBS 模型元素。
- 基于最初的解决方案功能配置所选的 SBS 模型元素，以及如何更好地利用现有 SBS 模型重构解决方案。对于此任务，可以使用相同的 SBS Analyzer。
- 使用行为或属性扩展转换的模型（如第 3.3.4 部分中所述）。
在某些情况下，可以从与解决方案/资产功能和程序结构紧密匹配的现有 SBS 模型库确定一致的业务组件和服务。在这种情况下，我们只需通过添加或增强关系、添加新属性或添加/增强服务操作来扩展 SBS 模型。尽管有时候需要在 SBS 模型中创建一些新的业务组件，但是我们应更好地利用现有解决方案/资产模型。当然，在这种情况下会涉及更多的工作，但是这样做的一个好处是，SBS 模型本身会得到显著增强，从而可以涵盖更多的业务领域或行业。
|
|
除了前期进行一些有限的调查和建模工作外，一个 9 人团队仅用 6 个月便将当前的 SBS 方法置入“生产”模式。由于我们的 Global Business Solution Center (GBSC) 向各地区小组分配了单独的行业部门，所以 SBS 方法最初侧重于客户信息和关系管理以及案例管理。
5.1 实验 1 - 了解您的客户（Know Your Customer，KYC），银行客户信息系统
KYC 的用途是提供通用的业务服务，在符合银行业的 KYC 规则的情况下，加快客户开立帐户和维护流程的速度。完全了解 KYC 要求之后，SBS 团队培训并领导行业团队配置 SBS Party 和 Case 域模型。然后，为了使 SBS 生成的所有构件满足需求，SBS 团队开发并修改了一些服务模板以满足 KYC 特定的服务需求。SBS 生成预期的构件后不久，行业团队很快启动了进一步的开发。
SBS 团队帮助行业团队生成了实现代码，其中包括持久层中的 Entity、DAO 和 DDL，以及服务层中的 WSDL、XSD 和 Java 实现。行业团队将所有构件用作 FO-KYC 项目的基础结构。
结果，KYC 案例管理的 60% 的服务操作重用了 SBS 案例管理构件，其他 40% 的新增功能增强了大多数层的 SBS 案例管理模型。KYC 客户管理的 50% 的服务操作重用了 SBS 客户管理，其他 50% 还帮助增强了 SBS 案例管理。
正如表 1 中所指示的，SBS 生成了大约 50,000 行代码 (LOC)，这相当于 FO-KYC 中代码总行数的 68%。
表 1. SBS 在 FO-KYC 中生成的构件
| 生成的构件 | 数量 |
|---|---|
| 用于数据访问服务的 Java 类 | 162 |
| 数据访问服务的 LOC | 43161 |
| 用于业务服务的 Java 类 | 20 |
| 业务服务的 LOC | 4865 |
FO-KYC 的 LOC 总数量为 69874，而生成代码的 LOC 数量为 48026。因此重用的百分比为 48026/69874 = 68.7%。在本文中，我们不打算评估财务效益，尽管有非常明显的重大节省。应用 SBS 方法的另一个好处是缩短了实现和维护业务组件的周期，并且所需的技能级别也明显降低。
下表列出了为两个服务生成的构件示例：
表 2. SBS Enabler 生成的代码构件示例
| 类型 | 文件名称 |
|---|---|
| xsd | OnboardingCase.xsd Organization.xsd |
| wsdl | OnboardingCaseMgmt.wsdl OrganizationMgmt.wsdl |
| SCA 组件描述符 | OnboardingCaseMgmt.component OrganizationMgmt.component |
| SCA 服务实现 | OnboardingCaseMgmtImpl.java OrganizationMgmtImpl.java |
| DAO 类 | OnboardingCaseDAO.java OrganizationDAO.java |
| POJO 类 | OnboardingCasePK.java OnboardingCase.java OrganizationPK.java Organization.java |
此应用程序更侧重于案例管理。因此，60% 的服务操作重用了 SBS 案例管理构件，约 30% 的新增功能回馈到 SBS。SBS 为此项目生成了 35,000 行代码，大约节省了 42% 的工作。
表 3. SBS 在 Customer Insight 中生成的构件
| 生成的构件 | 数量 |
|---|---|
| 用于数据访问服务 Java 类 | 82 |
| 数据访问服务的 LOC | 32026 |
| 用于业务服务的 Java 类 | 10 |
| 业务服务的 LOC | 2934 |
|
|
从设计和开发 SBS 方法，并将其快速应用到某些实际的客户合作项目，我们进一步验证了以下内容：
- 建议的 SBS 方法成功集成了一些顶级技术，其中包括 SOA、基于元数据的 MDA/D，而且更重要的是普遍适用的原型已证实可行，且易于配置和扩展。
- 4 层通用业务组件和服务模型可有效地应用和扩展具有可配置和可转换扩展的原型概念，可以将这些原型概念打包为 RSA 的一些插件，其中这些配置和扩展能够以系统方式从 SBS Analyser 派生。
- 此类分层的通用业务组件和服务模型可以很好地充当未来的“业务体系结构”表示形式，特别是我们能够进一步增强，将业务流程连接到这些具有可跟踪性的模型构件。
- SBS Enabler 完成了端到端的 MDA/D 生命周期，由于它可以提供重要功能，将 SBS PIM 转换为 PSM（基于 JAVA/J2EE），并最终转换为可部署的高质量组件。SBS 方法的实际应用程序明显地体现了工作量、时间和成本方面的节省。
使用 SBS 方法，我们可以更容易地创建在这些业务组件之间具有高内聚性的松散耦合组件，经过分析验证的应用程序和设计模式可以使此类模型成为更一致的高质量模型，最终帮助生成高质量的代码，并且所需的高级技能更少。从这方面讲，我们认为 SBS 方法使当前的软件实践向前推进了一大步，使之变得不仅更灵活，而且更接近于实际的“工程设计”范例。
下面是早期审核人员和采用者发现的一些问题：
- SBS 库当前仍主要侧重于客户和案例管理，需要大量的工作才能将其扩展到更多的业务领域（如产品、零售等）。
- 整体方法需要更好地与业务所有者/分析人员通信。尤其是，SBS Analyzer 应集成到 RSA，而不是作为一组独立的电子表格和 SBS Enabler 的内部构件。
- 标识通用服务仍严重依赖于领域知识和建模技能。幸运的是，SBS 方法实际上可能已经缓解了此类常见问题，由于专业人员能够从一组集成且可跟踪的模型进行实验，来验证其关注的业务组件和服务。
- 将 SBS 与当前的 SOMA 建模环境 (SOMA-ME) 插件集成在一起可能会更好。
- 业务流程和 SBS 服务映射/转换。
- 与现有数据库模式和数据/管理定义集成，并利用主流行业标准。
- 业务需求确认/验证
- 应用 SBS 方法转换高价值而又复杂的行业框架和资产（如 IFW/IAA）。
- 未来的工具增强将超过推荐/实现的工具增强，它们可用于指导未来若干品牌的工具一致性和集成工作。
第 II 部分将讨论用于模型驱动的映射和转换的 SBS 工具。将讨论若干转换技术，以便跟踪基础构件、业务领域和行业特定的构件的发展，更重要的是，跟踪将模型从可能普遍适用的形式移动到平台独立性的形式，然后移动到依赖于平台和技术的表示形式所必需的可配置性和转换，其中包括自动代码生成。可以将其中某些实现的工具功能用作公共建模/解决方案体系结构工具的插件。
扫一扫
3193
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
