作者 | Betty Zakheim
译者 | 冬雨本文要点未集成的软件开发和交付工具链带来了瓶颈、降低了生产力、阻碍了协作并影响了项目可见性。
看工具链的集成貌似简单，但其实际难度比乍看起来要难太多太多。
虽然大多数端点工具有API，但与其他工具的集成很不充分，因为：它们最初未针对此类集成进行设计，通常缺乏文档，而且发布新版本时经常会有所变动。
集成这些工具所要面对的最大挑战包括：理解从业者如何使用这些工具，解决这些工具之间会阻碍工作流程的冲突。
对绩效影响的管理、集成工具链的测试和维护的难度会随着端点的增加而呈指数级增长。
开发团队经常有一种“补鞋匠的孩子”的现象：村里补鞋匠的孩子居然没有一双自己的鞋子。造化弄人，开发人员也有着同样的残酷命运，企业IT团队负责为组织的客户开发软件和集成现有的应用，但通常用的却是分散的、未经集成的工具。他们的商业合作伙伴从来都不能容忍由于业务系统未集成起来而遭受低效和管理可见性的缺乏。但是，我们却发现软件开发和交付团队却出于某些原因在使用着分散的工具栈。
低效、浪费生产力、乏味无聊的会议、不畅地协作和缺乏可见性，这些是未集成系统正常的临床表现，所以为什么这些组织仍忍受着它们的折磨？因为集成这些在开发和交付中使用的各种工具实在是太难了。但是软件开发团队貌似觉得他们应该有能力很简单地在内部完成这件事，而不愿通过第三方的帮助。
我最近遇到这么一个组织，他们自己仓促地完成了集成，但之后发现他们无法发展和支撑。这个客户说，他们的集成仅限于两个ALM（Application Lifecycle Management：全生命周期管理）工具，现在已经包含有两百多万行代码了，已经变得很难管理了。它开始的时候还很小，但随着它的扩充，集成逻辑需要去处理每种随着规模激增的新情况。当达到两百万行代码时，开始需要数百万美元的维护成本了。
看起来很简单的任务实际上要难得多。你知道，使这些端点互通不仅是个纯粹的技术挑战；实际上，它更是个业务问题。虽然在选定的技术集成架构中要实现集成的是那两三个选择，但实际的挑战却是由于这些工具的差异带来的阻力和如何克服它们以实现无缝的集成。
两个系统间的连通经验表明，使用数据库集成技术集成的两个应用是脆弱的，使用端点工具的API是唯一明智的方式。所以应做些实验，试着使用这些API去连通两个端点。首先尝试做个小例子，集成两个具有“相同”工件类型的两个系统，比如缺陷。然后探索对它进行扩展时可能会出现的一些难题。
“像”数据那样同步你可能尝试的第一件事是映射两个工具都有的一个工件类型，比如缺陷。因为两个系统都有“缺陷”这一工件类型，所以这可能非常简单。
为做到这样，你将需要：
对这两个系统所做的内容有根本的了解。一个可能是缺陷跟踪工具，而另一个可能是敏捷计划工具。
了解这两个系统的对象模型，识别这两个系统中已有缺陷的属性，比如缺陷名称、录入者、状态、描述、附件，等等。
理解这两个系统如何使用它们的API（REST）进行查询、创建和更新对象（即缺陷）。
当工件已经创建或修改时的检测。
注意，在进行集成的过程中最常见和危险的其中一个错误是使用过多的API去调用端点系统。例如，低效的轮询和更新机制会使生产系统性能急剧下降！至少，你要确保创建一个避免端到端（成对的）集成的解决方案，因为此类架构会衍生出许多调用每个端点的API。
你马上就会发现虽然两个系统有同一个对象（缺陷）的概念，但这两个系统之间存在很多差异：
它们有不同的属性，因此模型也是不同的。毕竟，每个系统所管理的是与之领域紧密相关的对象，测试人员在测试管理工具中对缺陷的看法和开发人员在敏捷计划工具里对缺陷的看法是不同的。
甚至即使它们有类似的属性，它们的值和格式也会有所不同。
当工件、评论和附件被端点工具用户同时改变时，一定会出现矛盾。
当然，这些端点系统中的每个工件会被端用户不断用定制属性予以扩展。
集成的“最低保证”是发现和接纳多个系统中“相似对象”（比如缺陷）的不同，以便它们可以保持完美同步。尽管这些矛盾之处已经被我们标注出来了，但我们甚至还没有开始去处理集成中的更具挑战性的一些细节呢，这真是个坏消息。
它真的不是“扁平数据”一个工件与其他工件之间并非独立无关的。工件之间的关系提供了工件的上下文，例如：
“史诗故事”分解为许多实现它的用户故事。
存在组织（文件夹）和用于计划安排的容器。
关系构成可追溯性和上下文的重要基础，比如一个需求与覆盖该需求的测试之间以及与这些测试测出来的缺陷之间的关系。
跨软件开发和交付流程中使用的工具，工件间有许多关系形式。把这些关系从一个工具映射到另一个工具对于保持这个工作的上下文非常重要。对于一名开发人员来说，如果一个缺陷缺少上下文，不知道如何去重现它，那么尝试去修复它就是在浪费时间，会令他的心情十分沮丧。
处理矛盾，需要专家级的理解扼要重述：对于如何理解完成这些工具间的集成，有着非常重要的初始步骤。使用工具API的方式远远优于尝试去访问工具保存在底层数据库中的信息。想要进行健壮的集成就要解决许多工件和系统间的差异。
基于这一思想，发现这些差异并决定如何去解决它们就需要该工具的专业知识了，知道它们是如何被使用的。第一步永远都是先对工具进行详尽的技术性分析。
这款工具在实际工作中是如何使用的？
描绘工具中内在的工件、项目、用户和流程的对象模型是什么？
标准工件和属性是什么，我们如何快速简单地处理频繁的自定义，比如添加和修改标准对象。
工件的状态迁移有没有限制？
当然，我们可以利用API获取访问端点的能力及其管理的工件。我们也可以利用它们避免自己不小心参与了“非法”活动（因为API会遵行业务逻辑）。但还有一个小秘密：这些API许多实际是为使供应商可以更便利地构建分层架构而创建的，端点供应商并不需要构建这些使第三方可以用于集成的API！
所以，这些API通常缺乏文档并且不够完备：
数据结构，如何以及何时形成调用（针对有状态的系统），以及未在文档中记述的那些有负面影响的操作。
通常缺乏错误处理和错误信息。
边缘情况和缺陷很少记录。
因为它们不是文档化的，想搞明白如何处理这些问题需要大量的反复试验。而且令人沮丧的是，供应商的客户支持人员通常不知道这些问题和如何去使用他们的API，所以寻求解决办法经常需要去请教端点供应商的开发团队。
更糟的是，这些API会随着端点供应商的工具升级而发生变化。这些变化能否破坏这小心翼翼完成的集成，依赖于供应商针对API变更进行了多么彻底的测试、对文档化的同步修改如何，以及对用户是否通知到位了。对于按需或SaaS应用，有时会静若处子，根本没什么变更，而有时却动若脱兔，频繁变更。
到目前为止，本文只解决了在两个端点间进行集成所会出现的问题。一旦你想明白如何处理这些问题，那么集成到第三个端点的学习曲线就没之前那么陡峭了，这看起来合情合理。通过成功创建一个单一的集成，你已经做出了一些决策并了解了集成的一些基本原理。你确定将使用API进行集成，为此搭建了开发环境，已经涉足了解了该端点的API，已经规划了如何去应对由于端点升级带来的频繁变更。推测起来，当你再增加第三个端点时，就不必再在这些事上投入过多的精力了，集成将会更加顺利。
但很不幸的是，虽然学习曲线不像最初的集成那样陡峭，但也不像人们所希望的那么平缓。有些第一次集成时的问题会重新抬头，再次冒出来。你将不得不进行技术分析，分析该工具是如何操作的、它的工件是如何展现的以及如何协调它与集成生态中其他环境的差异。再说一次，这些API不像你希望的那样有充分的文档，你不得不通过反复试验发现你还有哪些内容并不知晓。另外，你还将遭遇其他未预见到的情况，当你试图集成本来未针对集成进行设计的工具时，这些情况会导致其固有的冲突。
然而，还有更糟的情况，那就是随着你增加14、15甚至更多的端点时，复杂度也将随之增加。你所增加的工具来自于完全不同的领域，其工件与你最初因系统不同而做的映射也不尽相同，随着这些工具地增加，工具间的冲突也就更多了。
从架构上来说，进行三个或更多个端点的端到端集成会带来性能和维护的恶梦。从性能的角度出发，使所有API都调用端点会降低工具为其用户的响应。当最终用户投诉他们的系统表现不再像集成之前那么好时，很多集成项目就已经失败了。
从代码维护的角度出发，如果一个集成生态具有三个或更多端点，其测试和持续维护的难度会随着更多端点的增加呈指数级上升。通常所有的软件开发项目都一样，那就是软件的测试与构建同样重要。你希望部署一套健壮的与生产系统隔离的测试基础设施，不过还是针对这些产品的正式版本予以测试。部署这套测试基础设施的时间和费用不容忽视，应该在计划和预算中予以考虑。��,ʧ��
我亲眼看到了那些组织尝试集成应用时所经受的挑战，这些挑战都与其自身的业务紧密相关，在一篇文章中实在无法把所有问题都说清楚。但是，我希望你对软件生命周期集成中涉及到的一些挑战有了一定的概念，其中包括由于这些工具间的不同导致的阻力。让你的工具协作起来有很多的好处，所以发起一个集成项目是很值得做的。但不可回避的现实就是集成真的很难。所以在签发下一个内部集成项目之前要充分考虑隐藏的“陷阱”，避免由于漫长而昂贵的失败项目导致低效和缺乏可见性。
作者介绍Betty Zakheim，Tasktop的行业战略副总裁。她的职责是充当Tasktop客户、公司产品团队和市场团队之间的枢纽。她有广泛的软件开发、软件集成技术和软件开发工具背景。作为软件开发经理，它是“迭代开发”的早期“适配器”以及敏捷的先驱。作为InConcert（已被TIBCO收购）的产品管理和市场副总裁，她倡导使用业务流程管理（后来称为“工作流”）作为企业应用集团的语言框架。她具有心理学、广告学本科学位（由纽豪斯公共传播学院颁发），并是计算工程领域的Tau Beta Pi荣誉协会学者。她还收到了波士顿大学的计算机科学硕士学位。