我们需要创建信息系统分级

有害的金融产品之所以大行其道要归咎于法规（尤其如 Sarbanes Oxley 和 Bale 2）的漏洞，具有讽刺意味的是，后者的主要目的却正是减少风险。尽管有人已经注意到这些漏洞，开始着手去制订更多的法规，但应该小心地将表象和原因分离开来：出现现在的情况，相对于金融法规的缺失，缺乏对风险更为准确的度量更为难辞其咎。

新增或修订法规都将于事无补。一旦组织在高度复杂的环境中运营的速度超过其实际能度量的运营速度，可怕的紊乱就会浮现。这种紊乱并不会马上显现，而是慢慢浮现出来，随着组织一起成长。所创造的价值越高，失去控制的可能性就越大。一开始，紊乱还不足以表现出影响运营。但是，发现它越晚，就可能越难采取补救措施。金融系统的崩溃是说明这一现象的绝佳例子。根本问题在于，组织何以如此快的在这么大的层面上失去了对它们运营的控制，而且是在组织毫无察觉的情况下。产品的复杂性和不断增长的执行速度为此次危机提供了沃土。这些产品的模糊程度由支撑它们运营的信息系统的模糊程度决定，这使得想要准确评估和细化风险几乎成为一个不可能任务。然而在今天，任何行动或决策的制订几乎都离不开对某些数据集进行分析。此外，尽管信息系统几乎已经使所有业务流程自动化了，但大多数企业却在承受无法快速变更这些记录系统以满足业务变化的需要和回应竞争压力的痛苦。最终导致的状况是：记录系统没有反映出组织的现状，并且（或者）对于信息系统中捕获的状态，其含义没有达成共识。

在构架拙劣的基础设施上进行的过多战术性修补而引入的偶发复杂性，加之持续缩减的预算，已经对 IT 本身造成了伤害。让应用和技术升级或者甚至于退役都变得不可能，最多不过给它们打补丁，还是在其能修正主要问题的前提下。从心理学角度讲，人们并没有改变现状，但最重要的是，IT 管理从未允许它的员工实施任何形式的深度革新，而且项目很少被界定范围和为获得在整个运营过程中一致的可见性而进行配备。公平地说，过去 15 年，ISV 们很难交付稳定的基础设施和打包应用，来构建可持续的业务解决方案。不象硬件会老化或到达明显的自然极限，软件给人的印象是一种具有诱惑性的永存不灭。我们可能期望像 Google 和 Amazon 这样新的软件提供商能避免过去的错误，如构建可升级的基础设施软件，但这一切并不能被施与。就创建足够高效和一致的透明、可持续业务解决方案而言，每个组织都具有相当的独特性。

问题现在变成了，我们如何才能提高对现状的感知程度？对 CIO 而言，要接受这种现实并不容易。太多的时候，首席信息官成了首席信息系统官。这时候，他就已经不再是那个只关注公司战略的必需角色了。以上这种问题的转变得到了那些经常在业务革新和 IT 之间建立战略联系的行业专家和分析师的普遍支持。然而，实际情况是，IT 被发现是革新的阻力，准确地说，其原因在于 CIO 自满于管理信息系统，而不是信息。CIO 们至少应该去关心如何向业务提高信息系统的透明度。业务和信息之间的这种起码对齐将增加革新能力，同时能够更好理解对于我们社会至关重要的业务运营过程中所涉及的风险。最后，人们必须意识到，人与人之间的沟通已经变得高度依赖信息系统，而且它们所创建的复杂层次是如此复杂，以至于拥有它就会繁荣昌盛，没有它就会衰败灭亡。

说明这一现象的最好例子就是给法国兴业银行带来 70 亿美元损失的交易员 Jerome Kerviel，因为记录系统的访问控制向那些 IT 已决定不履行的实际业务敞开了大门（在这个例子中是区分模拟和现实交易）。可悲的是，它们同样也无法提供合适的可见性来正确报告该银行正面临的风险。

CIO 必须回归其首席信息官的角色，再次关注信息技术；仅仅把心思放在记录系统上是不够的。企业必须从服务业务的角度来要求 IT。为了实现这种转换，人们必须通过促使 IT 资产与业务能力的对齐来把技术和应用的价值摆在核心位置。今天，CIO 们把 IT 当作一组由技术人员操作和管理的应用和数据存储，除了分析工具，它们几乎对业务不透明。CIO 们，因为他们有意识地向一个更具战略性质的角色转移，远离技术，以信息控制者的身份来管理这些系统，但不管理这些系统的价值。这真是一种自相矛盾的说法！CIO 的权责和其要履行的职能不相称。

但是，这种转换有可能通过一种经过多年积累得出的方法论和新技术来实现。当代 CIO 们应该重点管理核心 IT 资产，如主数据、业务规则和业务流程。当前，这些资产往往经常被硬编码到信息系统中，从而导致与当前业务同时需要的灵活性和可见性格格不入的非透明性级别。例如，市场研究公司 Forrester 表示： “大多数企业依旧把流程、规则和报表内嵌到应用中。换句话说，流程图、规则和分析都被硬编码到了各个应用中。当它们和其它应用代码混合在一起时，要找到这些定义更加困难，为了完成变更，需要经过繁重的 QA 工作（业务规则、BPM 和 BI 一起将如何驱动业务的最优化，Forrester Research，Inc.2008 年 5 月）”

这些资产必须向业务开放，并能被业务审计。例如，给定义了访问权限、语义和版本管理规则的治理策略增加了可追溯性同时可以为理解企业的经营风险提供一个坚实的基础。在主数据、业务规则和业务流程被硬编码（而且是手工编码）到信息系统的技术深渊的情况下，我们怎么可能理解这些经营风险？

对管理层而言，IT 是必需品，是一种难得的竞争优势。CIO 驱动的改革所得回报极为有限：IT 管理仅仅被赋予降低成本和保持系统正常运行的职责。当关键经营指标达标且 IT 成本降低，管理层就会表现出满意。当然，业务会由于 IT 缺乏弹性和可见性而受到损害，这一点每个人都意识到了，但随着时间推移，在尝试过那么多新技术之后，这似乎成了不得不接受的现实。大多数组织在这种痛苦环境下日复一日地进行管理，直到重大问题的发生。

自相矛盾的是，大多数 IT 组织收集、处理和上报的信息量要比几十年前多几个数量级。然而今天，组织只能到达一个对其管理一无所知的位置，没有退路，之后就只有崩溃。在过去几年间，大多数跨国公司已经显示这种过程会在未来不超过 12 月内从一个“健康”位置开始发生，原因在于它们中的某些公司无法断定自己在冒险，也无法度量自己业务模型的可持续性，这都要归咎于可见性的缺失。在历史上，投资人可以依靠评级机构，但是今天这种评级只有极少或者根本没有价值，因为它们本身往往就是基于这种不透明的信息得出的。从这个角度讲，为了支持评级机构的评级而增加控制是没用的。提供对于公司经营状况的真正可见性才是关键。这里的关键在于通过定义表示审计信心的度量指标，建立一种信息系统本身的分级。这种分级将评估企业管理其资产价值的能力，即如何管理主数据、业务规则和业务流程。

以高成熟度级别为基础，这些工具和方法已经显示了成功。最重要的是，它们并不要求大爆炸式的方式，而是以一种渐进的方式进行，符合风险管理的计划变更，而且 IT、数据和服务治理也支持。结合这 3 种仓储是决定性的。把它们组合在一起就形成了被称为 ACMS（Agility Chain Management System，敏捷链管理）的强大概念：所有敏捷流程都具有敏捷规则；所有敏捷规则都具有对引用和主数据（图 1）的业务管理。这 3 个中的每一个都将支持高级治理功能，包括版本管理、权限管理、可追溯性管理等。

图 1. 敏捷链管理系统（Agility Chain Management System）

让我们设想这样一个例子：某个企业法规，如 Sarbanes Oxley 或 Solvency II，要求财务报表是可审计的。这意味着公司必须能够显示数据、用于创建报表的计算规则，以及证明数据和规则是正确的的证据。通常在这种情况下，公司可能最多出示纸质的审计记录，其显然无法被 IT 系统利用。而且最糟的是，给 IT 工具的文档过时，只有说明，或者甚至更糟，审计员得分析这些程序代码。并且因为审计员不是 IT 专家，他们无法使用这些资源。在某些情况下，这是可接受的，但是万一审计员不接受怎么办？要是独立 IT 评级机构看起来像是应股东要求进行的 IT 系统评级怎么办？通过访问业务规则和主数据仓储，同一个审计员可以通过仔细察看规则和数据的使用情况轻松地审计财务元素。这是可能实现的，因为这些仓储系统包含了面向业务的 UI，而不是只有面向技术人员的 UI。

这些仓储通常是逐步部署的。企业对遗留系统的修改是通过把一些业务规则移走，在遗留数据库的前端增加一个主数据仓库，同时围绕它们包装一个合适的治理流程完成的。遗留数据库在这一阶段并不涉及。通过增加可追溯性和机动性，好处可以在不到一年的时间内从规则和主数据仓储中获得。最后，业务得以从业务视角访问信息系统的资产，这消除了通常位于业务和 IT 人员之间的不透明性。通常来说，作为一个重要的流程目标，企业也应该看到关于业务规则和引用数据的业务知识的增长，这要拜所识别的建模成果和来自仓储的文档所赐。记住一点很重要，这个文档可以直接被 IT 团队和系统执行：这保证了业务和程序之间良好的对齐，并可增加系统的可审计性，包括满足法规的要求。

在第一阶段完成了利用方法和工具来控制仓储，并将它们与遗留系统集成之后，下一步通常就是重建所有系统以获得更大的机动性，并在合适的时候抛弃过时平台。

在这一阶段，必须设计一个信息模型来包含在遗留系统中被处理的数据结构的详细业务视图（图 2）。这个模型必须基于经过全局组织的数据模式，以鼓励数据聚合（它把共享一个强语义内聚的数据组织在了一起）之间的弱耦合。部分公共模型形成了构建引用数据（即系统间共享的数据，它通常是审计员主要关心的目标）仓储的基础。为了避免脑中一片空白，我们可以选择一个现成的数据架构模型，如由关注引用数据建模流程的主数据联盟组织（MDM Alliance Group，MAG）所发表的模型。

图 2. 主数据管理

至于业务规则端，某些算法部分必须从现有代码中抽出，并重写成 BRMS 中的规则。为了代替这个被转移的代码，需要增加一个对规则引擎的调用。业务数据通过这个调用被路由到规则引擎，被格式化成上面介绍的公共信息模型。BRMS 和 MDM 系统共享了相同的数据模型，该模型独立于常常是异构地存在于当前系统中的物理表示。发现规则并不是件简单的活。它要求业务和 IT 团队的合作，由他们一起来分析 IT 系统，发现或再发现隐藏其中的规则（图 3）。

图 3. ACMS 实战

被治理的信息语义和系统机动性又一次成为了 IT 的主要挑战，因为它们近来已经被证明具有重大的影响。只有按照建立于面向服务架构基础之上的 ACMS 原则对信息系统进行深度再造（重塑），这些挑战才能得到解决。好消息是这个工作可以按阶段进行，逐步地增加价值。特别的，这些关键驱动因素包括运营可见性（和可审计性）和价值驱动的组合管理。任何组织所取得的进步都应该被公开评定，以向管理高层和股东提供有意义的风险管理度量指标。

查看英文原文： We Need to Create Information System Ratings 。

感谢黄璜对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。