级别： 初级 Maria Ericsson, IBM Rational Services 首席顾问, IBM
2007 年 4 月 16 日 本文来自于 Rational Edge：您在寻找对组织治理的清晰解释吗？本文介绍了不同层次的治理，以及它们如何影响关键的管理问题，例如生产力和风险。本文还探究了好的治理与软件开发组织将其过程与业务策略结合的能力之间的联系。
为了保持竞争地位，现今全球的商家都需要更高程度的灵活性，并且需要比过去更有效地使用它们的资源。大多数逐渐依赖软件来实现这些需求 —— 在内部业务过程的运作中，以及在用于外部消耗的软件或与软件相关的产品的生产中。
这些要求已经将许多传统的开发团队转换为承担更多责任的软件交付组织。它们不仅要开发并维护应用程序，还要评估、获取，并将软件产品和服务集成到复杂的系统中，经常要满足严格的质量和法规的需求。换句话说，开发组织交付解决方案，对于这些解决方案的过程集合可能包括开发、获取、维护，对用户群体的传递，以及与操作的集成，以及交付过程。
这些活动覆盖组织中大范围的职能，并且需要带有有效治理的强壮的业务过程 —— 清楚的责任、权限，及通信链，以及确保这些链的量度、策略和控制机制。治理是在组织功能中获取业务过程和资产的控制的关键。良好的治理实践的目的是双重的： 1) 从战略上将所有的资源与整个业务策略结合起来，2) 在组织的运作和投资中管理风险。
已经设立了良好治理实践的开发组织有能力进行转型，并且意识到他们在业务中所贡献的价值。与其作为业务的提供商（也就是，根据来自业务的需求构建产品），这些组织倒不如成为必要的业务伙伴，共享同样的策略和价值，并且协作改进内部过程并获取新的业务。本质上，管理层将这些开发组织看作价值中心，而不是成本中心。
本文着重于影响开发组织的治理视角，IBM Rational 组织将其技术和服务产品投入到该领域。这些产品包括：
-
帮助管理全球化的开发和交付的解决方案。分布式的开发不仅是全球化的结果，而且还是寻找有效的利用技能和资源的结果，不论这些资源处于什么地理位置。
-
帮助实现对法规遵从和风险管理的解决方案。法律和规章越来越具体，不符合法律法规的代价是非常昂贵的。
-
帮助管理模块化且灵活的架构的解决方案。举例来说，面向服务的体系架构需要具体的治理和鼓励使用这个架构的生命周期管理机制。
我还将探讨 IBM Rational 如何扩展其覆盖面，从而帮助客户更好地管理软件和系统交付的其他关键方面。
另外，本文将涉及项目组合管理治理问题 —— 需要在业务创新所必须的更高风险的工作，与维护现有系统和产品所需的较低风险的投资之间权衡利弊。对于大多数公司来说，所面临的挑战是更有效地管理后者，为生成更多价值并帮助企业保持竞争地位的创新项目释放资源。
什么是治理？
现今的公司日益依赖软件来运行它们的业务过程。另外，许多公司为客户消耗提供软件，或者将软件并入它们的产品中。为了确保它们所依赖的软件是可靠且有效的，公司需要管理其用于采购、创建和部署的业务过程。像所有重要的企业资产一样 —— 实际库存或部门的业务知识资产，例如 —— 软件及软件相关的资产，必须小心地管理，目的是使这些资产对企业的价值最大化，同时要减少风险。
治理的公共行业定义包括以下两个部分：
- 在组织结构中对某人进行授权的职责、权限和通信链（治理的静态或结构组件）。
- 使人们贯彻其组织角色和职责的量度、策略及控制机制（治理的动态或量度组件）。
治理不同于管理。它决定谁有权限做出决策。而管理活动应该确保日复一日地贯彻组织的治理方法。
良好的治理不包含抑制创造性的束缚和业务控制。虽然是基于可重复的方法，但是良好的治理应该为企业精神、质量成就和有效执行提供环境。为了得到从业人员的接受，治理方法必须拥有可证明的价值。员工必须理解，这些方法会令他们的组织更加有效且高产。
好的治理是以价值为重点的。它帮助企业实现其目标，并且获得业务利益。通过启用有效的度量和控制，并且促进良好的沟通，它还帮助减轻风险并提高团队效率。治理得糟糕的组织经常陷入关注过程而不是结果的圈套。它们只根据度量提供刺激，忽略了策略目标和实际结果。
治理的主要目标是确保组织的业务过程，以及公司的策略业务需求的结果。另一个重要的目标是减少关于组织的运作和投资的风险程度。
令治理可操作意味着设立明显去除风险的方法和控制 —— 提供对正确决策做出的恰当理解。这典型地需要组织的变更工作，这不可能在一夜完成。治理被增量地依照带有明确里程碑和可度量的结果的路标实现。同样重要的是，在实现的道路上停下来根据经验教训调整路线。
治理视角
有很多种治理视角，就像企业中有很多职责一样。在本文中，我将讨论与那些与开发视角特别相关的视角：
如图 1 所示，虽然这些治理视角不共享相同的抽象层次，但是它们都是密切相关的。
企业治理最完整的视角。IT 治理是企业治理的子集。产品开发治理也是企业治理的子集，且是 IT 治理的兄弟，它们有许多相似性和重叠。IT 治理与开发产品的组织（除了开发 IT 系统之外）是相关的，例如汽车和电子行业中的。开发治理是 IT 治理和产品开发治理的子集。IBM Rational 在该规程方面有很多经验，这是 Rational 产品和服务的长远目标。
虽然人们可能期望开发治理在 IT 领域与产品开发领域看起来一样，但它不是。出于历史的原因，在着重点、优先级，甚至术语都不同。
图 1：治理视角
随着开发组织的成熟，这两个视角之间出现了更多交叉（参见图 2）。IT 组织开始将其资产作为产品处理，而产品开发组织对业务更加重视。在 IBM Rational 中，我们已经开始利用术语软件 & 系统交付治理来概括这两个孪生视角。然而，在本文中，我将继续使用更熟知的术语，开发治理来说明 Rational 最深远的经验领域。
图 2：软件 & 系统交付治理。
在成熟的组织中，所有这些视角都紧密结合在一起，如果没有有效的并且在战略上结合 IT 治理和/或产品开发治理，那么您不可能拥有很好的企业治理。
企业治理
这一层的治理是企业的会计师和执行者关心最多的。Information Systems Audit and Control Foundation 将其定义为：
...一组职责和实践，由董事会和执行管理层履行，以提供战略方向为目的，确保目标的达成，查明风险得到了适当的管理，并且验证组织的资源得到了有责任地使用。
企业治理的两个维度 —— 一致性和性能 —— 需要平衡。
- 遵从性维度也称作“法人治理”。它包括一些问题，例如董事会结构、角色及职责，特别是在执行层的。它也许还围绕对代码和/或标准的遵从，举例来说，审查许多组织都违反了 2002 Sarbanes-Oxley Act 的法规框架。然而，一致性和对法规的遵从性是不同义的。对法规的遵从性需要具体的文件证明决策是如何执行的。
- 企业治理的性能维度着重于策略和价值的创建。该维度不能简单的被借用于标准和审查的制度。相反，组织定义价值，并确定在组织的各个层上如何度量并监控该价值。
企业安全策略可能作为一致性维度的一部分，但安全性常常是一个复杂的文化问题。许多公司选择限制有关如何制定决策以及所依据的方法是什么的信息，这样的策略限制了治理策略实现的方式。如果由于安全策略，不能公开特定的治理方法的话，那么局外人可能会感觉根据那些方法所制定的决策缺乏理论基础或似乎是危险的。
只有很好的法人治理是不能令公司成功的。企业必须总是在一致性与性能之间权衡利弊 —— 并且让安全性提供边界条件。
要了解更多关于企业治理的背景信息，请参见[9]。
IT 治理
IT 治理与组织的信息技术过程及其支持业务目标的方式相关联。如图 3 所示，IT 治理全景可以分为若干领域，表示 IT 组织种各种各样的职责。我们将这些领域称作治理规程。
IBM Rational 解决方案利用项目及项目组合管理，及过程工具和经验，在 IT 策略治理和 IT 投资组合治理规程上支持客户。结合了 Tivoli 后，我们还提供对运作治理以及风险和法律遵从治理的支持。
图 3：IT 治理全景
许多 IT 组织使用标准治理框架来分配决策权，并设立过程方法。其中最流行的是 ITIL 和 CobiT。
- IT Infrastructure Library (ITIL) 是全球公认的且不断演进的 IT 最佳实践的集合，它能够帮助组织克服当前和未来的技术难题。ITIL 主要是关于执行的，它将控制作为其活动。全球的 IT 部门将 ITIL 作为帮助指导当前技术的高效且有效实现的路标，包括 IT 服务管理策略的实现。要了解更多信息，参见 ITIL 的官方网站：http://www.itil.co.uk/
- 另一个广泛应用的是 Control Objectives for Information and related Technology (CobiT) 的 IT Governance Institute (ITGI) 版本 4.0。CobiT 是一个 IT 治理框架及支持工具集，它令管理人员跨越了控制需求、技术问题，及业务风险之间的鸿沟。要了解更多关于 CobiT 的信息，请参见 http://www.isaca.org/cobit。
IBM® Tivoli® Unified Process (ITUP) 与 ITIL 紧密地结合在一起。要了解更多信息，请参见 http://www.ibm.com/software/tivoli/features/it-serv-mgmt/itup/index.html。
产品开发治理
产品开发治理是 IT 治理的兄弟，它是用于开发产品的组织（举例来说，手机或飞机）而不是内部使用的 IT 系统（举例来说，自动的工资管理系统）。从抽象的角度看，IT 和产品开发治理是相似的 —— 但由于它们的历史和开发及部署技术的差别，在实践上就存在差别。举例来说，产品开发治理将实践围绕着产品策略、产品生命周期管理，和产品销售（参见图 4）。
当涉及到管理开发及交付过程的经济学时，产品开发治理和 IT 治理有共同点。对于软件密集的产品，就同样需要着重于管理项目的风险曲线，并确保活动着重于向组织和最终客户交付价值。
图 4：产品开发治理全景
开发治理
开发治理是一种治理规程，IBM Rational 在这方面拥有很多的经验、广泛的产品及服务供应，以及长期的成功经历。开发治理应用于开发组织，以及它们用于管理开发程序的业务过程。良好的开发治理意味着：
- 在组织中，对于应用程序/产品、对于应用程序/产品的整个投资组合，以及对于应用程序/产品所依据的架构，明确定义的所有权。
- 全组织的度量程序，其目的是在开发过程上推动一致的进展评估，以及推动一致的控制机制的使用。
好的开发治理实践能够让组织决定开发投资对其预期值的交付程度。该期望总是处于风险中，根据项目特性，风险的程度各不相同。要解决的问题有多知名？您以前做过类似的事情吗？诸如此类。图 5 展示了与项目投资组合相关的风险曲线的表示。
- 在风险曲线的底端是处理与维护或交付相关的问题的项目。解决方案的开发过程通常是事务性的，而且结果是相对可预测的。开发治理实践和过程改进工作着重于 成本效率。
- 引入新技术、平台或一般不知名的东西的项目将落入仍现曲线的中间。由于要解决的问题更加复杂了，因此对应用程序/产品架构和项目管理的关注更大了。开发过程仍旧可以表现为事务性的，但是结果不再像前一类中的项目那样可预测了。过程改进工作和治理实践的典型目标是创建考虑到开发和交付过程的敏捷执行的环境。迭代开发技术对于避免在不能解决的问题上浪费资源这件事很重要。
- 探究创新概念的项目是最危险的。然而，它们也最有可能给企业带来竞争力。这些是为企业的未来创建新选择的重要投资。
图 5：各种项目类型的风险程度（可能的评估变化）
如果企业想要保持其竞争地位，它必须沿着曲线的三个部分经营其项目。为了生存，低风险的项目是必要的，中度风险的项目令企业适应并利用变更的技术，高风险的项目是成长所需的。
沿着该曲线绘制单个项目也可以帮助组织了解，在项目执行过程中风险是如何变更的 —— 因为项目体征在交付生命周期中经历变更。治理有道的软件交付组织和交付程序以此方式跟踪它们的项目，并且它们了解如何处理不同程度的风险。
不论从组织角度或项目角度看，使用治理实践来管理风险，需要知道谁制定决策，以及职责在哪？否则投资将承担其自身的命运，并且脱开与企业目标和策略的结合。治理还意味着适当地采取手段追踪结果，而当结果并不是预期的，那么就限制投资。
要更深入地讨论变更及所应用的风险分析，请参考[4] 和 [10]。
治理的起点
组织出于许多原因开始引入更好的治理实践。我只讨论它们当中的一些。IBM 和 IBM Rational 经常支持构建面向服务的体系结构（Service-Oriented Architecture，SOA）、对法规遵从的 IT 支持，或对地理分布开发（Geographically Distributed Development，GDD）的解决方案，而我们也对那些领域提供治理支持。下面我还将讨论用于组织的治理实践，这些实践从更全局的角度出发，针对开发组织的转型，使组织的IT 过程更加有效。
SOA 治理
SOA 治理是 IT 治理的扩展，它特别关注组织的面向服务体系结构中的服务、元数据和复合应用程序的生命周期。
SOA 治理包括为那些执行 SOA 过程并在架构中维护并使用服务的人设置决策权及方法。举例来说，必须清楚的是谁“拥有”每个服务并且对服务应该如何演进做出决策。同样，对于每个项目来说，必须清楚的是谁决定是否使用服务 —— 以及它们应该使用的标准是什么。许多面向服务的体系结构没有得到充分利用，因为产品开发/IT 组织没有采用恰当的方法，并且没有阐明指导雇员充分利用架构的决策权。
针对遵从性的治理
对于法规遵从性的治理是企业治理的扩展。法规遵从性包括编制文档并证明所执行的治理方法增强了特殊的法规框架：确保编制并贯彻了与框架相关的决策。许多公司必须遵守 Sarbanes-Oxley 法规，但它们还要遵守具体领域的标准 —— 例如，制药行业的 21-CFR-11，或银行业的 Basel II。
地理分布开发的治理
在全球化的业务环境中，公司想拥有在任何地方、任意时间，开发并交付软件的能力，利用最好的人力资源 —— 不论他们在地理上所处的位置在哪里。这种方式有许多名称：外包、离岸、right-sourcing。要完成这样的工作，公司需要支持跨大洲、时区和文化协作的开发环境，以及定义明确且商定一致的开发实践。治理应该着重于：
- 阐明分布的开发组织中的职责和资产所有权。
- 在分布的开发组织构成中，度量并控制服务级别。
开发组织转型的治理
IBM Rational 的构想是帮助企业将开发组织的内部关注点从成本中心转型为业务价值的生成。这不仅与引入新的最佳实践和工具有关，还与变更态度和文化有关。这要求组织变更围绕来自许多解决方案领域的部分，包括 SOA、顺应性，和地理分布开发。成熟的开发组织为了不断地优化它们向商家提供的价值，会常规地变更其开发实践。
需要良好的治理原则来监督这些组织变更工作 —— 从而确保它们随时间达到其预期的结果。
- 变更计划应该确定为可度量的结果设置期望值的里程碑，或决策点。然后，根据结果，以及减少风险的程度，开发组织可以决定项目是否应该继续，及如何继续。
- 变更计划还应该提供控制对业务过程的破坏程度的控制，并且评价变更的积极影响。这些方法应该集中于最明显的因素：项目成本的可预测性、交付迭代的长度，等等。然而，在计划的较早阶段可以使用更主观的方法，从而评估开发组织中感知到的影响。这些可能包括项目经理或方法的调查，从而确定有多少项目使用了某些新实践。
要了解更多关于开发组织转型的信息，请参考 [8]。
治理的生命周期
治理为那些执行公司过程的人设置决策权、控制机制和方法，然后监控对业务策略或其他规则的一致性。治理也是一个过程，它需要一系列事件来指定权力和方法、控制机制，以及顺应性和有效性监控。在开发组织中，治理过程让管理人员对执行上面介绍的治理规程中的业务过程的结构和严密做出深思熟虑的决策 —— 从而令开发活动与业务策略更好地结合。
如图 6 所示，治理过程有其自身的生命周期，它与需要治理的业务过程的生命周期不同。
图 6：治理的生命周期（如 IBM Rational Unified Process®，RUP® SOA Governance Plug-In）中所示
治理生命周期的目标是使组织的治理实践加强并成熟。虽然根据现有的治理成熟模型来评估您自己的治理模型可能有用，但是没有一个能够完全地反映出软件组织需要的所有东西。CobiT 框架中包含一个成熟模型，该模型允许组织判断，它能有多好地控制 CobiT 规范过程集。然而，由于 CobiT 主要关注控制目标，所以模型不评估其他治理方法和机制。
Forrester Research 推荐有四个阶段的 IT 治理成熟模型：
-
阶段 1：专门的。没有正式的 IT 治理过程可用，而且也不是必要的。
-
阶段 2：分段的。有人试图将 IT 治理过程形式化为组织的部分，但没有企业这样做。
-
阶段 3：一致的。在企业中一致地应用 IT 治理过程。
-
阶段 4：最优化。在企业中优化 IT 治理过程，强大的 IT 投资组合管理过程用于确保目前和未来 IT 投资还是最优的。
结束语
了解与软件相关的治理的本质和目的是实现良好治理的第一步。有了广泛的过程经验，以及在组织转型支持上的长期成功，IBM 提供了强大且全面的平台，帮助客户引入并演进用于软件和系统交付的业务过程的有效治理。后续的文章将详细地探究该平台。
致谢
本文是根据与 IBM Rational Distinguished Engineer Murray Cantor 和 Principal Consultant David Lubanko 的讨论而来，他们做了许多相关的工作。我还从 IBM Rational 专家 Walker Royce、Darrel Rader、John Smith、Mary Ellen McElroy，和 Geoffrey Bessin 那里得到宝贵的意见。
参考文献
注释
[1] Rational Unified Process，SOA Governance Plug-In。
[2] “Governing the Business Process of Software and Systems Development”，Lin Barnett 和 Murray Cantor。IBM 白皮书，发表于 DeveloperWorks。
[3] “Understanding IT Governance: Definitions, Contexts, and Concerns”，Sunita Chulani、Clay Williams 和 Avi Yaeli。2006 年 5 月。IBM 白皮书，发表于 http://domino.research.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/38905eea124cddfb852571fe00569cce?OpenDocument
[4] “估算偏差及管理”，Murray Cantor，2006 年 3 月。文章发表于
Rational Edge
。
[5] “Making Governance Operational”，Murray Cantor，2006 年 10 月。IBM 白皮书。
[6] “评估软件项目的经济价值”，Patrick McKenna，2006 年 2 月。IBM 白皮书，发表于 developerWorks。
[7] “IT Governance Framework”，Craig Symons，2005 年 3 月。Forrester 报告。
[8] “改造你的软件开发能力：一种适应组织变化的框架”，Zoe Eason、Maria Ericsson、Lynn Mueller。2005 年 9 月。文章发表于
Rational Edge
。
[9] “Enterprise Governance: Getting the Balance Right”，Professional Accountants
in Business Committee (PAIB) of IFAC，2004 年 2 月。
[10] Applied Risk Analysis: Moving Beyond Uncertainty in Business，Jonathan Mun，Wiley 2005 年。
参考资料
关于作者  | 
| | Maria Ericsson 是 IBM Rational 的 Strategic Services Organization（SSO）的首席顾问。1990 年她在 Objectory AB 开始致力于软件工程和对象技术领域，并且合著了 Ivar Jacobson 的书籍，The Object Advantage: Business Process Re-engineering with Object Technology。自从于 1995 年加入 Rational 开始，她就作为过程、业务建模，和需求管理的顾问及培训师，并且还花费三年时间，作为 RUP 开发团队的成员。作为 SSO 的一分子，她目前关注解决方案部署策略，并且在 IBM Rational 领域培训团队工作。作为瑞典的居民，她在 Kista 办公室。 |
对本文的评价
| 
