图1. “当时”—传统的供给链
图2. “现在”—合作网络
当我们在考虑公司、公司的客户、政府以及他们合作实现业务目标的发展过程时，形成了三个主要的模型，这些模型互为补充，以实现业务目标
%26#8226;传统的价值链合作伙伴主要从事以下工作获得材料，将它们转化为半成品或成品，将这些成品分配给客户。 %26#8226;业务流程外包商(BPO)能够针对材料转化或产品分配之外的业务要求提供服务，从而扩大了价值链。人力资源服务(比如制作工作单)的外包商长期以来一直都可以提供服务，但是他们提供的服务正变得越来越复杂，而且更多地集中在要害业务活动方面。例如，更好的通信技术为软件开发、求助电话等供给服务打开了低成本的海外劳动力市场。 %26#8226;另外，自助服务正逐渐成为协作过程中的一个重要组成部分。从客户或合作伙伴要求与供给商进行更加灵活的交互，到供给商为客户和合作伙伴提供奖励，以便通过不同的方式进行交互，自助服务包括了交互过程的各个方面。通过提供或要求进行特定的在线活动(比如填充表格或财务报表)，即使政府也加入到了自助服务的潮流中。 换句话说，现代的业务在多个方面跨越了传统的公司边界，我们的建模技术和解决方案要体现出这个特点，这样才合乎情理。在进行计划时，公司边界与公司的财政年度正变得越来越相似。二者都属于重要而相关的边界，但是业务必须跨越这些边界进行计划和预算。 系统的发展 - 连接的业务功能环境 假如你对任何指定公司的系统进行检查并观察它们的行为，你通常会发现，这些系统或应用程序能够支持特定的功能或用户团体，例如，用于金融机构的财务系统，用于营销、销售和援助性机构的客户关系治理(CRM)系统，等等。假如它们全部连接在了一起，那么它们之间的连接将不会非常完美。最终，客户将不得不忍受分离的功能竖井。他们不满足的地方在于，在新的业务开展方式的出现速度快于集成的进行速度时，现实情况很可能还是会保持这种方式。 既然我们无法“跟上潮流”，更无法走在变化的前面，当创新以各种不同的方式继续推动业务和客户的发展时，应用程序就要遵循一条不同的路线。我们不能大张旗鼓地将业务功能集中到现有的解决方案中;相反，我们应该接受这样一个事实排除基础体系结构的所有成果，现实和经验告诉我们这种可能并不适合发展。由于业务行为通常本身就不稳定，再加上迅速变化的技术的影响，所以从某种程度上来说任何体系结构都将发生变化。不过，知道了这点之后，我们就可以着眼于我们的体系结构，在它的构建过程中尽可能地去适应这些变化，从而将体系结构方面的投资转化为永久的资产。 我们可以对它做什么? 对于如何延长体系结构二次设计的使用周期，这些观点都不错，但是细心的读者会注重到，它们其实都取决于是否能够获得我们的第二个问题的正确答案实现体系结构如何与现实的业务相关联?我们回答这个问题的准确性将决定我们实现这些观点的效果。 现有的业务改善技术都集中于流程的改善，在应对目前的业务挑战的过程中，它们做出了巨大的进步。然而，我们第一个要关注的重点——“怎样”完成工作是以完成“什么”为前提的。其次，解决方案的限制在于如何提高技能——而不是挑战工作的基本前提。现在，大多数人在尝试解决业务问题时，都使用了这种惯例。为了对其进行改善，我们需要挑战这些前提，并提出不同的问题。 业务功能 – 一个更稳定的基础 因此，我们发现真正的问题是“在你为客户构建一个解决方案时，该体系结构的哪些元素真正的具有持久性并答应你应对各种变化?”这是因为，对于体系结构的陈旧化，这个问题的答案显然提供了最佳的投资回报率(ROI)和最好的保险。 我们发现，稳定的元素不仅仅包括业务的实际行为(例如创建采购订单、生成发票、发送产品等等)。我们将这些业务活动称为业务功能，它们比较稳定，但是业务如何通过人、过程和技术来执行这些活动，以及这些活动如何组合成流程，还远不够稳定。因此，现在我们需要调查清楚业务能做什么以及它的功能是什么。 在我们继续之前，让我们介绍几个与我们的讨论有关的定义 %26#8226;业务功能是一种非凡的能力或性能，业务可以掌控或交换这种功能，以达到特定的目的或结果。功能描述了业务为客户创造价值的行为(结果和服务级别);例如，向员工支付薪水或发送产品。业务功能对人、流程/过程、技术和信息进行了抽象化，并将它们封装到了基本的构造块中，这些构造块可促进性能的提高，为重新设计分析提供便利。
图3. 功能是“黑盒”，其输入和输出是根据明确的服务级别要求而定义的
%26#8226;功能连接器表示业务功能之间存在的链接。连接不仅仅是简单的消息;它们包含了丰富的语义信息。它们是功能模型中存在的各种连接器，此功能模型主要负责信息交换(输入/输出、支持信息)以及政策的控制或制订(规章制度的影响)。
%26#8226;业务流程描述了业务如何执行或实现指定的功能，或功能如何进行连接，以提供预期的结果。Hammer和Champy是上世纪90年代的业务流程运动的创始人，并因此而享有盛誉，他们将业务流程精心定义为提升在过程之上的端到端的工作。流程跨越了组织部门和功能。
%26#8226;业务功能映射图是功能及其连接的定义，也是它们清楚的结构略图，这些功能和连接能够促进一个典型公司的各项活动。业务功能是业务体系结构的构造块，因此将功能视为体系结构蓝图是一个很好的类比，同时流程在任何指定的时间都是这种体系结构的实现。一旦建立了这种更客观、更稳定的业务观点，公司就可以更深入地了解功能之间的依靠性，并更好地理解业务在一系列业务之内，跨越业务单位，超越时间。
功能 – 最佳的问题解决层
我们建议将业务建模为一种结构化(与物理集成相对)的功能网络。这主要着眼于“丰富的互连性”，通过它，其它方面(比如应用技术的方式)可以从开始就进行分层，而不是作为昂贵、麻烦的补充措施而添加。就像你能够看到的，这紧密结合了类似黑盒的面向服务模型业务功能属于结构元素(黑盒)，它们提供了一个稳定的基础，将面向服务项目与它们的业务驱动程序结合在了一起。
业务功能映射图和面向服务提供了一套全新的免费工具，它们将业务的概念扩展到了公司的物理边界之外，从而将整个价值链或业务功能生态系统包含到了此映射图中。业务模型的这种抽象性使治理人员可以在关注具体怎样完成工作之前，调查什么在工作、它们为什么会以某种特定的方式工作。 功能主要关注“什么”，它产生了更稳定、更客观的焦点区域模型。如上文所述，简单的业务功能实例包括“发送产品”和“向员工支付薪水”。无论此功能的业务实现属性(“怎样”)是什么，无论它是内包还是外包，无论它是手动还是自动，“向员工支付薪水”的基础功能都是相同的。 以食品杂货店的结帐系统为例出纳员确定一个新客户，在传送带上扫描此客户购买的产品，最后客户通过某种方式支付显示的付款总额。上述的所有步骤都是食品杂货店的必备功能，其目的是为客户结帐并收取货款。在美国，食品杂货店正开始使用自助结帐系统，在世界其它地方，这种情况也越来越普遍。乍一看，自助结帐似乎表现出与 “操作式”(由出纳员执行)结帐明显不同的特点，可将它视作一个新的功能集。但事实上，客户仍可以执行与上述完全相同的步骤——确定一个新客户/购买需求，扫描产品，最后付款。不过，自助结帐需要一个附加的功能，这也是它的不同之处为了避免不老实的客户滥用此系统，自助结帐需要一种真实性检查功能。(将扫描过的产品放在秤盘上，比较已扫描产品的重量和称重系统获得的产品重量，即可完成检查。)因此，尽管功能集的差异仅此一项——验证已售出的产品，为客户结帐的流程仍然具有很大的区别。在流程或业务实现过程发生改变时，业务体系结构构建的这些功能仍然能够保持稳定。 功能公开了接口 功能最重要的方面之一是它们如何联系其它功能;在生态系统的环境下考虑功能其实就是考虑它们的连接。因此，尽早检测出它们与其它功能的连接，或者从根本上定义互联的生态系统，也是实现以下目标的要害步骤理解哪些边界是可以跨越的，而哪些不可以;最大限度地强化所有重新设计的体系结构成果。事实上，发现连接与定义功能可能一样有价值，这是因为，在功能保持基本不变的黑盒状态时，你需要操作和治理这些连接。连接器可能与将一个功能的输出转换到另一个功能的输入的方法一样简单，例如，某项活动通过电话呼叫获得客户请求(“获得订单”功能)，并将此客户请求发送到另外一个部门，以处理订单(“处理订单”功能)。另外，可能有一个连接器来控制另一个功能，比如与“处理订单”功能(此功能需要对新的客户事件进行通知，这样待办订单才能进行合并)的连接。 在业务级别，服务级别期望(SLE)对连接具有强烈的影响。因此，功能模型也是以特定的服务级别分析和以下概念为基础的假如改变工作人员可以实现服务级别的变化(即，评估不同的来源选择，在它们之间进行外包)，那么就可以跨越公司内的所有功能在平等的基础上做出决策。这样业务就可以交换服务，而无需纠缠于执行流程的细节。例如，可以利用ADP公司提供“向员工支付薪水”的功能，但是却无需了解ADP处理工资单的所有具体信息——是达到还是超越了已定义的服务级别，这是唯一需要关心的问题。 只要知道功能的服务级别差异，治理人员就可以基于提高业务绩效所需的功能配置做出决策。这样，可互换性就成为了一种可比较的功能。通过了解封装业务功能的规则(以一种可信的方式调用和完成服务的规则)，你就可以有效得多地完成功能的技术集成。 简捷的说明 只要了解他们应该提供的功能和他们应该达到的服务级别，你就可以治理你与能源或电话提供商的关系。你只需要关心他们做什么，而无需关心他们怎么完成它。他们提供了有限的功能，并立约承诺达到一定的务，你可以将业务转移到能够更稳定地满足你的服务级别要求和实际的供给条件的其它地方。 你并不了解向你的移动电话传递拨号音的过程的细服务级别。对你来说，运营商是可互换的，这完全以他们提供的服务级别为基础。假如他们不能完成任节，但是你仍然可以非常有效地治理关系和性能目标。这对功能同样适用，功能代表了一种抽象级别，你可以通过它们交换服务，交换和治理性能规则。 功能模型概览 业务功能模型是业务功能的嵌套层次结构。它公开了跨越相关生态系统的所有业务功能。由于业务流程跨越了整个价值链，业务映射图很难覆盖与实体公司映射图相同的信息。例如，UPS和ADP都是与其它公司合作构建整体“业务”的公司。 业务功能模型是一种分类图示，它描述了业务使用的功能网络。
图4. 业务功能模型分级
第1级基础功能
基础功能服务于整个业务生态系统。它们分两类表示操作功能(在公司的物理业务边界之内的东西)和环境功能(与业务互相作用的所有其他人员和公司，他们位于业务的物理边界之外)。
图5. 第1级 基础功能模型操作功能和环境功能
操作功能
无论每个指定的功能是由哪个提供者提供的，这些功能都需要提供确定为业务目标的价值。操作功能属于业务拥有或控制的功能，它们包含了以下的业务活动
%26#8226;开发产品和服务。
%26#8226;为这些产品或服务产生需求。
%26#8226;生产或提供产品和服务。
%26#8226;与合作伙伴进行协作和通信。
%26#8226;计划和治理业务。
这些操作功能可以接受特定行业和/或业务的名称(例如，“开发产品/服务”也可以称作“研究和设计”)，但是基本的设置几乎在每个业务中都是一致的。
环境功能
环境功能定位于业务基本操作之外的功能，这些基本操作或者影响了价值的传递(例如，客户的期望、政府的合规性要求或目前的供给商或新兴的供给商的竞争力)，或者提供了利用生态系统(包括客户)的机会，以便实现价值传递/差异化。它们包括
%26#8226;客户 %26#8226;面对客户的渠道 %26#8226;物流提供商 %26#8226;基础结构和合规性 %26#8226;财务提供商 %26#8226;供给商 %26#8226;政府和其它监管机构 请注重，该业务模型包括了整个价值链，因此它能够对所有的虚拟业务进行建模。 第2级功能组 功能组是功能模型中的下一级。举例来说，在核心功能“1. 开发产品/服务”内，通常会有一个称作“1.1 规划产品/服务”的功能组。负责规划产品的“产品工程”组可以进一步包含第3-n级的各种功能，它们描述了特定的功能及其属性。 功能组通常是一种重要的分析初始级别，这是因为它位于功能组级别，在此，服务级别、障碍和约束、组织所有权/责任都可以首先进行抽象化，并获得可操作性。 第3级业务功能 功能组分解为业务功能。业务功能是业务功能映射图的构造块。业务功能可以分解为更细粒度的业务功能。在业务功能级别，可以捕捉到具体的属性。在分析中，你可以将一些业务功能分解到非常细微的级别(第4级以上)，并在第3级聚合其它功能。无需将所有的功能都分解到相同的级别。 结论 开始时，我们问了以下问题 %26#8226;我们如何防止面向服务的体系结构在今后有望实施的相似计划中出现与过去相同的体系结构问题? %26#8226;我们如何确保选定的实现体系结构与实际或期望的业务状态相关联? %26#8226;我们如何在不断变化的环境中延长期望的实现周期? 结合Web服务的面向服务只是特定模型的实现，这是要把握的要害点。它是决定这些问题答案的模型的质量和基础。业务功能为你提供了一个参考框架，这样你就可以针对业务中的各种不同的互连观点提出和回答这些问题。它发现了稳定的业务元素，可围绕你的体系结构进行建模，同时，它也提供了一个紧密结合面向服务的要害层。另外，面向服务提供了一种既分隔又连接的结构，以实现这些功能，这样IT就能够满足实际的业务要求，并提供真正灵活的业务。