Do we still need to stop and define DevOps as a methodology, practice, tactic, approach and/or portmanteau in and of itself?
Whereas we might have justifiably suspected the IT industry of spin doctoring up a new term simply to ply its wares, the number of genuine DevOps postings on IT job boards is proof enough for most that this new Developer + Operations DevOps role does indeed exist.
That being so, we still appear to be looking to pin down and define DevOps today — so TechTarget’s own definition takes some beating:
“DevOps is a philosophy or cultural approach that promotes better communication between the two teams as more elements of operations become programmable. In its most narrow interpretation, DevOp is a job description for an employee who possesses the skills to work as a both a developer and a systems engineer.”
DevOps is a cultural approach
A “cultural approach” is good isn’t it? If we say that DevOps is a “social attitude” even… is that acceptable?
This might be too touchy-feely for the enterprise IT industry, but then again it might not.
There is now, in 2014, more (arguably) more noise coming out of CA Technologies in this space than most other companies.
Even firms that previously sold themselves heavily on being specific developer to operations orchestration (and/or service management and perhaps some ALM too) specialists (think Serena Software for example, but also BMC and ServiceNow) are falling by the wayside in terms of share of voice… or so it seems to be so.
CA’s latest DevOps spin (okay sorry, it’s not spin, it’s real) is to talk about the Dysfunction Junction.
According to CA “Getting Dev and Ops on board and heading in the same direction can be difficult. But first, you have to recognise if your teams are on different tracks to begin with.”
The firm lists some of the warning signs of a dysfunctional process (and therefore a need for formalised DevOps) as including:
7 warning signs
1. You don’t discover software defects until late in the lifecycle–or worse, in production.
2. You use Agile to speed development, but any gains evaporate once the app goes into production.
3. Your developers and testers are constantly waiting to access the resources they need, causing delays.
4. You can’t pinpoint problems across development, testing, and production operations.
5. You see simple human errors wreaking havoc during development and deployment.
6. Development views their job as finished once the app is in production.
7. Anytime a problem arises, everyone starts pointing fingers to lay blame on someone else.