随着Web服务的出现，面向服务成为最新推出的技术解决方案，其目的是实现业务活动的自动化。(如要全面地了解Microsoft连接系统策略中SOA及相关概念的信息，请参阅《面向服务及其在连接系统策略中的角色》。)面向服务体现的概念是通过长期的努力发展演变而成的，它们可对复杂的计算机系统进行模块化处理和分布，这些计算机系统能够反映和支持分布式业务世界的实体。

依照面向服务目前的定义，这些服务通过标准的、已发布的、可发现的接口提供了可访问网络的功能。这些核心的特征至少保证了协议(在语法方面)的互操作性，而无须考虑平台、提供者和位置的限制。

然而，在目前，解决技术集成问题本身并不足以证明面向服务投资的正确性。为了强化它的论据，针对面向服务对于业务灵活性的支持，正在做出各种不同的声明，这是因为此论据存在于面向服务的环境中，在此环境中，通过公开服务、重新配置服务、重新使用服务等措施，更容易创建解决方案。也许如此，但是根据面向服务的上述定义，许多业务在某种程度上都已经实现了面向服务，可它们仍然要努力提供业务需要或要求的IT支持。

为了证明面向服务投资的正确性，我们需要解决以下问题，它们在新体系结构原则的每个部署项目中都会出现：

就像我们将要看到的，这些问题的答案是相互联系的。面向服务仅仅体现了系统的一个特定方面；它并不是系统的起始点，而且有缺陷的基础将导致不完善的实现。此基础是解决实现问题所缺少的一个重要环节，实现的难点在于，如何通过正式化的、可重复的、创新的方式提出上述的业务要求并将它们与面向服务的模型相关联。

通常，在描述或模拟业务要求所使用的方法与它们的最终技术实现之间并没有明确定义的关系。目前，大多数获取和体现业务要求的工作都使用了业务流程建模方法和技术。对于任何将业务要求及策略与IT策略和实现相关联的尝试，正式的业务流程建模都是必不可少的一部分，但它并不能满足需要。

业务流程需要以实现业务目标所需的活动为核心，而无须考虑传统的“砖瓦泥灰(实体)”筑成的边界——你今天内部进行的工作明天也许就会外包。通过灵活的业务模型，我们的设计必须能够支持这些协作要求，并考虑到边界、网络的作用、不断变化的责任等因素，同时还要顺利地穿越这些边界，而不会受到系统、公司或其它边界的影响。传统的业务流程建模没有将业务要求与技术结构和投资相结合。它并没有边界、部署、封装等问题的概念。

换句话说，除了具有活动表现功能之外，一个较好的模型必须支持业务之间的依赖性以及对它提供支持的服务的独立性。

返回页首

进入业务功能映射图

为了实现这些目标，我们建议将业务设想为功能网络。功能模拟了业务功能的行为(指它的外部可以看到的行为，相对于它的行为方式和内部行为)和期望的性能标准。Pay Employees(向员工支付薪水)和Ship Product(发送产品)就是两个功能实例。这些功能一般具有“所有者”和“客户”，它们被要求按照一定的标准(比如每个时间段的工作单位，或某些质量度量标准)进行工作。这指的是做了“什么”(行为)以及行为的期望或约定的标准。功能的内部包含了此功能的详细信息，介绍了它是如何在指定的时间点针对人、过程步骤、技术等因素而实现的。在这种虚拟的标准下，我们仅关注外部情况，它们是如何实现的并不重要。这种功能在本质上是一个“黑盒”。

功能具有充分的描述性，可以说明某个功能是如何满足业务要求的以及与它交互需要什么，另外它们也进行了充分的概括，从而能够提供所需的稳定性，并藉此提供稳定、持久的基础。网络方面则描述了各项功能在执行业务所需的工作时是如何互连的。

我们已经着重强调了可观察、可度量的外部行为以及它们与其它功能的联系，现在我们可以立刻看到功能和面向服务之间的平行关系。在它们大多数的抽象含义中，业务功能和Web服务都是黑盒，它们的联系非常重要，它们与内部工作相关联，但又与其相分离。直观上，这种平行性对二者之间的紧密结合进行了充分的预示。

变动的边界

在了解业务功能的详细信息之前，我们需要彻底地理解通过IT满足业务要求的问题，这一点很重要。IT是改善体系结构和重新进行项目的原因和结果。毕竟，在对我们使用新技术的工作提供支持之前，业务需要获得明确的投资回报率(ROI)和价值策略。

对于大多数业务而言，IT基础结构都是一个复杂的互连系统，它会随着时间的推移有机地发展，以满足各种持续变化的需求。每项新技术都推动了体系结构的变化，只要提供足够的资金，它们就一定能够将现有的系统重新设计为一个有组织的、灵活的、由各种部件组成的整体，这个整体将业务需求、系统和数据流结合在了一起。然而，即使你可以对体系结构进行完整的重新设计，在共享所有数据且不存在复制的应用程序的情况下，随着时间的推移，该基础结构还是会逐渐变回与原来相似的组织结构。这种情况为什么会发生？它是如何发生的？这里牵涉的问题是什么？

连接的业务

在全球化和竞争力的推动下，标准的线性供应链已发展为复杂的价值网络，该网络由参加公共业务的合作伙伴组成。图1和图2演示了从线性价值链到复杂的价值链网络的发展过程。这些网络正在不断地扩展，以包含不断增多的合作伙伴(客户、政府、金融服务组织等等)提供的附加服务。对于系统或应用程序的投资需要考虑到这种不断增强的互连性所带来的需求或机遇。

价值链的发展 - 业务成为连接的合作伙伴网络

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

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

当我们在考虑公司、公司的客户、政府以及他们合作实现业务目标的发展过程时，形成了三个主要的模型，这些模型互为补充，以实现业务目标：

换句话说，现代的业务在多个方面跨越了传统的公司边界，我们的建模技术和解决方案要体现出这个特点，这样才合乎情理。在进行计划时，公司边界与公司的财政年度正变得越来越相似。二者都属于重要而相关的边界，但是业务必须跨越这些边界进行计划和预算。

业务功能 – 一个更稳定的基础

因此，我们发现真正的问题是：“在你为客户构建一个解决方案时，该体系结构的哪些元素真正的具有持久性并允许你应对各种变化？”这是因为，对于体系结构的陈旧化，这个问题的答案显然提供了最佳的投资回报率(ROI)和最好的保险。

我们发现，稳定的元素不仅仅包括业务的实际行为(例如创建采购订单、生成发票、发送产品等等)。我们将这些业务活动称为业务功能，它们比较稳定，但是业务如何通过人、过程和技术来执行这些活动，以及这些活动如何组合成流程，还远不够稳定。因此，现在我们需要调查清楚业务能做什么以及它的功能是什么。

在我们继续之前，让我们介绍几个与我们的讨论有关的定义：

•	业务功能是一种特殊的能力或性能，业务可以掌控或交换这种功能，以达到特定的目的或结果。功能描述了业务为客户创造价值的行为(结果和服务级别)；例如，向员工支付薪水或发送产品。业务功能对人、流程/过程、技术和信息进行了抽象化，并将它们封装到了基本的构造块中，这些构造块可促进性能的提高，为重新设计分析提供便利。 图3. 功能是“黑盒”，其输入和输出是根据明确的服务级别要求而定义的
•	功能连接器表示业务功能之间存在的链接。连接不仅仅是简单的消息；它们包含了丰富的语义信息。它们是功能模型中存在的各种连接器，此功能模型主要负责信息交换(输入/输出、支持信息)以及政策的控制或制订(规章制度的影响)。
•	业务流程描述了业务如何执行或实现指定的功能，或功能如何进行连接，以提供预期的结果。Hammer和Champy是上世纪90年代的业务流程运动的创始人，并因此而享有盛誉，他们将业务流程精心定义为：提升在过程之上的端到端的工作。流程跨越了组织部门和功能。
•	业务功能映射图是功能及其连接的定义，也是它们清晰的结构略图，这些功能和连接能够促进一个典型公司的各项活动。业务功能是业务体系结构的构造块，因此将功能视为体系结构蓝图是一个很好的类比，同时流程在任何指定的时间都是这种体系结构的实现。一旦建立了这种更客观、更稳定的业务观点，公司就可以更深入地了解功能之间的依赖性，并更好地理解业务：在一系列业务之内，跨越业务单位，超越时间。

功能 – 最佳的问题解决层

我们建议将业务建模为一种结构化(与物理集成相对)的功能网络。这主要着眼于“丰富的互连性”，通过它，其它方面(比如应用技术的方式)可以从开始就进行分层，而不是作为昂贵、麻烦的补充措施而添加。就像你能够看到的，这紧密结合了类似黑盒的面向服务模型：业务功能属于结构元素(黑盒)，它们提供了一个稳定的基础，将面向服务项目与它们的业务驱动程序结合在了一起。

业务功能映射图和面向服务提供了一套全新的免费工具，它们将业务的概念扩展到了公司的物理边界之外，从而将整个价值链或业务功能生态系统包含到了此映射图中。业务模型的这种抽象性使管理人员可以在关注具体怎样完成工作之前，调查什么在工作、它们为什么会以某种特定的方式工作。

功能主要关注“什么”，它产生了更稳定、更客观的焦点区域模型。如上文所述，简单的业务功能实例包括“发送产品”和“向员工支付薪水”。无论此功能的业务实现属性(“怎样”)是什么，无论它是内包还是外包，无论它是手动还是自动，“向员工支付薪水”的基础功能都是相同的。

以食品杂货店的结帐系统为例：出纳员确定一个新客户，在传送带上扫描此客户购买的产品，最后客户通过某种方式支付显示的付款总额。上述的所有步骤都是食品杂货店的必备功能，其目的是为客户结帐并收取货款。在美国，食品杂货店正开始使用自助结帐系统，在世界其它地方，这种情况也越来越普遍。乍一看，自助结帐似乎表现出与 “操作式”(由出纳员执行)结帐明显不同的特点，可将它视作一个新的功能集。但事实上，客户仍可以执行与上述完全相同的步骤——确定一个新客户/购买需求，扫描产品，最后付款。不过，自助结帐需要一个附加的功能，这也是它的不同之处：为了避免不诚实的客户滥用此系统，自助结帐需要一种真实性检查功能。(将扫描过的产品放在秤盘上，比较已扫描产品的重量和称重系统获得的产品重量，即可完成检查。)因此，尽管功能集的差异仅此一项——验证已售出的产品，为客户结帐的流程仍然具有很大的区别。在流程或业务实现过程发生改变时，业务体系结构构建的这些功能仍然能够保持稳定。

功能公开了接口

功能最重要的方面之一是它们如何联系其它功能；在生态系统的环境下考虑功能其实就是考虑它们的连接。因此，尽早检测出它们与其它功能的连接，或者从根本上定义互联的生态系统，也是实现以下目标的关键步骤：理解哪些边界是可以跨越的，而哪些不可以；最大限度地强化所有重新设计的体系结构成果。事实上，发现连接与定义功能可能一样有价值，这是因为，在功能保持基本不变的黑盒状态时，你需要操作和管理这些连接。连接器可能与将一个功能的输出转换到另一个功能的输入的方法一样简单，例如，某项活动通过电话呼叫获得客户请求(“获得订单”功能)，并将此客户请求发送到另外一个部门，以处理订单(“处理订单”功能)。另外，可能有一个连接器来控制另一个功能，比如与“处理订单”功能(此功能需要对新的客户事件进行通知，这样待办订单才能进行合并)的连接。

在业务级别，服务级别期望(SLE)对连接具有强烈的影响。因此，功能模型也是以特定的服务级别分析和以下概念为基础的：如果改变工作人员可以实现服务级别的变化(即，评估不同的来源选择，在它们之间进行外包)，那么就可以跨越公司内的所有功能在平等的基础上做出决策。这样业务就可以交换服务，而无需纠缠于执行流程的细节。例如，可以利用ADP公司提供“向员工支付薪水”的功能，但是却无需了解ADP处理工资单的所有详细信息——是达到还是超越了已定义的服务级别，这是唯一需要关心的问题。

只要知道功能的服务级别差异，管理人员就可以基于提高业务绩效所需的功能配置做出决策。这样，可互换性就成为了一种可比较的功能。通过了解封装业务功能的规则(以一种可信的方式调用和完成服务的规则)，你就可以有效得多地完成功能的技术集成。

简捷的说明

只要了解他们应该提供的功能和他们应该达到的服务级别，你就可以管理你与能源或电话提供商的关系。你只需要关心他们做什么，而无需关心他们怎么完成它。他们提供了有限的功能，并立约承诺达到一定的务，你可以将业务转移到能够更稳定地满足你的服务级别要求和实际的供应条件的其它地方。

你并不了解向你的移动电话传递拨号音的过程的细服务级别。对你来说，运营商是可互换的，这完全以他们提供的服务级别为基础。如果他们不能完成任节，但是你仍然可以非常有效地管理关系和性能目标。这对功能同样适用，功能代表了一种抽象级别，你可以通过它们交换服务，交换和管理性能规则