ACM

ACM通信

首页 / 杂志存档 / 2010年1月(第53卷第1期) / 为重用考虑 /全文

虚拟扩展

为重用考虑

保罗·d·威特曼、特里·瑞恩著
ACM通讯，2010年1月，Vol. 53 No. 1, 142-147页
10.1145/1629175.1629209
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 分享: 通过电子邮件发送在reddit分享在StumbleUpon分享分享到黑客新闻在推特上分享在Facebook上分享

许多组织成功地实现了从对象、子程序到组件到软件产品线的精细到中等粒度的软件重用。然而，关于大粒度重用的发布相对较少。这种大粒度重用的一个例子可能是全世界业务单元中重用的整个Internet银行系统(应用程序和基础设施)。相比之下，当前研究中的“大规模”软件重用通常指重用大量较小组件的系统，或者可能重用子系统。⁹在本文中，我们将探讨一个具有内部开发小组的组织的案例，该组织在大粒度软件重用方面非常成功。

BigFinancial，特别是BigFinancial技术中心(BTC)，已经创建了许多软件系统，在多个企业和多个国家得到重用。因此，BigFinancial和BTC为案例研究提供了丰富的数据来源，研究这些项目的特征和它们成功的原因，以及研究那些不太成功的项目，了解导致这些结果的原因，以及可以采取哪些不同的措施来防止未来的问题。研究的重点是开发过程中的技术、过程和组织要素，而不是具体的产品特性和功能。

支持大粒度级别的重用可能有助于缓解在更传统的重用程序中出现的一些问题，这些重用程序往往是细粒度的。特别是，由于BigFinancial试图在业务流程和操作模型中获得共同性，大粒度组件的重用与其业务目标更加紧密地结合在一起。同样的效果可能不会发生在细粒度的重用中，因为业务单元能够更容易地挑选和选择要重用的组件。

BTC是BigFinancial的一个技术开发部门，在美国东部和西部都有业务。BTC雇佣了大约500人，最终通过一个单一的直线经理向BigFinancial的全球零售业务部门负责人汇报工作。BTC为BigFinancial提供产品和基础设施组件，其产品线多年来包括消费者互联网银行服务、出纳员系统、ATM软件和网络管理工具。BigFinancial的美国业务总部位于美国东部，在全球范围内雇佣了8000多名技术人员。

在与BTC的合作中，我们从大约25个案例中选择了3个案例进行进一步研究。这些案例包括Java银行工具包(JBT)及其相关应用系统、全球单点登录(WSSO)子系统和大金融消息开关(BMS)。

回到顶部

后台软件重用和大财务

文献中出现了各种关于软件重用的定义。Karlsson将软件重用定义为“从现有软件资产创建软件系统的过程，而不是从头开始构建软件系统。”软件重用方法的一种分类包括重用范围、重用目标和重用粒度的概念。⁵粒度的概念是区别BigFinancial软件重用类型的一个关键因素，因为BigFinancial已经证明了大粒度重用程序在一次构建一个系统并在多个业务中重用它方面的成功。

技术模型，如Griss提出的⁴并由克莱门茨和诺斯罗普进一步阐述²和克鲁格6建议可以将软件组件与制造可重用部件的概念进行类似的处理，这些部件有助于整个产品线的一致性，并提高制造效率。这种重用的好处包括用户界面等功能的高度通用性，⁷这就增加了某些领域的转换成本和客户忠诚度。这可以在逻辑上扩展到银行系统，以通用功能和用户界面的形式跨业务中的系统和跨业务单元。

BigFinancial有几个成功的大粒度重用项目实例。我们确定了在广泛的业务环境或业务领域中成功重用的项目，这给BigFinancial带来了显著的好处。其中包括JBT平台及其相关应用程序包，以及Worldwide SSO产品。这些项目展示了广泛的成功，作者评估了这些证据，以确定哪些因素对每个项目的成功有贡献，哪些因素可能有不利影响。

作者还确定了另一个在相对狭窄的业务环境范围内成功重用的项目。这个项目，即BigFinancial Message Switch (BMS)，是为全区域级别的重用而设计的，并且在该级别上取得了成功。因此，它似乎对其客户基础所需的特性和功能进行了适当的投资，而且似乎没有过度投资。

回到顶部

网上银行及相关服务

我们将BTC的多用途Java银行工具包(JBT)作为一个成功项目的典范。Toolkit在多个业务单元中广泛使用，并表示在最大粒度级别上的重用，以及大规模基础设施组件的重用。目前，JBT支持三种应用程序集，包括在线银行、门户服务和警报功能，因此，JBT基础设施已经被多个应用程序重用。在某种程度上，可以将这些多个应用程序作为子案例进行研究，尽管到目前为止，它们倾向于作为一个组部署。此外，在线银行、门户服务和警报功能本身在应用程序级别上跨全球多个业务单元重用。

最初的发现表明，几个当前和最近的项目显示了跨独立业务单元的显著重用，这些业务单元可以做出替代的技术开发决策。对研究结果进行了总结表1．

虽然需要大量的努力来支持多种语言和特定于业务的功能可变性，但BTC发现，通过将产品设计为基于规则的，并通过设计用户界面将内容与语言分离，它能够适应这些需求。通过这种方式，业务规则驱动了Internet银行应用程序的行为，而语言和格式定义工具驱动了应用程序行为的细节，同时维护了一组一致的底层应用程序代码。

在20世纪90年代末，BTC负责创建系统基础设施组件，构建在行业标准的商业操作系统和组件之上，以支持其客户在BigFinancial中所需的银行功能。这些基础设施组件的功能包括系统管理、高可靠性日志记录过程、高可用性机制，以及其他在创建组件时尚未在商业产品中提供的功能。同样的基础设施被用于支持消费者互联网银行和自动柜员机。在这里，互联网银行服务将被定义为传统互联网银行产品(LIB)。

BigFinancial最初进军互联网交易服务是通过另一个重用实例实现的。利用互联网之前的银行组件，BTC能够从产品中显示的页面中“抓取”内容，并将HTML代码包装起来，以便在Web浏览器上显示。其他组件负责修改Internet的输入和菜单功能。

这种Internet交付方法的目的是在不修改遗留业务逻辑的情况下，更快地将产品交付到Internet，从而也降低了风险。这相当于业务和表示逻辑的早期分离，internet之前的业务逻辑仍然存在，表示层为浏览器环境重新映射其内容。

2002年，BigFinancial和BTC认识到两个关键问题需要解决。他们遗留的互联网银行应用程序的平台已经接近生命的尽头(第一次部署是在1996年)，并且有太多不同的平台提供给消费者互联网产品。BTC的互联网银行、警报和门户功能都需要单独的硬件和操作环境。BTC计划其活动，使新开发的成本能够适应现有的年度维护和新开发成本，其客户已经支付。

BTC和企业高管表示，对BTC组织的信任是让BTC有机会开发JBT产品的关键。此外，BTC之前在细粒度和中等粒度重用软件组件方面的成功导致了一种将重用作为最佳实践的文化。

自2002年年底开始，BTC开发了一个综合的平台和应用程序集，提供一系列的消费互联网功能。这个名为Java银行工具包(JBT)的基础架构包基于Java 2企业版(J2EE)标准，旨在让大金融将其服务器基础架构集中用于消费者互联网功能。作者对几位BTC经理和架构师进行了详细的访谈，并审阅了数百份文档。JBT的当前部署统计数据显示在表2．

JBT的基础设施和应用程序是由BTC及其区域合作伙伴设计和构建的，并听取了其全球客户的意见。BTC的经验表明，消费者银行的应用程序在各个业务部门之间并没有本质上的区别，BTC提出并获得了资金，以创建一个统一的互联网银行应用程序集。市场评估确定，市场上没有合适的、全球可重用的、完整的应用程序，也没有任何其他具有成功记录的组织对交付有信心。最终获得融资批准的是大金融科技和企业高管。

JBT的需求需要几个主要的功能元素。这些需求在支持各种计划的应用程序包和应用程序本身的基础设施元素之间进行了划分。随JBT最初版本一起交付的应用程序包括一个消费者互联网银行应用程序集、一个帐户活动和余额警报功能，以及一个门户内容工具集。

这些组件都被设计为可以在世界各地的每个业务单元中完整地重用，只需要对业务规则和语言短语进行更改，这些更改可能是每个业务特有的。每个JBT应用程序的基本需求之一是包含设计为尽可能多的业务单元通用和共享的功能，同时允许所有必要的特定于业务的可变性。

这种可变性是在需求过程中计划的，构建在LIB基础设施和应用程序以及已经在生产中的遗留门户和警报服务上。特定于地区和业务的可变性的例子包括语言变化、对当地法规需求的遵从性，以及基于当地和地区竞争需求的功能。

JBT最初的高级需求文档包含了一系列类别的需求。这些类别包括技术、操作、部署、开发和工具。这些需求旨在形成与涉众的初始讨论和协议的基础，并支持对定义体系结构的即将完成的任务的划分。创建了九个额外的、更详细的需求文档，以充实顶层需求中引用的细节。详细文档涉及的其他主题包括语言、业务规则、主机消息传递、日志记录、门户服务和系统管理。

BigFinancial的一名地区技术领导者报告称，由于JBT的应用基础更大，而且可以很容易地向其添加应用，因此它比传统产品更容易集成。值得注意的是，他指出JBT的设计考虑了从以前的产品中吸取的教训，包括性能、稳定性和总拥有成本的改进。这导致了“企业、技术集团和客户的双赢”。

从经济角度来看，BigFinancial表明，相对于新开发的成本，首次业务单元实现已经部署到其他业务单元的产品平均节省了20%到40%的成本。此外，对一组业务单元进行更新版本的后续部署所节省的成本，与为每个业务单元独立维护软件的成本相比，节省了50% - 75%的成本。

所有核心银行功能都由一个全局应用程序集支持。在某些情况下，仍然存在只有特定企业或地区才需要的功能。JBT体系结构允许区域技术单位根据需要开发那些特定于区域的应用程序。中显示了JBT体系结构的概述图1．

BTC基于分层架构原理实现了JBT，¹²关注互操作性和模块化。例如，应用程序组件只与页面的应用程序主体部分交互;导航和标记的所有其他元素都由公共服务和门户服务元素处理。此外，事务性消息传递通过消息抽象层与应用程序隔离，以便在必要时在每个区域使用惟一的消息传递模型。

JBT包括一系列银行功能的基础设施和应用程序组件。基础设施和应用程序组件被定义为独立可更改的版本，但目前被打包为一个组，以简化部署过程。

项目的资金和治理通过BTC进行协调，业务部门也有很大的参与。业务部门有机会选择其他供应商来满足他们的技术需求，尽管随着JBT项目获得更广泛的推广地位，公司的技术战略限制了这种选择。业务部门参与每半年一次的现场规划工作，以评估增强请求并优先考虑新业务部署。

回到顶部

结果

作者总共研究了六个不同的软件重用案例。其中三个是Java Banking Toolkit (JBT) Internet银行、门户服务和警报以及JBT平台本身的重用的子案例。其他的是Worldwide SSO产品和BigFinancial Message Switch。有各种各样的重用成功级别，以及各种各样的预期支持和重用障碍的证据级别。结果的范围用二维图表示，如下所示图2．

BigFinancial以一种非常实用、直接的方式衡量其重用的成功。BigFinancial不是衡量重用的模块、代码行或功能点，而是简单地衡量兼容代码集的总体部署。由于不断的增强，代码库会随着时间的推移而不断演进，但会以向后兼容的方式演进，因此可以根据业务需要随时将旧版本升级到最新版本。

比特币没有明确地捕捉成本节约的硬性经济指标。但是，他们对节省费用范围的估计载于图3．由于将业务单元需求映射到全球产品功能所需的大量工作，以及业务规则的培训、开发和测试的成本，以及操作流程的增加，新部署节省的成本更小。相比之下，持续维护节省的费用通常更大，这是由于许多业务单元的代码库的共通性。这种共性使错误修复、安全补丁和其他维护活动可以在一个代码库上执行，而不是针对每个业务单元执行一个代码库。

BigFinancial已经证明，对于大型组织来说，构建供其内部使用的软件是有可能超越更常见的软件重用模型的。通过这样做，BigFinancial在其多个业务部门实现了显著的规模经济，并缩短了其新产品部署的上市时间。

许多因素对重用项目的成功至关重要。这些包括来自更传统的重用文献的元素，包括组织结构、技术基础和经济因素。此外，还确定了几个新元素。这包括信任和文化的概念，大粒度和细粒度重用成功的跟踪记录的概念，以及公司指令的良性(和潜在的恶性)循环。相反，组织障碍被证明是成功重用的最大障碍。¹³

在多年的时间里，BTC采取了具体的步骤来创建和加强其重用文化。在众多的产品线中，强烈鼓励重用组件和基础设施包。大粒度元素的重用是下一个逻辑步骤，它处理单个区域组织中的一组业务单元。这支持必要的业务对齐，以支持大粒度的重用。此外，由于其为BigFinancial提供全球技术的地位，BTC能够利用其跨业务单元的需求知识，并明确地设计易于重用的产品，以及驱动需求的共通性，以支持重用。

在与重用相关的技术因素方面，BTC的结果提供了关于在实际重用环境中使用各种技术和模式的经验证据。其中一些技术和模式是平台独立的接口、业务规则结构、跨软件层的严格隔离关注点，以及允许组件分阶段迁移到更新接口的接口版本控制。在其他技术中，这些技术通常被认为是设计系统的良好体系结构方法，并且已经被更仔细地检查了它们对重用活动成功的贡献。在此研究中，发现它们对大粒度重用项目成功所需的技术元素有很大贡献。

产品供应商，特别是应用程序服务提供商，经常进行这种类型的开发和重用，尽管动机不同。(应用程序服务提供者现在通常被称为软件即服务的提供者。)作为商业供应商，他们更有可能是市场驱动的，经常销售专业服务的定制。相比之下，大金融的动机似乎更旨在实现功能、上市时间和成本的最佳组合。

这项研究提供了一个机会，深入研究在BigFinancial的三个项目和三个子项目中实践的各种形式的重用。这些形式包括设计重用、代码重用、模式重用和测试用例重用。作者根据参与者的文档和报告发现，系统的、细粒度重用的积极实践有助于在更大粒度级别上成功重用系统。

这项研究提供了管理结构和领导风格的观点，并提供了一个机会来检查它们是如何促成或阻碍成功重用的。在BigFinancial/BTC上，关于IT治理和支持各种情况下重用的组织结构已经有了很多内容。BTC和BigFinancial的领导都被认为对重用工作的成功做出了贡献，甚至被认为是启动一个打算完成这种大粒度重用的项目的先决条件。

Sabherwal¹¹注意到外包IS关系中信任的重要性，项目的参与者在项目之前可能不认识彼此，并且可能只在一个项目中一起工作。因此，在这种环境中建立和维持信任是至关重要的。这并不完全适用于BTC，因为它是其客户的技术集团的同行组织，其成员通常与他们的同行有长期的关系。Ring和Van de Ven研究了更广泛的合作组织间关系(IOR)的概念，并注意到信任是IOR的基本组成部分。信任被用来减轻关系中固有的风险，在个人和组织层面上，它本身被法律或组织系统的潜在压倒力量所减轻。¹⁰这一元素似乎确实适用于BTC的环境，因为据报道，信任是将JBT的创建转让给BTC的基础。

Griss指出，文化是组织结构中阻碍重用的一个因素。一个担心失去创造力、缺乏信任或不知道如何有效重用软件的文化，将不会像一个没有这些障碍的组织那样成功。⁴反之，关注并含蓄地欢迎重用的文化可能会更成功，这也是合理的。BTC在重用方面的悠久历史，对更传统的重用缺乏明确的激励和衡量标准，以及它作为业务合作伙伴的全球技术供应商的地位，都可能使其文化成为重用成功的有力支持者。

其他一些研究人员已经评论了组织文化对重用的影响。Morisio等⁸顺便提及文化因素，主要是作为重用的潜在抑制因素。卡和卡莫1检查四个有助于重用采用的文化方面:培训、激励、度量和管理。此外，Card and Comer的作品主要关注文化障碍，以及如何克服这些障碍。然而，在BTC的案例中，重用存在着根深蒂固的文化偏见，例如，不再需要激励来促进重用。

该研究的一个关键参与者提出了关于细粒度重用与粗粒度重用的强烈意见。JBT的首席架构师明确而强烈地反对一个倾向于在细粒度级别上对对象和组件进行细粒度重用的重用定义。这个人的观点是，虽然在这个粒度上的重用是可能的(实际上，BTC在这个级别上证明了成功)，但在分布式开发项目中，细粒度的重用是很难实现的。首席架构师进一步认为，它提供的影响远不如大粒度重用程序带来的影响大。这样，这种大粒度组件的集成商就可以更加确信组件已经在类似的环境中使用、在适当的负载下进行了测试，等等，从而减少了为一个领域构建的细粒度组件可能在新的领域或新的规模中被误用，并在该环境中失败的风险。

虽然BTC的JBT产品在某种程度上是软件产品线的一部分(支持它的三个主要应用程序)，但JBT真正的重用并不是以从一组通用核心资产开发更多实例的形式出现的。相反，看起来JBT本身是被完整地重用的，以一种高度可配置的方式支持每个不同业务的需求。

组织障碍似乎(至少在一定程度上)导致了大金融信息开关(BigFinancial Message Switch)的缺乏广泛部署。Gallivan^3.定义了技术创新同化和采用的模式，其中包括即使面对管理指令，一些员工和组织可能不会采用和吸收特定的技术或创新的概念。这一概念可能部分解释了BMS的结果，一些业务部门和技术集团可能以各种理由(包括业务案例)抵制引入BMS，即使全球指导委员会决定继续部署BMS。

我们以前注意到组织间障碍对重用采用的负面影响，特别是在BMS的情况下。这一点在创建BMS并在很大程度上负责向其他业务部门“销售”BMS的组织中尤为明显，该组织的定位是区域性的，而不是全球性的技术水平。该组织的位置，以及该组织在全球可重用产品方面更有限的经验，可能导致了实现该产品更广泛重用的困难。

回到顶部