Once you’ve encountered (yet another) cause to become conversant in the language of software, and particularly “agile” development, you’ll bump into this companion term: “DevOps.”
“DevOps” is an industrial sniglet — a pairing of “Development,” as in product development, and “Operations,” as in keeping the whole operation up and running.
People who work in product development are rewarded when existing products are improved and when new products get to market swiftly. People who work in operations are rewarded when everything just keeps working.
No wonder: Prior to “DevOps,” product-development people viewed operations people as barriers to progress, and operations people viewed development people as pesky rogues, always armed with a swell new way to brick the network.
“DevOps” is part cultural spasm, part management renaissance. It’s a movement, usually growing out of an earlier decision to “go agile.” The point of it is to make sure the people who are building the machine actually use it — and to give the people who maintain the machine a say in how it’s designed. Continuously.
When people explain DevOps, they say “over the wall” a lot. A product spec gets tossed “over the wall” to operations, which vets it for deployability, then throws it back over the wall to its developers, to fix this or that.
DevOps removes the wall. It does so by building intangibles into product design: Is it deployable? Does it scale? Can operations do it? It’s all about empowering people to get things done, by removing what can be layers of processes — permissions, approvals, and “adminis-trivia.”
Ultimately, DevOps recognizes that the opposing forces of change and stability are both vital to a company’s success. Its reach is wide, and it’s probably headed your way. Best get limbered up.
Stumped by gibberish? Visit Leslie Ellis attranslation-please.comormultichannel.com/blog.
