将来，运维工程师的角色将更加接近软件开发人员的角色，但是他们的职责仍然有一些区别。以前，运维工程师不需要像开发人员那样必须精通对源代码控制系统、持续集成系统、调试及测试方法的处理及自动化管理。他们涉足的领域主要与操作系统、网络、数据层及系统架构相关，除了构建新的基础架构或Web应用环境，他们一般不需要与软件开发团队保持同步。但是，这种日子现在已经一去不复返了。现在可能还有一些专家负责处理一些特定领域，如操作系统、网络，数据库或数据存储，但是现在所有利益相关者都必须掌握这一部分

将来，运维工程师的角色将更加接近软件开发人员的角色，但是他们的职责仍然有一些区别。以前，运维工程师不需要像开发人员那样必须精通对源代码控制系统、持续集成系统、调试及测试方法的处理及自动化管理。他们涉足的领域主要与操作系统、网络、数据层及系统架构相关，除了构建新的基础架构或Web应用环境，他们一般不需要与软件开发团队保持同步。但是，这种日子现在已经一去不复返了。现在可能还有一些专家负责处理一些特定领域，如操作系统、网络，数据库或数据存储，但是现在所有利益相关者都必须掌握这一部分的专业知识。正是有了这一部分的知识，各个团队才能够互相理解对方在快速变化环境中的角色。


 
开发运维的未来发展趋势是，在某种程度上，所有人都是软件开发者，但是运维工程师会更关注于操作系统、系统基础架构和网络。为了努力实现最佳的工作效率，双方就必须达成共同认知并且完善彼此角色此举的关键就在于能否多了解一些本专业领域之外的知识，比如配置管理、源代码控制、发布管理，以及应用架构，等等。
 
然而，角色的模糊化可能会增加运维工程师和软件开发人员的工作难度。系统自动化之后，双方都必须熟知对方的职责。例如，如果一位开发人员正在自己本地的工作站上调试一个生产Web应用程序，那么他就应该能够在测试环境中部署一个修复补丁，然后请一位运维工程师批准它是否能部署到生产环境中去。这正是 Facebook日常采用的运作方式。源代码在从测试环境迁移到生产环境所历经的不同层次过程中，也会伴随着不同的相关许可策略。在这一整体过程中，不同组织可能会采用不同的方法，但大体上都差不多:运维工程师应该知道代码的含义，网站建设开发人员也应该可以独立地向测试环境推送变更结果，运维人员应该可以独立判断是否要批准这个变更。开发人员不再需要向运维团队解释整个过程，而这在以前非常费时，对快速创新与开发影响很大。现在，运维工程师有责任掌握关于代码、应用架构和软件开发周期的知识，这样他才能成为集成变更结果的桥梁，而不会充当其中的绊脚石一可是，在现今的软件开发团队看来，运维团队经常起着如此作用。