DevOps is all about trying to avoid that epic failure and working smarter and more efficiently at the same time. It is a framework of ideas and principles designed to foster cooperation, learning and coordination between development and operational groups. In a DevOps environment, developers and sysadmins build relationships, processes, and tools that allow them to better interact and ultimately better service the customer (James Turnbull).

At the time of writing, if you were to search for “devops” you would find eight results attempting to explain what devops is, one result for a conference, and one rather satirical article (although not necessarily incorrect) where the author answers the question of “how do you implement devops” with “nobody seems to know” (Ted Dziuba).

The big problem with the DevOps “movement” is that we essentially have a bunch of operations and development people promoting it and trying to implement it within their organizations. Meanwhile, those with management and business responsibilities, even if explained the “what,” don’t understand the “how.” Just because you use puppet does not necessarily mean your organization is practicing DevOps.

This shortcoming is the result of us devops proponents either falsely claiming these techniques and methodologies are new or not knowing any better. If we had something more relatable for the business people (and, by principle, we should be business-oriented, too) then I think DevOps would have more of a chance.

Well, get your product and management together because the truth is that DevOps is actually a form of Concurrent Engineering.

Concurrent Engineering (CE) is a systematic approach to integrated product development that emphasizes the response to customer expectations. It embodies team values of co-operation, trust and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel, from the beginning of the product life-cycle (ESA – Concurrent Engineering Facility).

Concurrent Engineering encompasses several major principles which just so happen to fit the definition (however formal or informal) of devops.

I’ll list them from the Synthesis Coalition here:

• Get a strong commitment from senior management.
• Establish unified project goals and a clear business mission.
• Develop a detailed plan early in the process.
• Continually review your progress and revise your plan.
• Develop project leaders that have an overall vision of the project and goals.
• Analyze your market and know your customers.
• Suppress individualism and foster a team concept.
• Establish and cultivate cross-functional integration and collaboration.
• Break project into its natural phases.
• Develop metrics.
• Set milestones throughout the development process.
• Collectively work on all parts of project.
• Reduce costs and time to market.
• Complete tasks in parallel.

By approaching the issues of devops as  concurrent engineering and implementing it as such, you open the movement to a well-researched, well-documented, and well-accepted product design philosophy. By shedding this light on the devops methodologies, this enables those of us pushing the devops movement to finally put the movement into a more business-oriented perspective.