以流程为中心的ALM套件面对现在不做的事，在将来会怎样做？

当我们想到SDLC流程时，我们通常认为它是一个一致的、同质的流程。但在现实世界中，软件开发生命流程很广泛。移动应用的SDLC必定与后端 数据流程系统的SDLC不同。如果你在卫生保健机构，你可能无法容忍一点错误；但是如果你在零售业，上市时间的压力可能比零容忍错误更重要。

一旦你设置了以流程为中心的ALM基础设施，一定要确保定义一个工作流，来满足你的方法论（敏捷到瀑布式）、你的拓扑学（大型机到移动）、你的技术（ALM套件到开源工具集），以及你的业务需求（风险控制、质量、上市时间、治理）。另外，你需要对每一个项目定义唯一的工作流。例如，你的业务营销需求可能是移动/社交/云，以及周三的部署需求和周末的应用商战的应用更新。HR系统一年只升级一次，但是因为他们影响你的ERP和SCM系统，他们需要不同的流程操作，以不同的速度，不同的控制。

当然，我们现在面临的最大的SDLC流程挑战是协调不同技术的的部署。越来越常见的需求是确保变更传到一以亚马逊/苹果/谷歌应用商店中进行更改，并在再一时间发布，而且发布的同时网站要更改，后端服务器要更改。

从第三方面添加web服务消费复杂性，一个开发社区遍布33个时区，这样我们拥有了21世纪的发布管理风格。我们的以流程为中心的ALM基础设施一定不只控制这一个，它也一定要促进这一流程。我们必须拥有支持持续交付团队测试环境的技术。我们还需要部署控制，它拥抱运维需求和产品发布时间框架。

ALM工具使项目社交交互成为可能，这些工具也应该是此解决方案的一部分。例如，如果你对于需求有疑问，那么么你会很高兴这一需求者在线上。而且发现这一创建工程同在惠灵顿很有用，因为他清楚了解应用是如何发布的，就像你在圣地亚哥开发的一样。

移动也相当重要。应用开发团队必须能够使用开发流程在所有设备上，任何地方进行交互。无论是否收到了严重错误的通知，它阻碍了创建的完成，或者在站立会议中选择了任务，还是批准了UAT发布的变更，开发人员都必须能在他们的移动设备上实施这一任务。