在軟件開發過程中會遇到許多各種各樣的需求，設計文檔，也會碰到許許多多的源程序，為了更好的找到東西，人們使用了不同的目錄和文件名，但是人們很快又發現，就算是同壹個文件也會需要不同的內容，於是人們又發明了版本，來表示壹個文件不同歷史時期的內容，這就是標識。但是很快人們又發現了新的問題，總是發現某個文件不知道什麽時候變成了另壹個樣子，於是人們便覺得需要有壹個方法來控制壹下，不讓文件隨隨便便的被修改，於是就提出了變更控制這個說法。
所以我們知道了配置管理的作用就是讓正確的人得到正確的東西。
隨著研究的繼續，以及使用和組合概念的經驗，許多新武器將會加入進來，這意味著有可能CM系統將會獲取壹組新的基礎CM服務來滿足用戶的需求。但是，不考慮是否每個CM系統設計師正在努力實現相同的特性，始終有壹些政治和技術問題影響著CM系統的未來。（政治問題關系到市場和標準；技術問題關註實現特定機制的可行性。）
壹個主要的政治問題是電腦輔助軟件工程（CASE）工具的演進。例如，是否CASE工具零售商會回避用他們的工具範圍內實現CM，並且假定環境零售商將會在它們的框架中提供CM支持？如果CASE零售商與其自己的CM工具支持綁定，當用戶安裝它們的CASE工具時，將需要解決集成不同CM 系統的問題。同樣，從零售商的角度，他們會從本質上重復解決許多環境框架解決的問題嗎？
另壹方面，如果CASE零售商不將CM工具組合到工具中，他們可以依賴CM環境工程提供合適的框架來集成CASE工具，並且同時提供壹些全局性的CM功能嗎？沒有人知道這些問題的答案。在任何情況下，CM系統與環境的關系有壹種隱含的標準，反之亦然。
許多技術，研究問題影響CM系統的能力，類似的問題正在上升。構建CM系統基礎的合適技術是什麽？壹個支持對象持久化的面向對象數據庫是否合適？什麽級別的環境是CM合適的？它在數據庫中必須是基礎級別，環境框架的集成部分嗎？或者是將CM指定為架構中的較高等級？CM的機制是否可以與CM 功能分離，也就是是否有標準的CM原型可以用在所有的環境來支持所有的CM功能？是否有壹個統壹的CM模型？是否可以支持分布式的CM支持？地理位置分離的團隊是否可以使用同壹個CM系統來進行本地CM和系統集成？這是業界，特別是國防部的協議中的主要問題。是否有可能支持跨軟件開發？工程師是否可以在主機開發壹個產品，並在維護中同時發布到目標機器？標準是否擴大了CM系統的限制？是否CM同樣的支持壹個百萬行代碼的產品和壹個上億行代碼的產品？是否可以對CM過程的所有方面，包括用戶敏感的部分建模，並在CM系統中實現？
以上問題的答案還不清晰，進展很有可能會源自各個方面－－從CM系統零售商，環境架構師和研究員，工具集成員，軟件過程建模論壇和電腦輔助設計/工程，電腦集成生產商世界。