达成理想的 SCCM 解决方案
任何一个 SCCM 系统的目标和关键请求都将随着单个用户的角色和任务而变化：
从一个开发人员的角度来看，一个理想的 SCCM 解决方案必须
.低调但是用起来很方便。
.允许开发人员从事一个或者更多的活动。
.赋予他们同时处理不止一个工作项目的能力，但是每个工作项目之间不能相互影响。
.将同一次确定的变更记录的决定与其它变更记录联合起来。
.使它们的代码能够被测试快速且方便的利用。
.记录请求，使它们能够清晰地被理解（XP/Agile）或者定义（RUP）。
.管理合并——例如，只合并那些实际上需要被集成的文件。
.从一个专门为每个开发人员安排的“待办”列表的工作项开始做（也会允许这个管理人员优先选择工作条目）。
从一个开发团队领导或项目经理的角度来看，理想的 SCCM 解决方案必须
.容易接受，评估，以及管理变更请求。
.容易分配工作项目或者将一个工作拆分为适合小组或者目标交付的细节的更小的单元——例如，单个的工作可能需要被拆分为更小的单元，因为小组能力，时间限制，或者最初工作条目目标交付灵活度的原因。
.区别哪些工作项目是完整的哪些是不完整的。
.简单地为一个构建安排工作条目的测试和包含内容。
.在各种不同的参差提供可视化，包括项目的状态，发布版本，组件，以及单个变更。这包括管理报告，比如小组成员中变更记录的分配，故障确定的平均时间，等等。
.为单个开发人员的工作和进展提供可视化展示。
从一个业务分析师或经理的角度来看，理想的 SCCM 解决方案必须
.允许他们请求或登记新的需求。
.允许按照人员、成本，项目状态等运行报告。
.使他们的客户保持与新发布版本进展的步伐一致。
实现一个供应商的 SCCM 解决方案
所有的软件开发组织都希望 SCCM 解决方案是可扩展的、灵活的、适应能力强的，包罗万象的，并且能够从单一的即将适应现存开发方针和过程（以最低的可能成本为标准）的供应商那理想地提供整个工具（包括穿越测试和部署过程的请求定义）的组合。首先，整个驱动器要避免制造和维护集成，并且实施了可靠且经过考验的不会把集成拆分为新的版本更新解决方案。
通常有这样一种说法“如果我们能够从一个供应商那购买我们自己的完善的开发环境，我们将成为最好的，”但是事实上这种情况很少发生。原因各种各样：每个产品的影响力都有它们自己最喜爱的供应商和产品；以前遗留下来的工具深深地扎根于组织中，使它们很难被迁移，随着时间的流逝新的工具进入这个市场，使用带有优于上个月“选择的工具”功能的现代技术。无论您怎样看它，对于大多数组织来说，实际上是一个软件开发产品的混合。
当今 SCCM 市场中供应商的解决方案
在当今软件开发的市场中，存在以下类型的供应商：
1.单个的旗舰产品，对于 SCCM 组合的其它方面有着潜在的集成
2.来自声称要无缝地进行集成供应商的多个高端产品
3.针对端到端 SCCM 的一个产品供应商解决方案
4.单一授权，包含全面的应用系统生命周期管理（Application Lifecycle Management，ALM）解决方案
5.在远程服务器上托管的解决方案；例如，软件即时服务（SaaS）
其实有很多种选择，任何一个决定都可能是令人吃惊的且十分困难的，每个都有它自己的优势和缺陷。如果您今天开始启动一个开放团队，选择上面的4和5听起来都是明显的选择。但是这些选项的问题是一个解决方案不能满足所有的问题。不可避免，许多组织将会认识到一个可选择的产品能更好地部分满足他们整个的解决方案，他们正为他们将不再使用地部分解决方案买单，或者说这个解决方案对他们的首选的开发技巧来说还不够灵活（XP，敏捷的，迭代的等等。）。这种“不确定” ALM 解决方案得真谛是，所有的客户都不同，因此转化为 ALM 系统中的功能越多，它就越难适应和自定义满足过程和每个客户的解决方案。最好的 ALM 解决方案十分轻巧，而且允许客户调整或者将它们与其它产品集成在一起。
没有人愿意为每个软件开发项目使用一个不同的产品或者供应商，但是如果不从可利用的高端工具广泛的选择中尝试大量不同的产品就很难找到理想的工具。其中的挑战在于需要更紧密更干净的集成。理想的世界应该是，不管潜在的是什么样 SCM 产品，都有一个共同的界面。
SCCM 方针实施者的挑战
在过去的两年内，我们看到了软件开发所有参与方的一个态度转移。历史上，共识都将严格地保护所有的源代码，并严谨地支配它如何被管理。近年来，软件开发技术建议，捆绑地越紧，就越难使它成为及时的，预算之内的，并且达到高质量水平的开发产品。
随着产品上市压力的增加，开发人员不可避免地会花更多的时间进行开发和测试，并跟随他们所认为的官僚的压力，包括复杂的工具和集成的 SCM 构架。相反，Subversion 的开放性开发人员下载并开始使用它在不需要寻求批准或者授权的情况下进行有效地执行公司的方针。 传统的 SCCM 方针实施者想要保持一个干净的过程——是有原因的——但是通常会发现他们自觉没有权力作为开发人员来干涉这个问题。事实上，他们通常拥护这个变更而不是与它作对。
像 Subversion 这类的工具通常会利用最基本的和必要的特性来处理最小量的业务和开放需求。如果他们能够与被核准公司解决方案集成在一起，而且这个方案能够提供所有的备份，安全性，以及为满足一致性指导方针所需的请求，为什么不允许开发人员使用更快速，更有效的工具呢？
