服务取向的面向业务的基础

服务取向的面向业务的基础

适用于：
企业架构
面向服务的架构 (SOA)

摘要： 通过将服务取向与 Web 服务结合使用，有效且高效率地实现业务活动的自动化。

“能够幸存下来的物种，不是最强的，也不是最聪明的，而是最能适应变化的。”
查尔斯·达尔文

简介

随着 Web 服务的出现，服务取向成为针对自动化业务活动而提出的最新技术解决方案。服务取向所体现的概念源自模块化和分配复杂计算机系统（该系统能反映并支持真实的分布式业务环境）的长期努力。

根据服务取向的当前定义，服务通过标准、已发布和可检测的接口提供可访问网络的功能。这些核心特性至少可以保证协议（句法）互操作性，而无需考虑平台、提供商和位置。

但是目前，解决技术集成问题本身不足以使在服务取向方面的投资物有所值。为使论点更加可信，大量有关针对业务灵活性的服务取向的说法涌现出来，它们辩解道，在面向服务的环境中，通过构成、重新配置和重新使用解决方案等方式，可以更加便捷地建立解决方案。根据上面对服务取向的定义，许多业务可能已在某种程度上实现了服务取向，但仍然要费力地提供业务所需的 IT 支持。

因此，要使在服务取向方面的投资物有所值，我们需要讨论以下在每个运用新架构原理的项目中出现问题：

•	我们如何避免服务取向重复类似的充满希望的开端，但产生与过去相同的架构错误？
•	我们如何确保所选择的实现架构与业务要求相关？
•	我们如何在不断变化的环境中最大化服务取向实现的生命周期？

正如我们将要理解的，这些问题的答案是相互关联的。服务取向仅仅涵盖了系统的一个特定方面，它不是系统的起点，因此有缺陷的基础将导致有缺陷的实现。这种基础正是实施难题中缺少的一个重要部分：一种以正式化、可重复和创新性的方式得出上述业务要求并将这些要求与面向服务的结构相关联的方式。

用于对业务要求进行描述或建立模型的方法与其最终的技术实现之间，通常没有准确定义的关系。今天，大多数捕获和表现业务要求的努力都使用业务过程建模技巧和技术。虽然在尝试将业务要求和策略与 IT 策略和实现相关联的过程中，业务过程的正式建模是不可或缺的一部分，但这远远不够。

业务过程需要专注于实现业务目标所需的活动，而不受传统“砖块加灰浆”界限的束缚 - 今天在内部完成的事务明天可能外包出去。我们的设计必须考虑到界限、网络的影响、不断变化的责任等因素，通过灵活的业务模型来支持这些协作要求，同时还要确保顺利地跨越这些界限，而不受系统、公司或其他界限的阻碍。传统的业务过程建模无法使业务要求与技术结构和投资匹配。没有界限、部署问题、封装等概念。

换言之，一个更好的模型除了能够表示活动以外，还必须同时支持业务的相互依赖性和支持业务的服务的自主性。

进入业务功能计划

为了达到以上目的，我们建议将业务想象为一个功能的网络。一种功能模型化业务功能的工作和所需的业绩水平，工作是指它的外部可见行为，而工作方式是指它的内部行为。“支付雇员工资”和“装运产品”都是功能的示例。这些功能都有普通意义上的“所有者”和“客户”，并需要按特定的级别（例如一段时间内的单位数或某些质量测定标准）执行。这是所完成的“工作”和所需或约定的完成级别。功能内部包含了如何在给定时间点根据人员、程序化步骤、技术等因素实现功能的细节。在目前的抽象级别，我们专注于外部方面，如何实现功能并不重要。这个功能实质上是一个“黑盒子”。

功能的描述十分具体，解释一个功能如何适应业务以及与功能进行交互所需的事物，但是要为提供一个牢固、更长久的基础提供所需的稳定性，应进行充分的概括。网络方面描述了功能如何互连来执行业务所需的工作。

现在，由于注重外部、可见且可测量的行为，以及行为与其他功能的联系，我们可以立即发现功能和服务取向之间的相似之处。以最抽象的方式来说，业务功能和 Web 服务都是黑盒子，它们的联系很重要，即与内部工作相关，又与内部工作分离。直观地说，这一相似性预示可将二者完美地结合。

移动界限

在我们了解业务功能的更多详细信息之前，透彻理解通过 IT 满足业务要求方面的问题非常重要。IT 既是架构改进和重复出现的项目的原因，也是它们的结果。毕竟，在支持我们采纳新技术的努力之前，业务部门希望有一个明确的投资回报 (ROI) 和价值策略。

大多数业务部门的 IT 基础结构是一个复杂、互联的系统，这一系统随时间有机地增长，以满足各种不断变化的需要。如果保证投入足够的资金，每项新技术都可以推动架构改进。利用新技术，可以将现有的系统重新设计为由组件构成、有组织、灵活的整体，从而使业务需求、系统和数据流相匹配。但是，即使可以完成完整的架构重设计，共享所有数据并消除重复的应用程序，其基础结构也将随时间逐渐退化到类似于原始结构的组织结构。这种情况为什么会发生？又是如何发生的？其中涉及哪些问题？

关联业务

受全球化和竞争力的推动，传统的线性供应链已经发展成为一个由参与共同业务的合作伙伴组成的复杂价值网络。图 1 和图 2 说明了从线性价值链发展为复杂价值链网络的过程。这些网络正在不断扩张，以包含由不断增加的合作伙伴提供的更多服务：客户、政府、金融服务组织等。对系统或应用程序的投资需要考虑由这一不断加强的互联性所带来的要求或机遇。

价值链演变 - 作为关联合作伙伴网络的业务

图 1. “当时”—传统的供应链

图 2. “现在”—合作的网络

在思考公司、客户、政府以及他们为达到业务目标所采取的合作方式的演变时，可以使用三个相辅相成的主要模型实现业务目标：

•	传统的价值链合作伙伴注重的是获取生产资料、将生产资料转化为半成品或成品、以及将成品分发给客户。
•	“业务过程外包商 (BPO)”通过在生产资料转化或产品分发之外的方面为业务要求提供服务，增大了价值链。人力资源服务（例如工资支付）的外包商已经存在很长一段时间，但是，所提供的服务日益复杂，并专注于对业务很关键的活动上。例如，更先进的通讯技术已经打开了低成本的海外劳动力市场，可以提供软件开发和帮助电话等服务。
•	此外，自助服务已日益成为协作的重要组成部分。自助服务范围广泛，从要求与供应商更加灵活地互动的客户或合作伙伴，到为客户和合作伙伴提供以多种方式互动的激励的供应商。甚至政府也正在通过提供或要求特定的在线活动（例如填写表格或财务报告），推动自助服务的发展。

换言之，现代业务在许多方面都跨越了传统的公司界限，唯一的解释是，我们的模型建立和解决方案造成了这种情况。当公司进行规划时，公司界限越来越类似于财政年度。这两个都是重要且相关的界限，但业务部门必须超越这些界限进行计划和预算。

系统发展 - 业务功能的关联环境

如果检查任意给定公司的系统，并观察他们的工作，您基本上会发现系统或应用程序支持特定的功能或用户社区。财务社区的财务系统、市场和销售的客户关系管理 (CRM) 和支持社区等。如果它们已经相互联系，则这种联系不是很完善。结果是，客户不得不使用孤立的功能。最令其不悦的的事实是，这种情况完全可能保持不变，始终持续，因为新的业务方式出现的速度比集成的速度快。

因为我们永远无法“赶上”，更不可能超过变化，因此，随着创新继续以多种方式推动业务和客户的发展，应用程序将来需要采取一种完全不同的方式。我们应该接受一个事实，即无论在最终架构方面做出多大努力，现实和经验仍然否认这种可能性，而不是进行一次有纪念意义的实践，将业务功能合并到现有解决方案中。通常不稳定的业务行为（受快速变化的技术影响）的性质决定了，所有架构在某种程度上都是流动的。但是，了解这些后，我们可以审视一下我们的架构，并尽可能建立能够长期适应这些变化的架构，将架构投资转化成为持久的资产。

我们可以做些什么？

这些关于延长架构重设计生命的观察很好，但敏锐的读者会注意到，他们实际上依赖于获得我们第二个问题的正确答案：实施架构与实际业务有什么关系？我们正确回答这一问题的程度决定了我们成功实现这些构想的程度。

现有业务改进技巧注重过程改进，在满足当今的业务挑战方面取得了长足的进步。但是，首先注重“如何”进行工作是建立在执行“什么”工作这一假设之上的。这样，解决方案就被限制于改进机制方面，而不是挑战工作的基本前提。这是大多数人今天在尝试解决业务问题时使用的惯例。要改进这一点，我们需要挑战这些假设，并提出不同的问题。

业务功能 - 更稳定的基础

那么，我们发现真正的问题是“当您为客户设计解决方案时，这个架构中的哪些部分真正耐用，使您可以应对变化？”因为答案很显然提供了针对架构报废的最佳 ROI 和最佳保护性措施。

我们发现，稳定的因素更多的是关于业务实际上的工作，例如创建采购单、制作发票、运送产品等。这些业务活动（我们称之为业务功能）是相对稳定的，但业务如何通过人员、过程和技术来实现它们，以及这些活动如何结合到过程中，都是非常不稳定的。那么现在，我们需要了解业务的工作和它的功能。

继续之前，让我们引入几个新定义用于讨论：

•	“业务功能”是业务为达到特定目的或产出，可能拥有或交换的特定能力。功能描述了业务为客户创造价值的工作（产出和服务级别）；例如，向雇员支付工资或运送产品。业务功能将人员、过程、技术和信息提炼和压缩到促进业绩改进和重设计分析的核心基础中。 图 3. 功能为“黑盒子”，其输入和输出使用明确的服务级别预期来定义
•	“功能联系者”表示存在于业务功能之间的链接。连接不仅是简单的消息，它们还包含丰富的语义信息。功能模型中有多种联系者，专注于信息交换（输入/输出、支持信息）和政策的控制或确立（规章的影响）。
•	“业务过程”描述了业务如何执行或实现给定功能，或功能如何连接以提供所需的产出。Hammer 和 Champy 是因在 90 年代创建业务过程运动而享誉的作者，谨慎地将业务过程定义为抬高到过程之上的端对端工作。过程比组织部门和功能更加重要。
•	“业务功能计划”是推动典型公司活动的功能及其联系的定义和清晰的结构轮廓。业务功能是业务架构的基石，因此，将功能想象为架构蓝图是一个很好的类比，尽管过程是架构在任何给定时间的实现。建立了这种更客观和稳定的业务观点后，公司就可以更透彻地理解功能之间的依赖性，并由此更透彻地理解业务：在业务流程内，跨越业务单元，跨越一段时间。

功能 - 最理想的问题解决层面

我们建议将业务模型化为结构化（而不是物理集成）的功能网络。这样就提出了“丰富的相互连接”，其涉及的其他方面（例如应用技术的方式）从一开始就可以分出层次，而不会作为昂贵、麻烦的事后补救措施来添加。正如您可以理解的，这与黑盒子服务取向模型紧密匹配：业务功能是结构化元素（黑盒子），提供一个稳定的基础，使服务取向项目与其业务驱动力相匹配。

业务功能计划和服务取向提供了一套新的免费工具集，将业务的概念延伸到物理公司界限以外，以将计划内业务功能的整个价值链或生态系统包括在内。业务模型的这种抽象方式使管理可以在注重工作是“如何”完成的之前，先检查事情做“什么”以及“为什么”以特定的方式进行。

功能（注重“什么”）产生了实质上更加稳定和客观的焦点领域模型。正如前面所讨论的，业务功能的简单示例包括“运送产品”和“支付雇员工资”。无论功能的业务实现属性（“方式”）是什么，无论它是内包还是外包，手动还是自动，“支付雇员工资”的基础功能是相同的。

以杂货店的结帐系统为例。收银员识别新客户、扫描客户放在商品运输带上的产品，最后客户通过某种方式支付显示的总金额。上述所有步骤都是杂货店必须提供的必要功能，来为客户结帐并接收已购买产品的资金。在美国和世界上越来越多的地方，杂货店正在增加自助服务结帐系统。乍一看，考虑到自助服务结帐与“受管理”（由收银员执行）的结帐大不相同，使人们把它当作新的功能集。但结果是，客户执行了与上面概括的步骤完全一致的步骤：新客户/销售的识别、产品的扫描和最终支付。但是，需要一个附加功能，这使得自助结帐有所不同：为了避免不诚实客户的滥用，自助服务结帐系统需要有效性检查。（这个过程通过将已扫描产品放在一个天平上，来比较已扫描产品与支持天平的系统识别的产品的重量。）那么，虽然功能集仅在此步骤（验证已购买的产品）存在差异，为客户结帐的过程已经大不相同。作为业务架构基石的功能，在过程或业务实现变化时依然保持不变。

功能显露界面

功能最重要的方面之一是，它们如何与其他功能相关联；将功能放到生态系统环境中进行考虑其实就是考虑它们的联系。因此，尽早发现它们与其他功能的联系或从本质上定义相互关联的生态系统，也是在了解哪些界限可以穿越、哪些不能穿越的过程中的关键步骤，还是最大化所有重架构努力的关键步骤。事实上，发现这些联系可能与定义功能有同样的价值，因为您操作和管理这些联系，而功能一直是本质上不变的黑盒子。联系者可以与将一个功能的输出转换为另一个功能输入的方式一样简单，例如，一个通过电话获得客户请求（“取得订单”功能）然后将其发送到另一部门以发出订单（“发出订单”功能）。此外，可能有一个联系者控制另一个功能，例如与“发出订单”功能的联系（需要通知新的客户事件，从而可以结合未决订单。

在某个业务级别，服务级别预期 (SLE) 强烈影响着联系。那么，功能模型还基于对服务级别的分析和以下说法：如果可以通过改变承担工作的人员（即非配工作的不同选项，包括外包）改变服务级别，在公司中的所有功能中，决策都是建立在相等的基础之上的。这可以使业务无需考虑执行过程的细节，而直接交换服务。例如，公司 ADP 可用于“支付雇员工资”功能，但没必要知道 ADP 过程如何进行支付的全部细节。需要考虑的仅仅是满足或超过了定义的服务级别。

只需知道功能的服务级别之间的差异，管理层就可以对改进业绩所需的功能配置做出决策。因此，相互可交换性成为了一个可比较功能。通过了解封装业务功能的规则（以可信任的方式调用和完成服务的规则），您可以更高效地完成功能的技术集成。

快速演示

只需了解应该提供的功能和功能应该执行的服务级别，您就可以管理与能源或电话供应商的关系。只需关注它们做什么，而不用管它们如何完成工作。它们提供一组不连续的功能，并完成合同规定的一定服务级别。对您来说，是否可以互换运输公司完全由其提供的服务级别确定。如果他们未执行，您可以将业务交给其他公司，以更加可靠地满足您的服务级别期望和实际运输。

您不知道为手机提供拨号音的过程的详细情况，但您仍然可以有效地管理关系和业绩产出。这对功能同样适用，它们表示您交换服务和管理执行规则时的精炼级别。

功能模型概述

业务功能模型是一个业务功能的嵌套层级。它显示了相关生态系统中所有的业务功能。由于业务过程横跨整个价值链，因此业务计划很少包括实际公司计划的相同信息。例如，UPS 和 ADP 是与其他公司联合组成集体“业务”的公司的示例。

业务功能模型是一个分类表，介绍了业务所使用的功能网络。

图 4. 业务功能模型分类

级别 1 基础功能

基础功能描述了业务的整个生态系统。它们以两种类别表示，“操作功能”（公司的实际业务界限内部的功能）和“环境功能”（公司的实际界限之外、与业务交互的其他人员和公司）。

图 5. 级别 1 基础功能模型：操作功能和环境功能

操作功能

与给定的任意功能无关、需要提供识别为业务目标的价值的功能。操作功能是业务拥有或控制的功能，包括进行以下操作的方式：

•	开发产品和服务。
•	生成这些产品或服务的需求。
•	生产或交付产品和服务。
•	与合作伙伴协作和交流。
•	规划和管理业务。

这些操作功能可以使用行业和/或业务特定的名称（例如，“开发产品/服务”可以是“研究和设计”），但几乎每个业务中的基本设置均一致。

环境功能

环境功能描述了业务的基本操作之外的功能，这些功能影响价值传递（例如，客户的期望、政府的一致性要求或现有或潜在供应商的竞争功能）或提供利用生态系统（包括客户）进行价值传递/区分的机会。他们是：

•	客户
•	面对渠道的客户
•	物流提供方
•	基础结构和一致性
•	资金提供方
•	供应商
•	政府和其他管理机构

请注意，这个业务模型包括整个价值链，因此它建立了整个虚拟业务的模型。

级别 2 功能组

功能组是功能模型中的第二个级别。例如，在核心功能“1. 开发产品/服务”中，经常有一个功能组被称为“1.1 规划产品/服务“。规划产品的产品工程组可能还包含许多级别为 3…n 的功能，描述特定的功能及其属性。

功能组通常是执行分析的一个重要初始级别，因为它所在的功能组级别中的服务级别、障碍和约束、以及组织所有权/责任可以首先被提取并成为可操作的功能。

级别 3 业务功能

功能组被分解为业务功能。业务功能是业务功能计划的基石。业务功能可以分解为更细的业务功能。在业务功能级别有许多捕捉到的详细属性。在分析过程中，您可以将某些业务功能分解为非常详细的级别（级别 4 及更高），也可以合并级别三的其他功能。没有必要将所有功能都分解到同一级别中。

小结

开始时，我们曾问及：

•	我们如何避免面向服务的架构重复类似的充满希望的开端，但产生与过去相同的架构错误？
•	我们如何确保所选择的实现架构与实际或所需业务状态相关？
•	我们如何在不断变化的环境中最大化服务取向实现的生命周期？

需要注意的关键点是具有 Web 服务的服务取向仅是特定模型的“实现”。模型的质量和基础决定了这些问题的答案。业务功能为您提供了一个参考的结构，使您可以提出这些问题，然后针对您业务中的相互关联的观点来进行解答。它能够发现业务的稳定因素来模型化您的架构，并提供与服务取向紧密匹配的关键层面。服务取向反过来提供经过划分但相关联的结构来实现功能，以使 IT 满足实际的业务要求并提供真正灵活的业务。