论述几个服务体系原则以及他们的敏捷度、适应性的设计。

本页内容

导言

松散的链接

服务供应商和服务用户远景

设计原理

抽象化

普遍性

依从的标准

间隔尺寸

根据要求递增排列间隔尺寸

提供可选择服务；使用集合和组件

结构考虑事项

结论

导言

当设计商业软件时，我们应该提醒自己我们的目标是交付灵活系统来支持商业需求；而不是维护的方向。就是，我们能够做到商业和技术灵活性的途径，并且它不是以它本身为结果的。这一点在涉及到web服务时必须显著的被牢记。在部属系统中达到这种时常伴随着web服务协议的灵活不仅仅是采用web服务的结果而且是其下的优秀的设计原理。在这篇文章中，我们考虑几项好的服务体系的原理和设计从他们的对灵活和适应性的影响效果。

Web服务提供一个我们能够施展更加灵活解决办法的有力的框架结构。但是，我们必须结合他们使用的服务定位并确保灵活性的需求符和的原则。我们能够看到采用组件技术和建立发展组件（CBD）的比较。组件被允许的好处例如组件重复使用和开发的市场，这两个结合将彻底的减少发表新系统的时间。然而，当组件技术像微软的COM技术被广泛的采用，许多组织只看到很少的组件重复使用和开放的市场未能成长为任何相近层面上的预期。IT能够得到其他的益处从组件的进程；例如改进系统的可测量性和能够根据需要替换组件，但是许多要求已经用来证明投资组件是不被领悟的。

为什么会这样？就是，当组件技术成为巨大的重复使用的构架，开发者没有将努力放在证实组件本身确实为另一个方案重复使用。典型的，这个努力需要了解为什么一个现有的组件胜过适用于一个从头完全适合新需求建立的简单的新的组件；当然这个新的组件也不能被下一个新系统重复使用，如此循环。换句话说，当许多组织采用组件技术，他们不再遵守CBD原则。

现在我们在服务方面面临着类似的挑战。我们能够预测Web服务技术将要被广泛的应用，但在何种程度上他们将根据SO的原则吗？并且如果他们不是，是否Web服务的承诺将是明白显著的为商业。

返回页首
　

松散的链接

松散的连接是 Web 服务器的优点之一。不讨论那些似乎能不需要利用那些较为松散的与终端（应用程序，它们由于使用了 网络协议从而得到了简化）连接的参考而可以完成的网络服务的情况

这个原则是使用一个资源仅仅通过他的已发表的服务并且没有根据直接（一级）定址在他们之后执行：

1. 服务提供者实施的变动不能影响服务的消费者。
2. 服务的消费者能够从相同的服务类型实例中选择一个（例如更换服务提供者）而不用修改他们的应用申请，除了新实例的地址。
3. 当Web服务被使用时，消费者和提供者并不需要使用同样的实施、借口、或综合应用技术（虽然他们同样被绑定使用相同的Web服务协议）。

图示1、联合应用和技术贯彻服务

联合应用的概念在商业本身与任何IT技术无关，包括应用软件和在技术层上。图1说明联合只在一定量的级别上。

在技术层我们涉及到综合平台和网络层。例如如何将J2EE与.NET结合？考虑到这个层上的综合技术也许包括分布式处理和通信技术。

在技术层我们考虑如果将一个应用软件和另一个应用软件结合起来；例如结合Seibel和SAP。电子联合公司（EAI）的技术在这个层次上是通用的方法。Web服务协议也许能够在技术层实现松散连接，但在应用层不是必须的。例如，Web服务的使用若是通过打包应用就像SAP也许去除技术依赖在对比使用他们的应用分组技术的BAPI界面之后。但是Web服务暴露的是仍然与SAP相同的特殊界面和不能从SAP应用中分离的问题。因此消费者服务是仍然牢牢的捆绑在SAP上而不是Web服务器的使用上。

因此我们需要一个独立的将服务从技术和应用中分离出来的商业服务层。使用这个，我们可以利用Business Process Layer来支持商户，它在服务层内对行消费者和销售进行内部操作(概念不能改变)，它并不直接通过SAP和Seibel作用在应用层(该执行可以改变)

然而，如果例如签订一个长年的单一供应商的商业合同，一些松散连接依赖的服务和Web服务与B2B综合似乎是不不切实际的。尽管如此，由于提供者了解其中的内幕，而商家并不希望这样的事情出项，因此在一个合同到期的时候，就可以对它的内容进行更改了这就是为什么我们必须设计SOA来反对不确定的形式的特殊商业要求 。你不能假想所有形式的松散连接能在不同的层次上机械的适应所有系统。

返回页首
　

服务供应商和服务用户远景

灵活的服务能够被同时服务供应商和服务用户的前景认同。表 1 认为一些灵活的需求对于灵活的服务比一般的服务设计原则更满意。服务用户的现实的目标通常是接受最大化的价值和最少的花费和奉献。为服务提供一个商业依据，采用被接受的优点，风险能够通过修正服务费用减少 ―― 这能够被一些既用既付形式实现但仅仅假设这个服务和商业计划被适当的设计。风险也能够通过有能力更换服务供应商来提高水平或者或通过运作费用或服务层次的提高来减少。

表格 1. 对比供应商服务和用户需求

一个被期望的服务供应商的目标是这样一个状况――给予最大的价值和最少的费用和风险。通过使尽可能多的相关运用关系和尽可能多的客户能够易于使用，以使得服务得价值达到最大化。费用的减少通过经济学的衡量，并且一个新的服务需求有一个有效率的回复。风险通过在大量不同的用户和相关应用之间传播被减少，因此需求的颠峰和低谷是可以被消除的，并且通过使用虚拟的（效率或是基础格）资源来控制需求层的变动。如果每个服务消费者都希望以各自的方式使用服务，则对于服务商来说，尝试着提供一个通用的服务满足其需求就变得更加有意义。

这些目标都从供应商的前景暗示了服务的目标。然而，这也可能是利益的斗争。例如，服务供应商可能故意的减少提供服务用户灵活的使用或锁定他们坚持的服务目标。

返回页首
　

设计原理

这一章是要检测一些设计原理的更多的细节并理解它们如何增进敏捷性，这些设计原理比如，抽象化，在以前也曾经提到过。

返回页首

抽象化

抽象化的原则通常是是用在上下关系中确保一个服务是不受约束的具体实例和其他细节。如前文所述， Web 服务提供了来源于一个基于标准的协议而不是基于根本技术的本地界面的高级抽象。其中一种服务定位原则是集中在服务做了什么而不是如何去服务。

为了实现灵活性，常用的抽象化为：

• 去除具体实例中设计的服务。
• 隐藏实例特有的内部工作方式和不太重要的服务消费者的数据或特性。
• 转换技术实例里的特殊数据类型。
• 隐藏对象特性。与可封装执行的实体接口不同，我们实际上并不希望显示出在服务中的实体的运行。因为这些运行给出了继承关系，创立了指定实体技术的继承关系，或者强制服务客户使用一个导向方法的实体，而该实体并不适用于消息模式。

其中的一些能够在类似的对象封装原则和技术构成中看到。然而，目标布不仅是在界面后隐藏细节，而且是使界面脱离技术实例和任意消弱连接的特殊性质的实例的抽象。

当建造新的组件时，这种抽象化能够将精髓部分结合到服务。新组件可能提供基本操作服务，当紧密的结合不能的到结果时这种服务被用在内部的组件和高度关联的底层汇编组件周围（虽然使用Web服务协议可能仍然适用于其他前提，如可测量性组件的动态地址），同时一个更加抽象的商业服务在在形式上被暴露。如图片2.所示，通常采用进程组件来构件的。商业服务揭示在命令层而不是独立个体层的操作（运行）。

图2. 组件揭示抽象的商业服务

用途如下：

1. 这意味着服务的消费者不得不认识如何使用特殊的基本的操作服务而不是一个命令。
2. 从灵活度的前景，服务供应商选择的内部组件配置的方式能够改变过时的毫无变化的服务消费者。
3. 基于实施的服务仍然可以为其他工程的开发者运用，那些开发者需要调解其他商业服务。

图3. 进程组件提供了现有执行的另一面

经常或许在当前的思潮，商业服务正准备被大量的现有应用软件来执行。如图3.所示，相同的模式利用一种新的进程组件仍然应用抽象的商务服务而不是由已打包的应用软件提供的基于实施的服务。此外基于实施的服务仍然被公布，所以他们能够被嵌入其他不同于商业需求的服务中。

灵活性不仅因为将服务从底层执行抽象化出来而提高，而且因为在服务中采用了更多商业概念的抽象观点，因而能够用于更广泛的上下连接中。例如，使用一个整体的信息而不是分别给消费者和供应商的信息，如此之类。然而其难度在于这些类型中的每一个都可能有独自的不与其他类型共通的数据或是操作，这就是我们不得不考虑普遍化的使用。

返回页首
　

普遍性

普遍性的原则是扩大服务的应用，这样能够用于更加广范的设想，包括还未预测到的设想，消除为每一个新需求建立特殊服务的需求。

图 4. 普遍化的服务将特殊性从普遍性中分离出来

服务普遍化的目标是使得灵活的系统成为可能，包括：

• 将公有的数据和属性从细节中分离，因此共用的部分在更加广阔的范围里被应用，而且可以嵌入到其他更多的服务中，就像图4所示。
• 服务里包含更加广泛数据和属性比一些特殊的消费服务更加被接收，因此服务适合广泛消费者的服务需求不必为每个需求发表一个不同的服务。

头两条观点好像是自相矛盾的。然而，这反映两个程序进程表现灵活的服务。首先，分解服务找出共同和特殊的精妙部分；然后再将他们结合成一个未加工的服务。很明显，这也可以被认为是微粒的另外一方面，关于这个我们将在以后讨论。

使用普遍性的未加工服务的目标是用于减少大量无法避免的暴露和维护服务。当消费者服务需要被用在新的上下连接中或者为实现他们以前未用过的服务要求额外的信息时，它对减少维护是必须的。由于之前的远见，普遍性的服务已经能提供这些了。

依赖这种特殊要求，普遍性存在于操作层或是信息/文件层。它能够被分成两个服务，如图4所示，或者文档包含两个信息结构，其中之一是符合普遍性的观点。

缺点是它可能变成一个执行的瓶颈，而且由特定使用的不连贯的数据而产生负荷。此外它依赖于特别的设定。如果你希望提供一个服务，这个服务可以在消费者层返还信息然后只需要一次操作就将所有的消费者帐户回复到平衡状态，你就应减少拥堵，并简化服务请求。然而，如果需求是纯粹的将特殊帐回复平衡状态，为什么要从各种后台系统所有帐户中招致过度的集中和返回信息？

返回页首
　

依从的标准

服从领域标准可能不被认为是理论问题，而是方便的问题。有助于提高适用性的标准的一个关键因素是它们有着相当大的稳定性，做出一点改变通常需要很长时间。因此在稳定性和变化慢方面，标准为确定可靠性提供了有用的模式/结构。标准化实现稳定，这点是吸引消费者的，因为可以灵活的从多个都符合相同标准的服务商中进行选择。同样的它能让服务提供者仅遵从当前的标准而不必建立新的服务类型就进入现有的行业成为可能。

然而，盲目的依从标准被视为是沉闷的灵活，一个有创新观念或是有勇无谋的公司可能适当的选择偏离标准，为了增加灵活性或是为了提供与众不同的服务。公布的界面中能够包含对标准的顺从：

• 商业用语和计划（而不是暴露在底部实施的私有形式）。
• 数据评估，例如参考数据。参与者承认指定的相应数据标准值与我们设想的一致。例如，小型机场区别使用IATA标准协议（对伦敦的Heathrow机场使用LHR协议），或是地区命名遵从UN/LOCODE标准协议（英国的利物浦是根据GB LIV协议命名的）。
• 商业过程，就像信息的顺序。

依从也是意味着根据那些标准的发展承担维护服务的义务。标准可能被相应的行业团体设置为顶级的行业水平，例如ACORD在保险行业的作用。另一些标准具有广泛的适应性，就像为产品编码的同意代码委员会标准。

依从标准的优势包括：

• 在服务的消费者和提供者之间有广泛的兼容性
• 基于服务的现有的标准将迅速被依从相同标准的新的服务消费者使用。
• 不同提供商的所要求的标准服务，对于用户几乎没有或是仅有很小的影响，所以可以动态的转变服务提供商

返回页首
　

间隔尺寸

间隔尺寸涉及到由服务提供的功能性的范围。进行最好的练习则需要该网络服务只具有基本的结构。。对Web服务的最初映象是会在整个互联网被低速和不可靠的连接配置的资源，这部分的反应了现实同样，使用少量的只具有基本结构的信息将能够减少传输的数量同时增加信息成功 送达的可能性，并且在传输完成时可以保持连接依然畅通。虽然连接质量不停的改善，但唯一的好建议是使用互联网对外部传送Web服务。然而，在网络更加快速和稳定的地方，Web服务如今被更加广泛的内部使用。在这种情况下，大量的精细服务和信息因此能被接受。一些间隔尺寸的好处和面对的挑战在表2中展示。这里没有规定服务都是粗糙修饰或是良好修饰过的。理想的状态是他们对精细用法的设定应该完全没有被加工过。

表 2. 对比精细和未加工服务操作

返回页首
　

根据要求递增排列间隔尺寸

在较早发行的定期杂志的一篇文章中，我们用由良好基础修饰服务构成的粗糙修饰服务介绍了服务提取层（这是对现有 Web 服务接口的直接的解释）。然而 Web 服务能够在任何的申请层被暴露。卖主已经使得从任何数据库、对象或组件中直接的暴露 Web 服务。应用包卖主可能在他们的应用软件的大量不同的层中暴露暴露 Web 服务。粒状图片 5 将例举下列的各列在间隔尺尺寸里的不同：

• 商业对象。良好修饰和不充分的从执行设计中抽象出来。
• 数据库。调用数据库也可能是被良好修饰。对于组件，虽然有些存储过程可能提供了粗糙的界面。然而，可能暴露内部数据库设计的任何方式都是不能被接收的。
• 商业组件。如果你为商业对象包建立组件，那么他们的界面可能是被粗糙修饰的，并且从良好修饰的对象方法中更好的抽象出来。当它依赖设计和组件效果时，这是没有保证的。
• 商业过程组件。基本的结构和一个对外部网络服务的良好的匹配以及一个适当的提取所反映的不是 一个内部界面而是那些有意义的商务服务的情况。

图 5. 服务的操作改变通过应用层改名间隔尺寸

图5所示，你越接近要求的应用程序服务就更加粗糙。在数据库和目标层中，良好修饰的数据库和方法调用将被贯彻在提供可测量性和执行的本地技术平台。关于间隔尺寸的决定是开发者的领域。

在这个实例中，系统A和系统B在不同的技术中被执行。和Web服务被用在去除技术依赖一样。Web服务也是从执行中抽象出来以便执行改变给服务造成最小的影响。系统A和系统B在网络中是分布式的，粗糙修饰服务被用来减少通信量。然而，当他们仍在防火墙之后时，高层的鉴定和加密技术不是明显的。我们能够和提及这些就像内部服务一样。为了能够重复使用，这些内部服务不是太粗糙修饰以便相同的服务能够在不同的上下连接中使用（如上文的普遍性）。

返回页首
　

提供可选择服务；使用集合和组件

虽然机构并不希望无必要的大量增加不同的网络服务的数量，但却没理由限制对在一个适当范围内的单个网络服务的提供。例如，一个商业服务作为个别的粗糙修饰的Web服务被暴露给第三方使用，并且同样作为一套良好修饰的服务被内部使用，或者给相近的商业同伴使用。这提供了对双方都是最好的解决方案。有两个方法达成这理想的解决方案。一个是简单的提供相同的正面平行Web服务，或是重复事由现有的网络服务并且把他们聚合成一个新的粗超修饰的服务。

图 6. 对服务传递多样化的间隔尺寸

如图6所示，服务能够从为适应不同需求的单列不同间隔尺寸中被解救出来。服务消费者A可能包括在相同的组织里并且有高速可靠的传输可用。虽然，服务消费者B是通过共用网络的访问系统的第三方。

很明显得到这个途径要付额外的费用。然而，下列的好处能够超出付出的费用：

• 建造一个Web服务与建造一个传统的接口的费用相比较是廉宜的。
• 最大化的自动化聚集和合并的有效工具
• 最重要的，帮助确保Web服务的正确间隔尺寸在有效范围内。

类似的方法用来推广服务的应用。拥有完备的功能的通用的服务被整合到那些被指定到应用于特殊要求的只有简单功能的服务中去。这个方法也帮助抽象化，作为较粗糙的修饰付隐藏良好的修饰对象接口。

返回页首
　

结构考虑事项

除了采用以上的设计原则，我们能用增加灵活性的观点考虑一些 SOA 的特定元素。

执行组件

广泛采用的SOA策略是通过包装他们或是暴露服务接口重复使用现有的应用软件。虽然这是一个快速取得进展的良好办法，它可能不利于长远的敏捷性，在某些地方留下痕迹。

SOA的本质是服务必须不受约束的被执行――意思是，服务消费者不必了解详细的执行模式。在任何一个功能或非功能层已经存在的包装问题是最初的申请是几乎无疑的不去使问题轻易的透明。例如，执行单块集成电路不支持Web服务的灵敏显示：

• 他们通常掌握不好比例，并且不能依特殊部分的比例来说明瓶颈问题。如果在它后面执行的是一个整体，你不能够简单的衡量一个独立服务的比例。
• 你不能非常容易的动态的部署一个执行整体。
• 当在同一个整体执行所有的服务时，你不能从许多服务中取出一个来改变或重新传人――因为内部的依赖关系从属于外部服务的依赖关系。

可执行服务的结构对服务消费者来说不应该是结果，但是对服务供应者很好的理解组件是具有可维护性和可测量性之类的好处揖让世很重要的。此外，可执行服务不是被好的组件组成可能影响服务消费者的灵活性，因为执行中的内部依赖，服务消费者发现在一些范围里不能任意选择服务，如图7所示。在这个例子中应当如何快速的使你能够执行公司的后勤采购行为并且使用其他的后勤公司提供的网络服务以满足你的客户对于获取信息的要求呢？当在ERP包内的内部依赖仍然存在时你如何改变一个独立的Web服务？

图 7. 避免内部依赖

即使用组件形式执行，过程的开发者仍然需要根据CBD最佳的实践，而且保证依赖是贯穿已发表服务和界面的，举例来说，不是仅仅因为方便仍然直接访问另一个组件的数据库。

理想来说，商业服务会有非常清楚的队列，它贯彻商业对象和软件组件在间隔尺寸的可追踪的层次以便在任何层次对改变的响应在其他方面影响最小。

在真实世界中，虽然，这种队列是经常不存在的。幸运的是，服务帮助从现有的集成电路或是弱的执行结构中提供良好的转换路径。通过用设计良好的Web服务包装的执行，你能够替换执行和去除内部的依赖，如图8所示。

图 8. 使用服务移植现有的应用软件

为这个过渡的最后步骤发现商业解释通常是不容易的。当发布有比较多的需要适时显示商务服务的情况时，它们中的很多会在第二步停下来。然而，我们应该了解在商业敏捷度方面，不仅仅是技术上的敏捷度通过持续使用弱执行结构保持折中。

关键点

在SOA中，我们能介绍一些‘关节点’，围绕它我们能够为服务提供者消费者介绍适应性的问题。

图 9. 关节点

图9所示的一些有限的关键点能够做出下列的结论：

1. 服务消费者应该申请使用那个服务？
2. 请求应该送到那个服务提供者？
3. 那个基本可执行服务应该收到请求？
4. 那个执行程序应该收到请求？

通过在每一个端点中从应用软件中分离出关节点，敏捷度提供最好的服务，因此判断程序和结果都不是坚固连接在代码中的。程序在这里举例，应用软件总是对相同的合理服务提出一系列问题，但是实际的端点是被点1和2所决定。我们能够使用这些关节点如下列条目所示：

• 关节点1可能也是插入更多的信息到需求中，例如特性或其他非功能的信息；或者改写需求以便能够送到操作不同服务的任意一个服务提供者那里。
• 关节点2也可能在服务供应者里用到，线路安排的请求对不同的商业单位有各自的服务。
• 除了在请求层做出路径安排决定，当在请求层做出一个排程决策时，关节点3也能够能够将简单服务的请求和通道分解为单个的基于服务的较为完备的执行块
• 关节点4能够被基于翻译安排需求的路径，或是商业的规则，例如消费者类型。
• 一个或更多关节点，典型的如2和3能够被中间者执行。

有一些方法实现每一个关节点。在一个简单的脚本也可能是一些查寻能够在一些实例中得到满足(举例来说，这样的功能可能被良好的构建于网络服务中)的同时，通常需要一些比较复杂的解决方案，或者需要提供一个可以被多重商业规则驱动的有能大的灵活性的解决方案。选项包括运行一些执行简单的转换和路径安排的服务经纪人的形式，或者可能包括更多负责功能的服务的假相。对灵敏度来说，重要的事项是这些关节点是如何计划到SOA中，并且在开发中不超出开发者的功能。

服务的假相

对大部分人来说假相的观念是熟悉的。是否在结构的上下关系中或是软件中，基本的原则是相同的；无论构建或是软件的内容如何，基本的原则都是相同的；通过基于执行的一个用于内容的隐藏来显示一个截然不同的外部情况。Web服务的假相显而易见的角色是执行一个包装，提炼基本执行技术到Web服务协议，例如SOAP和WSDL。象先前章节讨论的，假相能够被用来帮助移动遗留下来的应用软件。假相也能够被用来执行许多在SOA中的其他功能，例如过程编排的层，或Web服务管理。

在敏捷的上下连接中，一个假相能用来传递一些设计原则，论述如下：

• 提取。假相不仅压缩执行并且提供黑盒的观点，但是能够被用来从执行中更多的抽象Web服务。
• 间隔尺寸。假相能够用来为消费者组成正确的Web服务间隔尺寸，如以上图6所示。
• 形式。假相也能被用来管理新的Web服务形式的传入（就像传送了新的服务），和执行的形式。假相的执行如果能够多样化。这可能是在假相必备的重要的需求处理，并且下列的途径更加适合：
• 新的组件方法被用来建立特殊服务的特殊需求。这可能是高度乐观的，但是不是真正为其他使用推广。然而，它能够已一个模式为基础被很块的被复制。
• 在商业服务总线层被用来建造新的过程组件，是较早期刊介绍给我们一个观念。BSB与被商业领域有关的一组服务。对附加的机动性，这可能是一个如此的方式驱动使新的服务容易被添加和组成的数据库。
• 一个商业过程，或机动的编排，例如微软的BizTalk服务。我们认为只是一个非常灵敏的能够执行许多假相任务的方案

服务经纪人

服务经济人提供转换或使路径安排的机制。这样获得需求进入的地址并且发送它代替另一个。由于WS-Addressing 协议提供了可以使服务请求地址路径能够被动态确定的框架，它在这里得到了特别的应用。在Web服务能力之内，服务经纪可能采取许多形式，比如：

• 为一个任务建立或获得新的软件组件，并且贯彻在应用服务里
• 硬件路由器，其中的一些现在正在形成Web服务路由器的能力
• Web服务管理（WSM）工具，其中的一些包括经纪人功能
• 机动的排列能够再次执行这个――虽然它可能仅仅为了经纪人被断掉

就像在早先的章节里看到的，没有对每个关节点需求的单一解决办法。有用的产品，或那些在建造在房子里的能够经常在多个函数中执行并且为许多关节点服务。

附加说明，许多产品，例如显著的机动排列和WSM工具，除了这里需求的以外还执行其他函数。作为可能不恰当执行选项的花费，你不太可能得到一个仅仅执行简单经纪人函数。得到这些通常是一个组织而不是一个工程层决定的。然而，当判定它们的全部功能时，将他们同时运用于简单和复杂的连接请求下会很有意义，尽管这样的操肯定作会和理想状态以及在高速状态下进行简单的转换的情况产生一个对比。

返回页首
　

结论

在 Web 服务里许多卖主的称述将以反映对敏捷的需要的商务问题必须的 称述开始。然而，这是一大需求和如后来被当作解决方案呈献的 Web 服务技术之间的大的差距。当Web服务成为一个重要的运用方法时，传递商务迅捷就更多的成为一种根植于迅捷观念的商务需要和构建于本参考所勾画的迅捷使用的良好设计的结果。

当敏捷度可能是令人满意时，在报告里传递原则要点可能不被坦率的作为下列需要被克服的缺点。

• 组织的文化和计划的定位。同样的，那个计划定位禁止了组件的重复使用，这也可能扼杀敏捷度。商业的需求作为一个整体而言不被考虑，并且可能被适用在别处的通用的服务将不被传送。
• 短期思考。符合当前的需求压力没有留下机会讨论将来的需求。它可能并不是通过试图引入在这里所描述的概念阻止IT，而是使它(IT)更加在商务中难以获得认同。
• 商业秘密。同时商业可能希望敏捷，它不一定是想要以IT分享可能需要的敏捷的解决的商务策略。
• 抽象和概括的能力。在开发者中必须的技巧不总是共同的，明显的如果他也需要对商业充分的熟悉，能够抽象和概括商务观念。

如果商业变得更加敏捷，他们肯定赞成这个观点。当他们本身的行为能够造成以上的缺陷，商业领导不能持续的哀叹IT行业的响应改变方面明显的缺陷。同样的，IT部门在解决方案中也一定在进行他们那部分的灵敏度设计，但并不代表它是IT卖主最后的“魔法子弹”。

转到原英文页面

返回页首