简介： 随着应用软件复杂度的不断提高，软件架构越来越重要，好的架构可以增强系统的可用性、适应变化的能力以及健壮性。而参考架构（Reference Architecture）是一组有关架构方面的最佳实践经验的集合，合理借鉴参考架构可以统一开发中心各个团队的架构设计原则和思想，避免架构不统一带来的混乱，有利于开发适应当前发展趋势和未来变化的更为“智慧”的架构。本文分析了银行软件开发中心采用智慧的软件技术架构——基于 SOA 参考架构的软件架构的问题。

3. 智慧软件开发中心参考框架

在上一章重点讨论了在建设智慧软件开发中心过程中哪些应用软件技术、架构方法以及最佳实践、工具及平台可以帮助建立智慧的工艺路线、智慧的工艺路线，从而提高人的效率、架构的灵活度和适应变化的能力、以更加智慧的方式从事软件的交付。此外离开了企业级的治理和规划也会使上面的智慧效果大打折扣。综合上面的考虑，在融合了 IBM CBM（业务组件模型）、EA（企业架构方法论）、CMMI 以及 IBM SOA 参考架构后，我觉得可以用下面的参考框架来指导智慧开发中心的整体建设。

3.1 框架概述

图 1. 智慧软件开发中心参考框架

图 1 大图

上面的参考框架可以大体分为战略规划、中心控制以及战术执行层三个层次。战略规划层主要用于指导整个开发中心在工艺流程以及架构本身方面的总体方向、政策、规范及流程；战术控制层主要在于监督、监控和进行战术级决策；而战术执行层则侧重具体的执行，其中又分为软件交付工艺路线（即 ALM）的执行以及技术架构本身的执行。从 CMMI 角度看，战术执行层覆盖了 CMMI 2-3 级绝大部分内容，而中心控制层的量化管理平台则正是通往 CMMI 4 级的必经之路，战术执行层的资产管理平台以及战略规划层构成了软件开发中心基于经验达成自反馈、持续改进即 CMMI 5 级的基础。下面分若干章节分别对上面框架中的关键构成以及周边关系进行论述。

软件开发中心如何进行软件开发管理？如何进行技术架构设计？如何利用已有的技术平台或资产支持一个新应用开发？作为一个应用或项目的软件架构师，他的职责和交付件是什么？开发中心完成集成测试的标志是什么？什么样的应用应该使用企业服务总线？我们 JAVA 程序的规范是什么？……作为一个银行软件开发中心，特别是大型银行开发中心实际上每天都会面对大量诸如此类的问题，这些归根结底是统一的开发中心流程、方法框架以及规范应该解决的问题。和多家银行开发中心接触发现实际上多多少少各家银行不同程度均实现了一些统一的规范、方法和流程，但这些均比较零碎，缺乏规范的形式和后续维护机制，也缺乏工具和平台方面的支持。

实际上 IBM 自身也经历了上面的发展过程，也存在着大量的方法、流程、最佳实践等，不同部门使用不同的流程来指导本部门的具体实践，这为不同部门协作工作带来了不少麻烦，需要不少映射工作，例如术语方面的映射、交付件的映射等。近年来 IBM 对自身的多种方法、流程进行了归纳、总结和统一，形成了统一的方法框架（Unified Method Framework），并基于 IBM 方法创作发布工具 Rational Method Composer 设立了一整套统一的流程、方法创作、重用以及发布机制。下图是一个已发布的 IBM 实践方法网站（由 IBM Rational Method Composer 生成）。

图 2. IBM 实践方法网站示例

图 2 大图

在 UMF 帮助下 IBM 不仅统一了各类交付实践、方法和流程，而且各个部门的不同团队可以根据自身需要从 UMF 中选取已有的方法片段（Capacity Pattern 或 Delivery Process），经过定制后形成适合自己的方法和流程。因此 UMF 也是一个模块化的方法框架，通过 RMC 可以方便地进行编辑、剪裁和定制，然后发布到项目管理工具或形成 Web 网页。

IBM 自身的实践可以给银行开发中心许多借鉴，银行开发中心完全可以将分散在不同地方的文档加以总结，利用 RMC 提供的模块化方法机制进行统一，例如角色、活动、工件、流程、规范、模板、指导等，如下图所示。

图 3. 利用 RMC 提供的模块化方法机制进行统一文档

图 3 大图

通过上面的系统总结形成的适于本银行特点的方法和流程是一笔巨大的宝库，一方面可以指导中心控制层的监控和决策（如在哪些单元测试指标达到后才能进入集成测试阶段），也可以指导战术执行层的各类具体活动（如使用 SOMA 方法指导整个技术架构的设计和实施，使用需求管理实践指导 ALM 中的需求管理），可以沉淀到资产管理平台中形成方法类资产，同时也可以从资产管理平台导入其他可借鉴的第三方方法和最佳实践（例如 IBM DeveloperWorks 上有不少方法插件可供下载），逐步丰富本行的方法和流程框架。

企业架构项目旨在建立一套灵活高效的 IT 架构，帮助银行在未来的技术决策中提供更科学的决策依据。EA 的工作内容包括了银行业务架构、应用架构、IT 基础架构、集成架构、安全架构等现状梳理和未来架构描述，目的在于通过现状和未来应用的差异分析，定义实施项目群和实施项目，确立项目优先级和实施路线图等。同时，EA 可以用来帮助制定企业架构治理框架，包括企业架构治理目标、组织、流程等，据此可以提出架构治理转型计划。

EA 可以用来指导中心控制层中项目和项目组合管理（例如今后三年项目及项目群的计划）、量化管理平台以及战术执行层中的具体技术架构实施。EA 本身也是企业的一笔巨大财富，同样需要沉积在资产管理平台的架构资产中。EA 中的大量架构特别是应用架构、业务组件模型、数据和信息架构等可以作为模型驱动开发的基础之一。

EA 和统一开发流程及规范构成了整个开发中心的战略规划层，可以指导整个银行开发中心开发工艺路线和架构方方面面的问题。这里需要注意 EA 并不是一成不变的，EA 也需要随着企业的发展变化而逐步演进。

银行开发中心的项目办或者 PMO（Project Management Office）肩负着整个开发中心所有项目的立项、执行、跟踪和报告。就象机场控制塔控制每架飞机的起降一样控制着各个项目 / 项目群的生命周期。如前所述银行业务系统具有“公共汽车式”的发布特点，每个上线版本就是一个大型项目群，每个上线版本中的需求就形成了一个个项目群中的项目，由于银行系统之间错综复杂的关系决定了除了同一项目的 WBS 依赖关系之外，不同项目群之间、同一项目群的项目之间均存在着相关关系。除工作计划以外，项目与项目组合管理平台还担当着人力资源管理（项目人员调配）、项目问题及风险管理、工时甚至项目财务管理等。通过项目与项目组合管理平台开发中心可以从宏观掌控所有项目的执行情况，包括预算执行情况、工期是否拖延、资源是否充分等多方面信息。

战略规划层中的统一流程组件可以直接导入项目工作模板给项目与项目组合管理平台， EA 的后续项目及项目群规划也可以导入到项目管理平台中。应用生命周期管理平台中的诸多信息（例如重大需求变更、缺陷等）也可以根据要求同步到项目及项目群管理平台中进行高层展现和控制。一些经典的项目模板经总结后可以导入资产管理平台作为项目资产进行重用。

量化管理平台的作用是对整个软件开发过程进行监控和度量，其核心是如何根据业务目标、运作目标建立实用的度量体系。有效的度量可以帮助软件开发中心：

• 更有效的沟通

度量可以为整个软件中心提供明确的目标信息，例如进入集成测试阶段的缺陷必须在总缺陷数的 5% 以内等。可以帮助减少软件开发中的许多不明确性，帮助中心领导层在整个中心上下来发现和跟踪问题，并合理安排问题解决的优先次序。

• 跟踪具体项目目标

度量可以准确描述软件项目的状态，包括进度状态以及质量状态，因此度量可以帮助回答如“项目是否按进度在进行？”，“当前质量水平是否可以交付给客户？”的问题。

• 尽早发现和校正问题

度量可以尽早发现项目中的问题，有利于建立一种主动管理策略，避免后期校正付出的更高成本。

• 做出更为全面的决策

软件开发过程中经常受制于各种约束，包括成本、进度、质量、技能、人员等，开发过程经常是各类因素相互折衷的过程，因一种因素而产生的决策经常会对其他方面产生影响，度量可以帮助领导更好地评估各方面的影响，做出更为全面的决策。

从软件实现技术上看量化管理平台同数据仓库的构造及使用方式非常类似，来自 ALM 平台、项目管理平台、资产管理平台等各方面的数据按要求抽取到一起，按照预先创建的数据模型进行存储，构成基础度量数据。很多情况下多个基础度量指标可以导出更接近最终统计指标的导出度量数据，例如根据缺陷数目和代码行数可以导出每千行缺陷数。更多的统计指标则基于基础度量数据和导出度量数据，经过一定的公式计算得出最后的统计指标。量化管理平台本身的最佳实践、方法和流程、量化统计公式、各类度量指标、基础度量数据以及导出度量数据都可以在战略规划层的统一流程规范中进行具体定义。

以往量化分析能力大多分散在各个管理平台中，例如需求管理、测试管理、配置管理、项目管理等都有自己的度量指标，各类产品也分别实现了各自的指标体系。但随着端到端 ALM 体系的建设，需要更多的度量指标，也需要一个综合划一的量化管理平台从而以类似数据仓库的形式对各类软件开发过程信息进行加工，以 Web 页面方式在全中心进行展现和发布，进而形成各种报告。

很显然，量化管理平台是不可能一步到位的，必须分期循序渐进来进行建设。比如在一期建设过程中列出领导最需要的指标，然后分析如何导出或计算出这些指标，都需要哪些度量，以此推导出是否数据源具备提供基础度量数据的能力，由此得出如何对其他平台进行改进，因此量化管理平台很可能和 ALM 以及其他平台的建设同时开展。

应用生命周期管理 ALM 是整个银行开发中心的核心工艺路线，这一点已经在前一章中进行了详细描述，这里对其和框架中的其他组件关系做一简单描述。

由于 ALM 持有开发中心所有开发人员活动级、模型级以及代码级的大量基础信息，这些信息一方面可以提供给中心控制层的项目与项目组合管理平台进行分析和高层展现，另一方面可以提供给中心控制层的量化管理平台进行更为系统的数据抽取、分类汇总和分析，及时量化地把握开发中心的现状和能力。战术执行层的技术架构部分包含一系列的方法、架构模型这些都可以基于 ALM 的过程域（如需求管理、分析设计及开发等）进行分析、设计和实施。ALM 中形成的大量资产可以经提炼后记入资产管理平台进行共享和复用。

SOA 参考架构中的诸多构造块的实现向上受到战略规划层的指导，如 SOMA 方法论、企业架构 EA（关于企业架构 EA 和 SOA 参考架构的关系可见参考文献 11）等；而 SOA 整个架构的落实会依赖于 ALM 平台中各个过程域及平台的紧密支持，如业务流程建模、组件模型、服务模型等；向下同样会在资产管理平台进行资产沉淀。

资产管理平台也可以看作开发中心的知识库，从框架的周边关系看各个层面各个类型的可重用资产只要有共享的要求都可以通过资产审批流程进入资产管理平台。有效利用资产可以大大加快软件交付速度，同时提高软件交付质量。另外，资产管理平台自身的方法和流程也受到战略层中统一方法流程的指导，资产管理平台中的大量信息也可以回馈到控制层的量化管理平台（如资产分类统计、共享情况统计、资产在各开发中心分布情况等）以及项目管理平台中。

资产管理平台中的资产形式可能是多样的，因此其使用方式也会有所不同，比如服务（Service）、模式（Pattern）、代码审查使用的规则、模型驱动开发中模型转换用到的代码模板等。可以在资产管理平台进行管理的同时以最适当的方式将这些资产融合在具体工具平台中。例如服务和模式可以以插件形式出现在开发环境中，代码审查规则可以以插件形式落实在代码审查工具里，模型转换的代码模板可以以插件形式体现到模型驱动开发工具平台上。

3.2 框架部署模式

上面所涉及的框架如何在银行开发中心部署呢？这涉及到一系列因素， 但其中最重要的是开发中心各职能部门人员和上面的框架中各支持组件的位置关系，也就是开发中心的地域分布状况。如果银行只有一个开发中心，建议进行简单集中部署即可，这样各类中心人员都可以进行本地访问。比较复杂的一个因素是多点分布的开发中心布局。

开发基地多点分布的方式也称之为地域分布开发（GDD，Geographically Distributed Development），最早见于跨国软件公司为了统一开发流程、控制成本、增加灵活性、达成 24 小时不间断开发而提出的。随着软件中心规模的扩大，地域分布的多开发中心方式已广为采用，随着国内银行逐渐走出去的趋势，对国外银行的合并、收购和整合也势必涉及地域分布的开发。目前国内多家银行均拥有多个开发基地，各个基地基本以业务线或应用类型进行划分，每个开发基地包含自己的总工办 / 架构办、开发部、测试部、项目办等，银行业务系统版本的发布会涉及多个开发中心的共同协作。以下是国内软件开发中心的组织生态图。

图 4. 软件开发中心的组织生态图

从上图可以看出地域分布的开发中心出现一定会增加信息科技部和多个开发中心，多个开发中心之间的沟通，因此有必要进一步加强软件开发管理平台的组织和建设，例如统一的需求管理平台、变更管理平台、项目管理平台等。同时由于多个开发中心相距遥远，在考虑具体平台和流程建设上一定要综合考虑开发管理平台与开发环境的集成、性能和访问效率、中心间协作关系、服务器部署方式等。为了更好地进行沟通，一个比较理想的部署方式是将相关服务器集中部署到某一地点（如数据中心），各个开发中心均统一访问该点，形成星状连接方式。但前提是网络及平台性能满足各中心集中访问的要求。因此一个推荐建议是能集中则集中，不能集中则采用“区域自治＋复制同步”方式：

• 战略规划层——开发中心统一开发流程及规范

集中部署，包括流程及规范的编写、维护和发布。建议以 Web 方式为主，各中心团队在进行中心规范及流程使用时，除了浏览中心标准流程和规范、下载标准模板等任务以外，在需要对标准进行定制为本中心所用时，可以从 Web 上进行下载，然后在本中心进行定制和发布。

• 战略规划层——企业架构 EA

集中部署，其维护工作由专门的架构团队和总工办执行，其他中心和团队以只读方式浏览。

• 中心控制层——项目及项目组合管理

集中部署。

• 中心控制层——量化管理平台

通常采用类似数据仓库方式，集中部署但数据来源广泛。

• 战术执行层——ALM

首推集中部署，但个别过程域如配置管理可能涉及大量的代码传输过程，因此如果性能有问题的话也可以采用“区域自治＋复制同步”方式，即建本地配置库，但周期性地本地配置库会复制到某一核心地点供其他中心访问。

这里还需注意一点，即各个过程域之间的紧密集成与否对具体部署模式也会有影响，例如变更管理平台和配置管理平台如果进行了集成，那么两平台之间会涉及较为频繁的通信往来，集中部署在一起效果较好。

• 战术执行层——架构

架构方面的很多工件是以模型或资产形式体现的，因此架构方面的具体支持平台可以依赖配置管理平台以及资产管理平台来支撑。

• 战术执行层——资产管理平台

集中部署。

从总体看，软件开发是一项人工密集型活动，如何创造条件一方面使人少犯错误、少走弯路、少返工，真正实现以人为本；另一方面在更加灵活、快速进行软件交付的同时保证应用软件的应变能力是建设智慧开发中心的关键。下表对本文的一些要点进行了总结。

表 1. 本文要点

智慧的银行开发中心不仅可以以更智慧的方式帮助实现软件开发中心的目标，而且可以影响银行测试中心、数据中心，乃至第三方，特别是厂商，从而促进整个“智慧型”IT 和谐社会的建立。衷心希望本文能对国内银行开发中心的建设以帮助，共建“智慧的星球”。

本文融合了 IBM 技术团队多年为银行开发中心提供咨询服务的工作经验，这里首先感谢我的广大 IBM 同事，特别是软件部的李燕生、郑如彬、姚炳雄等同事，他们长期服务于银行开发中心现场，为本文的形成提供了许多素材。另外 IBM Rational 的许多同事也在成文中给予了很多反馈意见。其次感谢广大长期合作的国内银行客户，许多观点也是和广大银行开发中心的朋友们共同启发、共同合作的结果。

原文链接：http://www.ibm.com/developerworks/cn/rational/r-cn-smartsoftwaredevelopment5/index.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780873/viewspace-673159/，如需转载，请注明出处，否则将追究法律责任。