现代商业流程越来越紧密集成：运输、制造和财务紧密结合为客户交付增加的商业价值，从而减少了费用。在过去40年 里，自动化让商业流程得到进一步发展，它将各专业工具和实践集合成为一个整体价值链。客户往往希望只需提供完他们的 信息一次；并随之假设你们的技术支持了解他们及他们产品的一切，并期望随之的交易是直接的，并私人化。尽管如此，用 于创建和维护这些自动化系统的流程却比它们支持的系统来得更加分化和无系统。典型的软件交付项目会无数次地去获取需 求，并在多个地方描述测试，但它们却与某一特定的构建里的具体内容并不相符合，因此项目往往需要大量分析来获知谁在 做什么以及为什么做。软件生命周期管理（ALM），软件交付流程要比它所支持的商业流程不成熟得多。但是软件流程已经 从辅助的商业流程升级为不可或缺的，它要求软件公司快速并直接地向客户交付高质量的产品。这意味着软件交付组织或团 队必须开始考虑如何更好地集成他们的交付规则，设计出一个整体的、集成的ALM方法。
集成价值难以评估，但如果 没有它，项目则无法成功
你曾多少次经历过这样的会议：每个人都在困惑地讨论着一些类似相同、却又不完全相同 的东西？或者在会议的前３０分钟大家都在忙于弄清会议的内容？而且如果会议包含了来自不同部门、地域或组织的人，问 题则会更加严重。现代软件交付团队是由来自多个不同地方的人组成，其中包括：开发部门，项目管理部门，商业部门，以 及外包的测试机构。每个组织都采用自己特定的工具集，以及自己的实践和流程，而且这些全都根据自己团队内部，而非在 端对端上进行优化。组织间的协作往往是项目当前运行团队的责任，比如：当项目主要由开发团队来运行时，开发团队负责 分享故事和任务。当测试是主要关注点时，缺陷和问题则是沟通桥梁。而当单一团队在驱动某个阶段时，往往忽略了之前所 有的工作，并排除其他团队的工作内容；团队间的空缺则由特定流程、电子表格和wiki来填补。其结果就是徒然的、让人气 恼的会议；更重要的是，需要解决的问题往往被忽略了，从而导致了差劲的软件，不断增加的缺陷，以及昂贵的项目延迟。 将所有人“集成”起来往往因为以下几个方面被否定掉了：
所有权--规定谁来负责某一领域的提高是简单的，但又有谁来负责两个领域间的交互呢？比如：应该由谁来负责提高开 发和测试间的关系呢？没有明确的所有权，提高是非常难的。
地域上、组织间、以及政治上的边界--实际上，任何一个大型组织的组织架构在被管理和政治边界控制的同时，都在不 停地演变。而想要打破这些障碍则非常难，因为我们所追求的东西如同协作一样无法具体掌控。
度量--软件交付一直被标榜为拥有差的度量，就连有限的度量通常也只关注某一特定领域，比如只关注测试，开发或计 划其中一个。集成由于其自然特性难以度量，但没有一个明确的度量，又很难去关注或提高它。
惯性--改变从来不简单--它总是不确定，还有由于对来自领导层的低效改革的负面体验，大部分员工对它都怀有偏见，
管理和合规需要依靠一个综合的观点
不论组织多大，意识到任意时刻发生了什么，针对对象，时间以及涉及人员 对于审计和合规是至关重要的。随着工作不断分配到各个部门，软件产品，流程，及具体人员，对任意一个或一组行为进行 协调改变都将变得越来越难。举个例子：一个针对系统各项的安全需求涵盖了代码，测试，工作项，缺陷，可用软件，以及 操作票等方面。如果该需求在中途发生了改变，一般很难度量到底是什么时候以及为什么发生了，更别说解决它所带来的影 响。如果改变仅存在于代码中，那就会造成合规问题。就算组织不用遵守特定的政府规定，也应对影响、可追踪性和流程控 制的有一份明确的度量来管理他们的流程。而可追踪性会被以下几点削弱：
用于存储信息的工具互不衔接。每个工具都存储着各自的中间文件，通常围绕着历史和版本管理有自己明确的机制。但 是随着工作不断往不同部门延伸，中间文件间的联系却断开了。
可追踪性管理是笔巨大的费用。文档记录两个事物间的关系并不特别费时，但是随时更新那些具体度量和链接却很困难 。
可追踪性元模型。项目中，当我们努力地在规定期限前提交软件的时候，创建文档看起来并不具有优先级。跨团队/工件 间的文档纪录则更难找理由来贯彻执行。由于没有花费足够的时间来理解工作产品和文档因素间的关系，很难提供可追踪性 ，更别说去判断是否需要它们。每个项目都是不一样的，加上对敏捷方法的应用，项目可能会根据不同的问题领域或团队执 行自己的流程。