精益集成

白皮书 精益集成 本文档含有 Informatica Corporation 的保密、专有信息和商业秘密信息（“机密信息”），未经 Informatica 的事先书面同意，不得进行拷贝、散发、复印或以任何其它方式复制。 尽管我们尽最大努力确保本文档中信息的准确性和完整性，但仍可能存在一些排版错误或技术误 差。如因使用本文档所含信息而造成任何损失，Informatica 概不负责。本文档中包含的信息随时可 能更改，恕不另行。 Informatica 自行决定将这些材料中讨论的产品属性纳入其任何软件产品的发布或升级中，并自行决 定任何此类发布或升级的时间安排。 受下列一项或多项美国专利 保护：6,032,158；5,794,246；6,014,670；6,339,775；6,044,374； 6,208,990；6,208,990；6,850,947；6,895,471；或受下列正在申请的美国专利 保护：09/644,280； 10/966,046；10/727,700。 此版本发布于 2009 年 5 月 1精益集成 白皮书 目录 简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 精益集成原则 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. 消除浪费 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 持续支持知识 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. 计划更改 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. 更快提供 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. 提高团队能力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. 嵌入式优质 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. 统筹优化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Deming 的 14 点. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 按事实管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 弄清楚问题 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 确定根本原因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 呈交结果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 作者信息 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 参考资料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 简介 精益制造是一个管理系统，着重为最终客户创造价值并杜绝没有附加值（浪费） 的活动。其原则来源于丰田生产系统 (TPS)，此系统于上世纪五十年代开发，在过 去 15 年中，我们一般就将它简称为“精益”。虽然“精益”来源于产品制造，现 在它已被广泛认为可以有效应用到较广范围的产品和服务行业。“精益”借鉴于其 它方法并与这些方法紧密相关，包括价值网络、约束理论、六西格玛以及战略流程 控制。 精益软件开发是一个灵活性的方法，它将精益制造原则和实践移植到软件开发领 域。它改编自 TPS，由 Mary Poppendieck 和 Tom Poppendieck 在他们合著的《精益软件 开发》1 中引进并在《实施精益软件开发》2 中得到丰富与补充。 精益集成就是在这些先前的工作基础上，通过将两位作者的原则应用到集成流程， 精心打造而成。在此白皮书中集成的定义是“将独立的信息技术元素汇总成一个聚 合系统的过程”。 精益集成适用于各类集成领域，包括以下方面： 系统集成• 是从组件子系统到一个聚合系统的汇总，确保这些组件子系统可以有效 交互操作。 数据集成• 访问不同系统的数据和功能，以创建一个联合、一致并且可供跨组织使 用的核心信息视图，从而改善业务决策和运作。 企业应用程序集成• 可以跨业务应用程序实现信息交换和流程自动化，这些独立开 发的应用程序可能运用了互不兼容的技术，通常基于不同数据模型并且保持独立 管理。 软件系统的天性注定它们非常灵活，并且会在一段时间后改变（除遗留系统外）。 在这些各个领域中的集成并非一蹴而就，它们是持续性的活动。 本白皮书通过三节介绍精益集成：1)精益集成原则的讨论；2)Deming 的 14 点以及 它们在集成领域的含义；3)一个极为相关的最佳实践，名为据实管理。 概要 精益制造是一个管理系统，着重为 最终客户创造价值并杜绝没有附加值 （浪费）的活动。精益软件开发是一 个灵活性的方法，它将精益制造原 则和实践移植到软件开发领域。精益 集成就是在这些先前的工作基础上， 通过将两位作者的原则应用到集成流 程，精心打造而成。 关键词 精益集成、集成能力中心 (ICC)、系 统集成、数据集成、企业应用程序集 成、持续改善、Deming 白皮书 3 精益集成原则 精益集成可以归纳出七个类似于精益制造和精益软件开发的原则： 消除浪费1. 持续支持知识2. 计划更改3. 更快提供4. 提高团队能力5. 嵌入式优质6. 统筹优化7. 1. 消除浪费 针对制造和生产线最初的七种浪费（日语中的 Muda）为： 运输（不必要的物料移动） • 库存（包括正处于制作过程中的过量库存）• 动作（开展此工作要执行的额外步骤） • 等待（非活动期） • 超量生产（生产超过需求水平） • 超量处理（返工和重新处理） • 缺陷（在检查和修订缺陷中涉及的工作） • 开发软件与生产实际产品有许多相似之处，Poppendiecks 在《开展精益软件开发》2 中巧妙地将这些浪费比喻成软件开发界存在的问题。这些浪费有许多都非常明显， 这当然包括浪费精力修订缺陷，而不是最初即开发没有缺陷的代码。过量生产在软 件界好比为软件添加用户未请求的功能或用户不急需的功能（有时指“镀金”)。 正如 Poppendiecks 提到，“精明的软件开发机构首先考虑保持代码基础的简单、 精益和小型化”（第 69 页）。 在实际产品领域和虚拟软件领域之间的其它类似点不太明显，例如运输浪费相当于 设计人员、代码编写人员、测试人员以及实施人员在交底时的信息缺失；动作浪费 相当于在中断驱动型工作环境中的任务切换。无论如何，Poppendiecks 都已经很好 阐述出软件开发上的浪费，包括系统集成到何种程度，这里不再一一重复。您只需 阅读此书。 精益集成 4 也就是说，《实施精益软件开发》并不能解决所有集成子课题，在很多领域中， 仍然随处可见大量浪费的时间、精力和金钱。 首先，构建尚不需要的集成功能或额外功能是种浪费。集成团队通常特别喜欢预测 出机构的需求，在构建接口、数据集市、标准格式消息或 SOA 服务时时刻牢记整个 企业的需求。这确实是一个令人赞赏的目标，但是集成团队通常没有构建此类常见 功能的资源和资金，因此在可能用到此功能的首个项目耗费构建整个企业的解决方 案的全部成本时，他们将陷入困境。此作法被比作“首位为整辆公交车买单的公交 车乘客”或类似的暗喻。项目预算因此受到影响的业务领导人讨厌这样的作法。请 允许我重复一遍 — 他们讨厌这样的作法。业务部门获得优化其功能的预算，但是 当他们被告知实施将花费更长时间和更多资金，以便构建可供将来其他用户重复利 用的功能时，他们变得沮丧，甚至愤怒。这可能确实是机构的策略，但是在最后， 它使集成团队屈从于项目发起人而不是促进协调。 但是，还有另一个方法 — 仅构建第一个项目要求的功能，并按照可以在未来第二 个项目来临时扩展的方式构建。如果变更的本质如此，第二个项目要求重构为第一 个项目开发的解决，那么就让它这样。由于“建好肯定能用上”方法的缺点， 上述方法在目前仍然更令人向往： 长期以来，存在着对未来项目要求的不准确理解，即如果提前构建项目，那么会• 产生错误 附加代码或数据会将资金耗费在开发和维护上，不带来任何效益，直至出现下个• 用到这些代码或数据的项目 在构建符合未来需求的想当然的“理想”解决方案时，首个项目的商业效益会• 被拖延 首个项目的业务发起人会对实施团队感到不满意（这往往将赶走您的客户）• 如果将重构第一个项目的成本加到随后的第二个项目（如有）上，那么机构将更为 优化。在此情况下，第二个项目的需求变得与第一个项目的需求一样清楚（由于第 二个项目肯定已在开展之中），因此对于待构建的内容也就没有任何模糊之处。而 且，第一个项目的效益将很快得以实现，这实际上有助于为第二个项目提供资金 （孤立的会计作法可能仍然使机构难以采取此措施 — 虽然如此，优势依然明显）。 最后的启示为“不断重构集成，这样应用程序才不会被淘汰”。 第二，到处应用中间件技术是一种浪费。对于某些集成专家而言，这听起来像异端 学说，因为众所周知，在组件之间加快实现耦合脱离的方法是添加抽象层。在这一 看法上毋庸置疑。但是，事实上，虽然每层均会带来潜在的分离优势，但是这还也 会带来成本。因此，这的确是一个有关成效比的权宜之策。 白皮书 5 作为集成专业人士，我们常常将点到点集成描绘得很“邪恶”，因为它们使组织紧 密耦合，如果在没有标准的情况下应用，一段时间后将产生集成毛团。这太真实不 过了。但是对于一些具有严苛性能要求的特定的大量数据交换而言，这并不意味着 点到点接口不是最佳解决方案。每个中间件层在技术、人员开发、组织更改和复杂 性方面均会持续产生成本，因此只有在抽象层的效益超过持续支持成本时，才应添 加中间件。 中间件抽象层的另一个例子是标准模型或通用数据定义。人们很难反驳这样的原 则，即跨越具有不兼容数据模式的多个系统，使用通用的数据定义。虽然如此，常 见数据模型不是在某个时间点创建的静态对象，它们不断演进并且需要维护。除非 您有理由让逐渐增多的员工保持标准化模式，否则请勿添加此层，因为它肯定会在 短短几年内就变得陈旧和毫不相关，这是另一种浪费的实例。 第三，不利用规模经济的优势；重新开始是个浪费。事实上，只有相对较少数量的 集成模式可以满足哪怕是大型公司的集成需求。虽然集成的总数较大（数千或数 万），模式的数量却仍然较少 — 对于 90% 或以上的数据交换而言，可能只有一小 部分。但是，如果集成开发工作被每个项目团队视为一项独特的工作，那么随着时 间推移，我们会获得数千个“艺术品”。从我们多年的生产线经验中获知，每次数 量翻番3，成本节省额均会增长 15% 到 25%。我们在软件开发领域的经验很适用于 实现这些节省目的，这缘于两个因素 — 学习曲线的优势（您从事某项工作的次数 越多，您就越容易掌握此工作）；可特别清楚地了解重复利用机会（集成进行得越 多，模式变得越清晰）。 第四，工具和标准不必要的变更是一种浪费。我们还从制造业了解到每次变更加 倍3，成本就会上升 20% 到 35%。在集成领域发生的变更源于不同的中间件平台、 开发工具、交换、数据格式、接口规范以及元数据标准等。没有对它们以及 其它变更源进行有效治理，集成的种类可能将非常巨大。 如果我们将第三和第四例相结合 - 规模不大以及不必要的变更 - 成本和潜在质量问 题将使差异呈级数递增。举个简单的例子，试想某个机构有八个部门，每个部门 每年都按自己的首选工具集、技巧和标准开发一个集成。很显然，如果他们共同努 力，让一个团队构建多个集成，那么他们会从更为平缓的学习曲线、工具的重复运 用和常见组件中获得成本节省。基本思想是这样一个团队每年可以构建八个集成而 不是一个集成，这支团队将看到更多重复运用的机遇，只需在反复利用的基础上使 用类似的工具开展一些类似工作，他们就会更为迅速。具有较高产出的中央团队可 更为清楚地发现模式并加以利用。 精益集成 6 从这个简单的示例可发现，如果为八个部门分别建立集成的成本为 10,000 美元， 则中央团队的成本将是 1,159 美元到 3,144 美元，这削减了 70% 到 90%！ 此结果来 自将数据量翻三番，即可获得每次 15% 到 25% 的节省；将变更降三番，即可获得 每次 20% 到 35% 的节省。真实案例研究表明，在集成开发节省方面，事实上这么 巨大的改善完全可以实现。 2. 持续支持知识 “精益”和丰田生产系统的核心原则是通过实验和学习持续改进。一般观点是不存 在完成某事的“完美”方式。相反，世界上始终存在一些可以使用科学方法发掘从 而得到改善的机遇。正如 Poppendiecks2 所述，科学的方法通常分为这些步骤： 观察并描述一个现象或一组现象。1. 设定假设情况来解释现象。2. 使用假设情况来预测某些内容 — 其它现象的存在或者最新观察的结果。3. 进行试验，查看是否预测真实有效。4. 如果假设可以通过实验证实，则可以将此视为理论或规则。5. 如果假设不能通过实验证实，则可以否决或加以完善。6. 这可以细分为由 Deming 描述的更为简化的四步法：计划、执行、检查和行动。大多 数精益实践侧重于构建知识，但是我提倡将重点放在持续性的支持知识上，这包括 持续维护和培养。在集成活动中，我们可以通过多种方式运用此原则。 首先，必须考察和改进标准。此原则有一个推论，即五个 EAI 法则4之一：“不存 在绝对的标准”。事实上，标准对于精益集成必不可少，但是将它们认为是固 定、静态、不可更改并可以运用于所有情况的看法是错误的。以 COBOL、TCP/IP 和 HTTP（仅列出少部分标准）为例，在过去多年来它们一直有较大的演进。企业集成 标准也需要持续支持并随着时间推移而演进。 第二，精益实践特别强调科学方法。在集成领域，我们认为这点如此重要的原因包 括，我们常常碰到跨越多个独立团队或组织职能部门争取协调一致的难题。在平常 未曾合作的团队之间达成一致是比较困难的。在没有数据的情况下，您手中只有各 方意见，没有客观数据，在不同意见（按过往范例的有色眼镜筛选出意见）的人员 之间达成协议几乎不可能办到。有关数据驱动跨团队问题解决的一项特别实用的技 巧是“按事实管理 (MBF)”，在本白皮书的稍后部分将介绍此技巧。 第三，必须在一个结构化并且可搜索的库（而非通过静态的非结构化格式）中维护 组件之间的集成相关性。您的最初反应可能是这不必要，因为您的机构已经要求每 个项目，为组件之间的所有信息交流开发详细的文档。在这种情况下，不妨问自己 这些问题： 白皮书 7 文档是否反映出生产的部署内容，包括在设计完成后进行的变更？1. 两年后，一位普通的业务分析师、设计者或者开发人员是否还能找到该文档？2. 五年之后呢？如果原文档撰稿人不再为此公司工作呢？ 即使他们确实找到文档，是否能够理解？换言之，是否所有文档中的图标规范3. 均一致，是否基于常见的数据对象词汇表和术语表？ 如果在部署项目之后对生产进行维护性变更，那么是否更新了文档以体现变更？4. 如果您对全部四个问题的回答均为“是”,那么在这个特定的持续性支持集成知识 方面，您已具有必要的方法。如果您对一个或多个问题的回答为“否”，那么在您 每次需要更改内容并要求重建另一个版本的定制集成文档时，您会浪费时间。 3. 计划更改 大部分精益实践将此原则称为“延迟承诺”或“尽可能晚做决定”。一般概念是尽 可能等到您拥有可以获得的全部信息，然后再制定难以撤消（或撤消代价高昂）的 决策。灵活的软件开发使得您可以有效运用此原则。与此思想紧密相关的概念是批 量定制，这包含一些作法，例如 a) 设计基于标准组件并且为特定用户定制、组装 或配置的产品；b) 缩短设置时间以实现小批量（甚至一个一批）；c) 利用供应链实 现恰好够用并提供及时的库存管理。在集成领域，与此原则最为相关的是变更计 划，有许多关键技巧均可用于实现此目标。 首先，破除组件之间的依赖性，以使每个组件（或系统）可以在不影响其它组件的 情况下变更。松散耦合是最为宝贵的结构属性之一 — 尤其是企业级的松散耦合。 尽管在有关浪费的前一章节中介绍了许多盲目添加中间件的不利因素,中间件技术 仍然是获得松散耦合的有效方式之一，该项技术在这方面有助于打破应用程序之间 的依赖性。在典型供应链中可以找到一个极好的松散耦合系统示例。通过行业标准 数据定义、通用协议以及可以将流程协调作为与业务应用程序分开的单独层来处理 的处理工具，企业对企业 (B2B) 交互得以实现。换言之，B2B 交互通常至少包括三 种中间件抽象：1) 标准化数据模型；2) 常见传输；3) 流程编排层。凭借相同类型 的中间件基础设施，在企业内的各种供应商采购应用程序之间可以实现松散耦合。 第二，使集成的重建如同“按下按钮”一样简单。事实上，您永远也不会只构建一 个集成。您将多次重建集成 — 实际上，即使在首次生产部署之前，多次重建集成 也是司空见惯，因为只有在系统集成测试之时，才会出现真正的数据定义和质量问 题。因此，如果更改集成是规范作法，那么为何不对此尽可能实现自动化，从而使 您可以像按下按钮一样快速地重新生成生产集成？ 精益集成 8 第三，使决策可撤消。例如，假如您做出设计决策，决定通过企业信息集成 (EII) 方法来实时创建客户帐户数据的综合视图，结果，您通过大量测试发现，响应时间 将无法满足要求。备用方法是使用提取转换加载 (ETL) 解决方案并复制某些客户的 帐户数据，从而达到性能要求。通常，如果在实施环节后期采用备用方法，那么这 将是一项影响整体项目时间安排的重大设计变动。然而，如果在元数据库中维护记 录和数据映射规则系统，并且如果数据转换例程是可重用的中间件部件，那么或许 可以快速撤消最初的设计决策。 第四，使用批量定制技巧，这样，指定的集成会变得更像是一个组装过程，而不是 一个定制开发工作。这当然是 SOA 和中间件平台背后的核心思想，但是它仍然需 要可有效执行的方法。例如，多数大型 IT 商店有一项执行客户地址清洁的常见例 程，但是令人惊奇的是，居然有很多团队并不用它而是重新创造他们自己的例程。 如果不可以在每处都使用常见例程，那么这将违背本意。此解决方案包括在持续不 断的基础上建立负责维护和增强共享业务对象和可重用组件的 ICC 或中心团队。 4. 更快提供 长期以来，业内一直存在项目两难选择的困扰，这就是您似乎无法同时拥有快速、 优秀和实惠 — 您只能选择其中两项。对于定制的一次性解决方案，可能确实存在 这样的两难选择，但是如果您通过一个可反复的过程实现集成，那么这样的权衡并 不会在集成开发中存在。一些机构已将其成本降低数十倍，并且可以提供一贯优质 的快速集成。取得这样了不起的成绩的秘诀是注重时间。 在您加快集成的开发时，一件趣事发生了 — 成本下降，质量上升。这似乎有悖常 理，因为注重速度通常意味着将更多人员投入某个问题以便快速解决该问题，而这 会提升成本。另一个常见的错误观点是速度意味着仓促和犯错误，而这又会使质量 下降，由于错误和返工而提升成本。在时间基础上竞争 — 或者通过时间来彰显您 的能力 — 可以对抗旧范式。 加快研发的最佳方式是消除浪费的活动、减少延迟以及重复利用常用组件，我们曾 探讨过所有这些内容。虽然如此，仍然还有一些其它技巧可用来缩短交付时间。 首先，将集成开发从项目的关键路径上剥离。每个项目具有一个关键路径或瓶颈 — 即影响端到端项目完成速度的限制因素。集成活动常常是项目工程中的关键路径， 因为它牵涉到汇总所有零散工作将有多么复杂和不确定。如果您能清楚了解到倾向 于将集成活动放在关键路径上是根本问题原因所在，并着手解决这些问题，那么可 能不会出现这种情况。例如，在不同的独立系统之间存在数据质量问题是在集成测 试过程中出现重大延迟的常见原因。此问题的解决方案为，在流程中加入一个针对 所有相关项目的项目前数据探查强制评估。如果在一开始就能充分了解要在系统之 间交换的数据，那么可以在开发和测试上节省出令人叹服的时间量。 第二，实现可变的人员配备模式，制定可以快速补充新员工的流程。供应和需求的 不匹配是造成延迟的另一个常见的根本原因。例如，如果您有一批数量固定的集成 开发人员，负责支持新项目开发，他们中有些人可能会在需求淡季时空闲，但是在 其他时候，需求可能会远远超过计划人员的水平。如果您有员工 10 名，但是有好 几个月，需求会增加到 15 名，那么您只有以下为数不多的选择： 白皮书 9 通过走捷径以及降低质量水平，让 10 个人完成所有工作。这并非长久之计， 1. 因为降低的质量水平会造成维护成本的增加或未来灵活性的降低，这反而将牵 制您。 让这 10 个人平时和周末加班。这并非长久之计，因为您不能以使员工“累垮”2. 作为结束。 延迟一些项目，直至需求下降。这并非长久之计，因为事实上您在赶走您的客3. 户 （在客户现在就需要帮助时，对他们说您可以在两个月之后帮助他们，就等 于对他们说“不”）。 招募额外员工。这是唯一的长久之计，但是前提是您可以快速招募到这些员4. 工，然后在工作量降低时将他们剔除。实现这一切的关键包括具有定义妥当的 标准流程、好的文档以及建立与咨询公司的长期合作关系。 第三，着重推动端到端的项目周期时间，而不是着重优化各个活动。这似乎有悖常 理，但是实现全局统筹优化需要在下一级分别优化各个组件。例如，在所有软件均 已开发之后，创建用户文档的任务会变得最为高效。但是，如果按依次连续的方式 准备文档，那么整个项目会面临较大延迟。如果较早（甚至在需求阶段）开始文档 工作，而不论实际上是否需要重写某些文档以体现设计和开发阶段的变更，那么可 以缩短整个项目的时间安排。如果鼓励各个支持某项目的职能团队缩短整个生命周 期时间，而不是侧重于他们团队的效率，则整体改进将非常巨大。 5. 提高团队能力 提升团队能力主要是高层管理人员的责任，但是前线人员也可以通过自己的行动提 高能力。《X-Teams》5 一书非常简洁地阐明了此两难选择： “上级经理有一个愿景，但是他们如何才能让机构其余部门实施实现愿景所必需的 计划？ 假如个人与组织的目标一致；团队拥有他们需要的支持和工具；可以获得所有完 成工作所需的信息并且这些信息不会不断变化；如果工作并不高度依赖机构内外 的其他活动，那么这不会成为一个两难选择。这些情况很少出现，因此不妨采纳 《X-Teams》一书中的意见：应当从外部整体关注团队而不应在内部隔断式地关注； 团队的能力和效率来自与高层管理人员能力提高的有机组合；尊重员工以及团队成 员的主动性。在集成领域有许多有帮助的具体原则。 首先，清楚定义集成团队的责任。机构中与集成有关的大多数问题是：在很好地定 义了每个职能区域的责任后，对于谁负责组与组之间的信息交换存在大量不明确的 地方。在技术领域，谁负责“空白处”的问题十分明显。更为确切地说，谁负责集 成系统？ 集成系统是组件的集合，这些组件作为一个单元来管理，用于数据集成。它与企业 内的其它应用程序系统相分离，并为这些系统提供服务。这些服务可能包括数据迁 移、数据整合、数据同步、数据质量或流程编排等等。这与传统观点形成了鲜明对 比，在传统观点中，集成组件作为应用程序的一部分来管理。在最糟糕的情况中， 它们根本不会得到管理（即它们是“独立的”集成组件）。 精益集成 10 集成系统是从整体角度来看待集成组件的。它为每个业务应用程序划定了清晰的界 限，并且明确定义了能共同代表集成系统及其功能的所有组件，无论这些组件可能 有多么分散。这使您能够在完成早期项目之后，以跨应用程序的方式持续支持数据 集成。 第二，使例程活动自动化，让人员专心考虑他们必须专注的工作。许多集成工作非 常重复，这具有两方面缺点：1) 使用人工来执行重复任务是浪费劳力；2) 如果工 作千篇一律，不需要动脑子，那么员工容易麻痹而变得自满。请务必注意，使人工 活动自动化“绝非”用机器替代人员，而是提高可能达到的集成水平。例如，如果 您带领一支专门从事数据映射的 10 人团队，您通过改进自动化水平，将人员需求 降为 5 人，那么您可以安排其他 5 人专注具有更多附加值的功能，例如端到端流 程流、主数据管理或者改善数据质量，所有这些活动都将为企业创造远非低水平映 射工作可比的价值。 第三，将外延团队（包括离岸合作伙伴）视为第一级团队的成员。此原则不仅关系 到正式措施，例如指标和激励奖，而且还关系到非正式技巧，例如团队庆贺与赏 识。大多数公司的人力资源政策对此设有限制，因为出于税务和法规方面重要因素 的考虑，不能给予工与员工相同的待遇，但是这并不意味着合同工不能享受团 队成员的待遇。例如，如果您为员工提供激励奖，那么在与您的合作伙伴协商合同 条款时，请加上这一点，这样分派至您的项目的员工可以从他们的雇主那获得类似 的项目奖金。非正式技巧对于打造团队而言甚至更为有力。例如，在达到某个项目 里程碑时，订购庆典蛋糕，并将蛋糕发往您在孟买的离岸合作伙伴办事处，这样会 极大鼓舞远方的工作人员。 第四，教员工如何了解和解决问题，教经理如何开展员工培训。请注意，我们并不 是说要培训技术方面的技能。当然，如果要求某人开发 Java 程序，那么此人确实 需要学习 Java — 但是这并非团队提升的源泉。当人员能够通过“突破常规”方式 思考（即不在他们的职责周围设置人为障碍），以及不畏惧处理在其擅长领域外的 问题时，能力将获得提高。虽然某些人天生就具有这方面能力的倾向，我们仍然希 望在此提供一些可以帮助每个人获得改善的技巧。无论任何，首先请确保前线经理 和主管具有培训他们手下的必要技能。 白皮书 11 6. 嵌入式优质 有三个基本策略可用来改进质量： 通过检查、复查或审计来确保质量 1. 降低恢复成本以快速更正发现的问题 2. 通过对流程进行“排错”，实现嵌入式质量 3. 大多数机构按此顺序确定重点 — 但这是个错误。您无法“从内部检查质量”。在 发现缺陷之时，损害已经产生，修正缺陷的成本可能会非常高。与排错流程相比， 如果更容易降低由于纠错恢复而产生的成本，那么第 2 个选择将是一个可行策略。 但是，我们建议最好还是在一开始就不产生缺陷。与通常的意见相反，创建没有缺 陷的代码是可以实现的 — 即使涉及到外包合作伙伴。Poppendiecks 在《实施精益软 件开发》2 的第 8 章中提供了有关此话题的行之有效的处理办法。此外，还有许多 可供集成团队使用的技巧。 首先，使部署流程没有错误。部署可包括源代码管理的整个流程，以及代码从开发 到测试到投产的所有过程。确保不出现错误（即迁移的版本错误、未包括依赖的组 件、未将变更与其它依赖元素同步等等）的最佳方式是使流程自动化。一般观点是 不在测试或生产环境中涉及任何人工作业。这也就是在与部署工具集成的库中描述 您要进行的变动，在部署清单已完备并且审批到位后，让工具推出所有变更。在拥 有此能力后，将出现两个非常强大的功能：1) 您可以更为频繁地进行测试或生产 发布，这使您可以小规模增量式（小批量）地开发代码，这是改进质量和缩短生命 周期时间的关键之一；2) 如果真的出现问题，撤消变更并回滚到前一生产状态要 变得容易得多。 第二，停止构建旧代码。Poppendiecks2 将遗留系统定义如下： “有两种软件 — 容许变更型软件和遗留软件。某些软件系统相对容易适应业务和 技术变更，而还有一些软件系统则难以变动。在软件开发领域，这些难以变动的系 统被标记为“遗留”系统。容许变动型软件的特别之处在于其有限的依赖性以及具 有可以标记意外变更结果的综合测试工具。因此，我们可以将遗留系统定义为未经 测试套件保护的系统。此原则有一个推论，在您每次未经相关测试构建软件时，您 会构建旧代码”（第 166 页）。 对于中间件系统或者组件而言，由此获得的教训是使它们模块化并且可以接受测 试。此原则有一个推论，您应为新的应用程序规定集成要求。这也就是建立清楚要 求，以便应用程序系统能够通过标准化和支持的界面呈现其内部功能。最后建议您 首先建立界面和测试工具 — 然后再构建集成工具的其余部分。 第三，不断进行集成，不仅仅是在项目生命周期中才这样。这是在集成能力中心或 专业技术集成中心幕后的一项基本前提 — 集成是一门特殊学科，它需要一支统一 协调的团队不断关注，以便确保集成解决方案一旦实施就不会散开。该主题的最佳 参考资料依然是《集成能力中心》6 一书。 精益集成 12 7. 统筹优化 正如先前所述，整体统筹优化需要在下一级分别优化各个组件。这不仅适用于集成 领域，而且还适用于视为一个整体的企业。对于在整个企业利益层面上进行权衡的 独立团队或职能组，必须具有一套共同的价值、使命和目标。为此，我们有许多针 对集成团队的关键建议。 首先，注重整个价值流，而不是单位或职能活动。例如，有一所大银行的集成团队 受特许为许多遗留的中间件系统进行重构，以便降低运营成本、为加快适应变动而 简化环境、改善吞吐量并减少生产事故。团队可以使用这些来衡量是否成功，但是 他们决定将项目的成功与银行客户的满意度挂钩，而罔顾这样的事实。a) 集成系统 离直接影响最终客户尚有一、两步之遥。b) 对于客户满意度，还有许多其他因素 具有比集成系统大得多的影响力。虽然如此，由于集成系统在快速可靠地向 ATM、 网站、取款机工作站以及呼叫中心员工提供数据方面扮演着关键角色，因此团队认 为牢记最终客户非常重要。使用此指标可以令机构的其余部门为此精诚协作，帮助 集成团队取得成果，因为每个人都有兴趣改善客户满意度。 第二，提供完整的解决方案。所谓完整，我们指不仅要提供集成软件的组件，而且 还要了解所有即时更改在端到端数据流中的作用；了解整体性能将受到何种影响； 了解随着时间推移组件将怎样变化；了解如何有效地监控系统运行；此外，还要了 解可以如何监控和计划容量以确保获得可持续的吞吐量。 第三，选择合适的指标以保持对整体情况的关注。培养一支具有合作精神的专门团 队。主要概念是选择一些有广泛基础的全盘措施，而不是许多专注范围狭窄的指 标。这并不意味着您不应评测各个领域的详细活动以及流程的各项步骤 — 相反， 这些详细的评测对于为支持不断改进而进行的数据收集十分必要。但是不应将这些 详细的度量用于刺激或鼓励个人或团队，应将其投入到数据驱动型改善流程中。 其实，三个中心集成指标即可满足鼓励个人或团队的一切需求。 整个项目实施1. 的周期时间 — 从概念到已部署的解决方案。 商业价值 2. — 可以采用财务衡量标准，例如运营成本或销售收入，但也可采用从 业务角度而言有意义的任何其它指标。 净推荐值 3. — 一种客户满意度评测标准。净推荐值可以是一支拥有多个内部客 户的集成团队的内部指标，也可以参考企业的外部客户。净推荐值是由 Fred Reichheld 在《最终问题》7 中提出的评测标准，书中介绍的公式是将失望客户数 量从满意客户数量中扣除，从而得出范围介于 0 至 10 之间的净评分。 白皮书 13 Deming 的 14 点 W. Edwards Deming 的哲理对精益实践有着关键的影响。Deming 相信通过采用合适的 管理原则，机构可以在提高客户忠诚度的同时提高质量、削减成本。关键是实施不 断改进，并将制造视为一个体系，而不是一些分开的步骤。 Deming 为有效业务管理提供了 14 个关键原则，这些原则最早出现在 1986 年的 《逃脱危机》8 一书中。以下列出了最初的 14 个原则以及如何在集成工作中运用 这些原则的说明： 1. 建立以改善产品与服务为目的的长期一贯性，致力于变得有竞争力、保持业务运 转并可以提供更多工作机会。 说明：针对企业的长期数据集成需求。请勿专注于短期的项目需求。我们的目标是 在将集成作为一项长期工作予以持续支持。这样做，集成能力中心会发现他们的团 队不断壮大并可以提供更多而不是更少的工作机会。 2. 采用新哲理。我们处于新的经济时期。西方管理层必须起来迎战难题，必须了解 他们的责任，在变更中争取主动。 说明：IT 界已发生变化，在汇总职能“烟囱”和推动组织变更方面，集成专业人士 必须成为组织的带头人。 3. 终止对检查的依赖性以获得高质量。通过从一开始即将质量嵌入产品之中，从而 消除批量检查的必要性。 说明：在质量嵌入到集成之中，方法为 a) 转而使用“首先测试”方法，在编写代 码之前开发出测试脚本；b) 实施许多小规模增量变更，而不是大规模变更；c) 使用 元数据维护。 4. 总结按照价格标签回报业务的作法，而是尽量降低总成本。根据长期忠诚度和信 赖感方面的考虑，转而为每种物料选择单一的供应商。 说明：停止使用手动编程工具，转而选择集成平台以便在整个机构使用。减少变更 将最大限度降低总成本，并与为数不多的供应商建立长期关系。 5. 不断改善生产和服务系统，改善质量和生产率，持之以恒，从而不断降低成本。 说明：投资降低可重复集成模式的时间和成本。在一个模式可以实现有效自动化之 后，您就可以立即寻找下一个机会，不断重复。 精益集成 14 6. 制定岗位培训。 说明：通过培养整个企业的员工，打造他们个人与集体的绩效，从而改善集成程序 的质量。鼓励员工问一些开放式的探索性问题，以定义问题、揭示需求并阐明目 标，将此作为他们日常活动的一部分。 7. 建立领导地位。监督的目的应是帮助人员、机器以及装备更好地工作。对管理层 的监督需要彻底的检查，对生产工人的监管亦如此。 说明：不断考察竞争对手和一流执行者，以找出增强集成服务、提高价值的方法。 主动团结他人以获得一流绩效，从而推动集成实践的增强。 8. 消除恐惧，这样每个人均能为公司有效服务。 说明：为所有项目制定项目总结、吸取主要经验教训，并将此作为一项，在新 员工培训时讲解这些教训。将失败看做学习机会而不是“寻找罪责”。 9. 消除部门之间的隔阂。研发、设计、销售和生产部门的人员必须作为一个团队来 开展工作，以便预知在产品或服务的生产和使用中会碰到的问题。 说明：进行跨职能部门的合作以确定实施新流程的影响。集成多个业务领域的工作 以支持战略优先级。发现市场和行业领域潜在的发展机遇以建立竞争优势。 10. 摈弃要求工作队伍零缺陷和达到生产效率新水平的口号、告诫与目标。这样的 告诫只会产生对抗性关系，因为造成这一系列低质量和低生产率的原因是体系， 所以这不在工作队伍的能力范围内。 说明：首先注重集成任务的实质。这是指，介绍集成团队/职能部门可以提供的服 务、形成集成的服务请求和实现过程、评定流程并不断完善总周期时间。换言之， 将集成活动的交付视为一个必须经过优化的“体系”。 白皮书 15精益集成 11. a. 消除工厂现场的用工标准（配额），用发挥主人翁精神来代替。 b. 消除目标考核管理。消除数量、数字目标考核管理，用创造性工作来代替。 说明：切实做到捕获和衡量流程，但这是为了收集数据以便持续改善，而不是为了 奖惩员工。 12. a. 扫清障碍，让钟点工也能为其创造性的工作感到自豪。必须将主管的责任从 负责纯粹的数字变为负责质量。 b. 扫清障碍，让管理人员和工程设计人员也能为其创造性的工作感到自豪。这意味 着废止年度考核或成绩评定，废止目标考核管理。 说明：致力于消除集成浪费，为员工提供完成任务所需的工具。在此重申，使用指 标来管理“体系”并不断改善这个体系，而不是用指标来奖惩员工。 13. 制定一个有关培训和自我完善的强有力计划。 说明：建立一个最佳实践库，为临时顾问以及所有新员工提供最佳实践培训。规定 必须在最佳实践中整合有效集成，并且每年应抽出时间培训其他人。 14. 使公司中的每个人都参与到完成改革的工作中。改革是每个人的事。 说明：建立使所有人参与的全景式端到端指标。始终牢记最终客户。收集必要的数 据以定义问题的症状和根本原因（人物、内容、为什么和成本）。根据事实、可用 资源和限制，制定备用方案。 16 按事实管理 在许多方法中都用到按事实管理 (MBF) 工具，这些方法包括六西格玛和能力成熟度 模型 (CMM)。它可用于推广数据驱动型决策，它是量化的问题描述、性能历史记 录、已确定优先级的根本原因以及相应对策的简练汇总。 MBF 的主要特性是依据事实来消除偏差，这使其成为跨职能“孤岛”达成一致的一 个特别强大的工具。此外，MBF 按划定的优先级，集成有待通过资源和努力来解决 的问题。最后，MBF 的核心概念是快速学习，使新成立的团队容易快速协调，有针 对性地掌握某方面的技巧，以便解决共同的问题。MBF 包含三步： 使用“四个什么”技巧弄清楚问题1. 使用“五个为什么”技巧确定根本原因2. 在篇幅为一页的简明汇总中呈交结果3. 弄清楚问题 “四个什么”技巧有助于量化问题描述以及量化实际性能与所需性能之间的差距。 基本思想是首先使用一般问题描述，然后不断提问（至少四次），直至获得一份非 常有针对性的问题描述。技巧说明实例如下： 初步问题描述：• 客户“资金占有率”太低。 什么是太低？• 与每个客户有 8 个帐户的其它公司相比，我们的机构平均每个客户 只有 4 个帐户。 这个差距的影响是什么？• 这代表着失去收入和盈利可能。 在每位客户与每笔收入和帐户之间的关系是什么？• 一位拥有 4 个帐户的客户平均 每年可带来 220 美元的收益，而一位拥有 8 个帐户的客户每年可带来 850 美元 收益。 填补此差距将有何影响？• 最终问题描述：• 我们公司的客户帐户渗透率是一流竞争对手的一半。使每个客 户的帐户数量翻倍以符合业界翘楚的水平将使收入提高 386%，这相当于年收入 18 亿美元。 白皮书 17精益集成 确定根本原因 “五个为什么”技巧用于改变过时的信条和观点，并使用事实来找出潜在问题。 “不能”发现根本原因的危害在于：根本问题表现出表面症状可能会被视为有待解 决的核心问题。一般观点是在您答出五个“为什么”之时，您应能够了解根本原因 所在。下个示例将展示此技巧。 初步问题描述：• 客户“资金占有率”太低。 为什么？• 我们的交叉销售做得不够。 为什么？• 我们不能在网站上交叉销售产品。 为什么？• Web 应用程序不清楚到底已经通过其他渠道提供或退回哪些产品。 为什么？• 我们没有一份可供所有渠道系统均可查看的综合客户数据视图。 为什么？• 每个业务部门以独立方式运营并不断实施互不兼容的系统。 最终解决方案：• 创建针对协调所有业务组的企业级商业案例，赢得高层管理人员 对大宗采购企业方案的许可。 请注意，如果我们在“四个为什么”后停住，那么团队可能会发起一个项目来构 建与其它部门系统进行传送的 Web 应用程序 — 往往在实施之后，这些团队才发现 其它部门也在更改他们的系统/流程，这样会使集成的解决方案失效。在这种情况 下，真正的根本原因是在于多个业务实体之间缺乏协调，我们应在实施技术解决方 案之前解决这个问题。 18 呈交结果 MBF 方法中的第三步是以简明的格式将收集的事实与得出的分析打包。下图 1 中有 所述格式的概述。 图 2 是为某个数据仓库整合项目填写的模板。最初问题描述为“数据仓库的成本 已失控，这无助于我们的业务。我们要么无法找到所需的信息，要么就是碰上系统 停机，所以我们无法获得数据，即使得到报表，这些报表给出的性能指标也是互相 矛盾。” 最终的问题描述位于图 2 上方，图中有图表格式的支持数据、已划分优先级的根 本原因以及相应对策。 图 1. MBF 一页格式 问题、性能趋势与目标的部分描述 随时间推移的绩效图 划分优先级和根本原因 性能和真正根本原因差 距列表 对策与行动 具体行动、负责人和截止 日期列表 影响，能力 预计效益和每项对策的 影响列表 支持或详细信息图 图 2. 有关数据仓库合理化方案的 MBF 示例 划分优先级和根本原因 对策与行动 影响，能力 企业数据仓库 (EDW) 的存储容量正以每 18 个月翻倍的速度递增，同时，生产事故也在不断攀升 —— 平均 每两日就会爆发一次严重性达 1 或 2 的中断。2008 年，EDW 的成本为 2200 万美元，虽然存储设备成本降 低，但是 EDW 的成本却仍以每年 60% 的速度递增。实施 EDW 合理化项目不仅可以简化环境，而且还可以 将 EDW 的规模降低 30%，从而使年成本递增从 60% 降至 20%，仅此一项即在未来三年为 BIGCO 节省 8400 万美元。 • 每个 LOB 使用其自身的标准创 建其自身的数据库 • 无法查看在 EDW 中存在哪些 数据 • 由于不了解相互依赖性所导致 的问题 • 由于缺乏标准的企业定义，不 同 LOB 的报表出现数据冲突 • 实施商业智能能力中心 （John Smith，2009-04-01 计划） • 获取元数据资料库 （Jane Doe，2009-03- 15 出版) • 建立 EDW 配置管理委员会 （Jane Doe，2009-4-14） • 推出数据治理项目 （John Smith，2009-06-01） • 填补 50% 的增长差距 • 填补剩余 50% 的增长差距 • 减少 50% 以上的生产事故 • 在年底之前解决所有优先级为 1 或 2 的审计问题 EDW 生产事故 0 20 40 60 80 100 120 140 160 180 2001 2002 2003 2004 2005 2006 2007 2008 年 严 重 性 达 1 或 2 的 中 断 EDW 增长趋势 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 财年 ED W 表 0 20,000 40,000 60,000 80,000 100,000 120,000 140,000 160,000 180,000 200,000 存 储 容 量 (G B ) 表 存储 (GB) EDW 成本趋势 $0 $10 $20 $30 $40 $50 $60 $70 $80 $90 $100 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 财年 百 万 美 元 基础案例成本（百万美元） EDW 合理化成本（百万美元） 白皮书 19精益集成 作者信息 Informatica 全球集成服务部副总裁 John Schmidt johnschmidt@informatica.com Mr. Schmidt 先生在 Informatica 公司担任全球集成服务部副总裁兼集成能力中心实践部 主管。他为客户介绍新兴科技的业务潜力，并领导制定企业计划的策略。他曾在银 行、零售、电信、教育、政府和公用事业行业工作。他主持集成共同体（Integration Consortium），编写了许多有关系统集成和企业体系架构的书籍和文章，开发了程序 管理的最佳实践，并经常在行业会议中发言。 参考资料 1. 《Lean Software Development: An Agile Toolkit》(Addison-Wesley, 2003)，作者 Mary Poppendieck 和 Tom Poppendieck。 2. 《Implementing Lean Software Development: From Concept to Cash》(Addison-Wesley, 2007)，作者 Mary Poppendieck 和 Tom Poppendieck。 3. “Time — The Next Source of Competitive Advantage,”出自《Harvard Business Review》 ，1988 年 8 月 1 日出版，ISSN 编号：0017-8012，作者 George Stalk。 4. “The EAI Laws,”出自《Business Integration Journal》，2002 年 7 月。 5. 《X-Teams: How to Build Teams That Lead, Innovate, and Succeed》(Cambridge, MA: Harvard Business School Publishing Corporation, 2007)，作者 Deborah Ancona 和 Henrik Bresman。 6. 《Integration Compe