The DevOps concept breaks all kinds of rules. Even as a portmanteau that combines two words—development and operations—into one, it does so by clipping cumbersome syllables and just getting on with it.
In practice, DevOps does the same thing, turning old ideas on their head by extending the agile software development methodology into operations. It emphasizes collaboration and communication between developers and other IT professionals and promotes experimentation and risk-taking all in the name of speeding up the development process.
Before DevOps, developers were employing agile methods to increase speed of development, add flexibility and responsiveness to the process, and enhance the user experience, but were hindered by the fact that the end product was tested by the market only after it was in production. This meant developers received feedback a mere two or three times a year. So developers “agilized” both the development and the operation processes. This way they could enhance products step by step and benefit from speed and proximity to users throughout the application’s entire lifecycle.
Improved deployment frequency became the primary goal, and enterprises that began harnessing the power of DevOps found it to be productive. Soon, IT leaders were being told, “Go. Implement DevOps!”
But introducing DevOps into an IT environment is not simply about implementing new processes into the workflow. It requires a cultural shift toward agile by the entire IT team. What use is agile development and operation if security policies follow the traditional waterfall model, that is, sequential design, and security gaps are only closed after weeks or months of work? Organizations need multiple, frequent changes to mitigate security risks, which changes the focus from “bringing security into DevOps” to “bringing DevOps into security.”
As DevOps makes the leap to the rest of the enterprise, it will continue to swallow multiple disciplines along the way. Infrastructure and hosting departments, for example, will need to move away from simple service catalogs and toward multiple delivery models that match different deployment velocities. Many IT leaders believe they must overhaul their entire legacy application and development testing environments to reap the benefits of DevOps, so they are stuck before they have even gotten started. On the contrary, many enterprises are beginning their journey by sourcing DevOps with great success. But they are doing so by carefully structuring relationships to optimize how their DevOps contracts work with their architectural reality on the ground.
Enterprises will find that DevOps service providers—especially those that sign up for an outcome-based deal—quickly become inextricable parts of their organization and value chain. When these enterprises identify non-value-add activities and remove inefficiencies, their DevOps providers experience even fewer failures and recover faster, further improving the cycle of development.
Such DevOps-driven changes will have ripple effects beyond the IT department into areas like finance, procurement and vendor management. By first defining the existing interfaces and establishing new ways of interacting across the IT division, leaders are able to glimpse how they might leave some old and less-useful rules behind and chart a course toward a more productive future.
Feel free to contact us to discuss further.
About the author
