简介

　　随着Web服务的出现，面向服务成为最新推出的技术解决方案，其目的是实现业务活动的自动化。(如要全面地了解Microsoft连接系统策略中SOA及相关概念的信息，请参阅《面向服务及其在连接系统策略中的角色》。

　　面向服务体现的概念是通过长期的努力发展演变而成的，它们可对复杂的计算机系统进行模块化处理和分布，这些计算机系统能够反映和支持分布式业务世界的实体。

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

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

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

　　·我们如何防止面向服务在今后将要进行的相似计划中出现与过去相同的体系结构错误?

　　·我们如何确保选定的实现体系结构与业务要求相关联?

　　·我们如何在不断变化的环境中最大限度地延长期望的实现周期?

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

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

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

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

　　进入业务功能映射图

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

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

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

　　变动的边界

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

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

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

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

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

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

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

　　·传统的价值链合作伙伴主要从事以下工作：获得材料，将它们转化为半成品或成品，将这些成品分配给客户。

　　·业务流程外包商(BPO)能够针对材料转化或产品分配之外的业务要求提供服务，从而扩大了价值链。人力资源服务(比如制作工作单)的外包商长期以来一直都可以提供服务，但是他们提供的服务正变得越来越复杂，而且更多地集中在关键业务活动方面。例如，更好的通信技术为软件开发、求助电话等供应服务打开了低成本的海外劳动力市场。

　　·另外，自助服务正逐渐成为协作过程中的一个重要组成部分。从客户或合作伙伴要求与供应商进行更加灵活的交互，到供应商为客户和合作伙伴提供奖励，以便通过不同的方式进行交互，自助服务包括了交互过程的各个方面。通过提供或要求进行特定的在线活动(比如填充表格或财务报表)，即使政府也加入到了自助服务的潮流中。

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

　　系统的发展 – 连接的业务功能环境

　　如果你对任何指定公司的系统进行检查并观察它们的行为，你通常会发现，这些系统或应用程序能够支持特定的功能或用户团体，例如，用于金融机构的财务系统，用于营销、销售和援助性机构的客户关系管理(CRM)系统，等等。如果它们全部连接在了一起，那么它们之间的连接将不会非常完美。最终，客户将不得不忍受分离的功能竖井。他们不满意的地方在于，在新的业务开展方式的出现速度快于集成的进行速度时，现实情况很可能还是会保持这种方式。

　　既然我们无法“跟上潮流”，更无法走在变化的前面，当创新以各种不同的方式继续推动业务和客户的发展时，应用程序就要遵循一条不同的路线。我们不能大张旗鼓地将业务功能集中到现有的解决方案中;相反，我们应该接受这样一个事实：排除基础体系结构的所有成果，现实和经验告诉我们这种可能并不适合发展。由于业务行为通常本身就不稳定，再加上迅速变化的技术的影响，所以从某种程度上来说任何体系结构都将发生变化。不过，知道了这点之后，我们就可以着眼于我们的体系结构，在它的构建过程中尽可能地去适应这些变化，从而将体系结构方面的投资转化为永久的资产。

　　我们可以对它做什么?

　　对于如何延长体系结构二次设计的使用周期，这些观点都不错，但是细心的读者会注意到，它们其实都取决于是否能够获得我们的第二个问题的正确答案：实现体系结构如何与现实的业务相关联?我们回答这个问题的准确性将决定我们实现这些观点的效果。

　　现有的业务改善技术都集中于流程的改善，在应对目前的业务挑战的过程中，它们做出了巨大的进步。然而，我们第一个要关注的重点——“怎样”完成工作是以完成“什么”为前提的。其次，解决方案的限制在于如何提高技能——而不是挑战工作的基本前提。现在，大多数人在尝试解决业务问题时，都使用了这种惯例。为了对其进行改善，我们需要挑战这些前提，并提出不同的问题。

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

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