Having DevOps as a separate function within an organisation has its caveats. Consider the traditional DevOps problem, a driving force behind the DevOps movement:

Developers do not know where their code is running, or how it gets there.

System administrators do not know how the code they are running works.

One of the fundamental ideas of DevOps is to bridge this gap - make sure developers and system administrators talk to each other, and share information and the responsibility of delivering value. It does not mean developers should be patching kernels, or that system administrators should be writing Javascript. It means they should know how each other operates, and use this to work better together.

If DevOps is built as a separate team or function between these two groups, taking on responsibilities such as code deployment and monitoring implementation, it will inevitably end up being an island. Yet another silo of specific skills and knowledge.

A better approach is to think of DevOps as a centre of expertise; a specialism that is in charge of coaching the rest of the organisation in implementing DevOps tools and practices.

A DevOps team can deliver specific tools to help developers, ops and QA work better together - while ensuring there are resources in place to maintain and develop these tools going forward. When direct delivery efforts are being made, the DevOps team should understand the operating environment and the problems that they are fixing, and all groups should be feeding into the process.

So, what is a DevOps Engineer then? As always, that depends on the organisation. In my view, a DevOps Engineer should be someone who drives efforts towards adopting DevOps, by building tools and even more importantly, helping the rest of the organisation understand why DevOps is crucial.