DevOps Done Right, the First Time

Arthur Cole
Slide Show

Digital Integration: Overcoming Enterprise Data Challenges

The benefits of converting to a DevOps model of IT operations are becoming plainer by the day, but the process of converting today’s management stack to an agile architecture is still mired in confusion.

DevOps alone, of course, will not make you agile, but it is a key enabling technology that allows for much of the continuous development and IT automation that will finally allow organizations to shed the hands-on control of data infrastructure to focus on more productive activities.

In today’s fast-paced economy, DevOs will not only be the preferred means of pushing new services to users, it will be the only way. As Datamation’s Andy Patrizio notes, the six-month or more time lag between request and fulfilment for new services simply will not cut it, particularly now that the cloud has provided a convenient alternative to IT. Under a DevOps model, everyone with a stake in the application – which includes developers, users, infrastructure managers and even the bean counters – gets a seat at the table to determine the scope and nature of the project and its implementation within the data ecosystem. In this way, services not only play a more pivotal role in the business process, but multiple eyes can track their progress to see exactly how they can be made more relevant or powered down if necessary.

This is not simply a change in technology but a new way of conducting business, which ultimately produces changes to the entire culture of the enterprise. As such, the transition is much more complicated than previous IT upgrades, with an entirely new class of hurdles to overcome. According to Cloudbees’ Brian Dawson, the move to DevOps requires buy-in from the front office to middle management to entry-level business and IT associates. The best way to do this is to start small and produce tangible results that clearly demonstrate the benefits to everyone involved, whether that is in easing the workload, reducing costs or expanding markets and revenue. From there, you can then scale DevOps across multiple teams and business processes, and before you know it, knowledge workers will start to look at today’s IT operations as practically primitive.

Of course, it is easy to say “scale up the program” but quite another matter to actually do it. Computer Weekly’s Caroline Donnelly says one of the first things the CIO should do is establish the KPIs and metrics to measure success and demonstrate it to others. In this way, organizations can build on what works and quickly dispose of what doesn’t before it sours the workforce on the whole concept of DevOps. You should also expect strong resistance to change, particularly in large organizations, and the inevitable setbacks when integrating DevOps with legacy processes, all of which makes it imperative to maintain a consistent vision and a deployment model that focuses on improvements to the business model, not just the deployment of new technology.

With DevOps being such a new phenomenon, it is difficult to gauge when things are going well, although there are signs when you are doing it wrong, says Scale Venture Partners’ Andy Vitus. For one thing, if you find yourself building automation and test scripts only after you’ve begun to scale, you are already behind the curve. As well, the “build it and they will come” mentality will not necessarily work this time because DevOps does not improve on the status quo as much as upend it completely. And since the new processes work hand-in-hand with automation, many workers already view it as a threat to their jobs.

This change is inevitable, of course, because organizations that don’t embrace agile development will soon find themselves out-performed by those that do. This is why a successful DevOps deployment is probably the single-most important initiative on the CIO’s plate these days – more so than the cloud, containers or virtually any other technology currently flooding the channel.

With DevOps, IT becomes an equal partner in the business model, which makes it essential that you get it right the first time.

Arthur Cole writes about infrastructure for IT Business Edge. Cole has been covering the high-tech media and computing industries for more than 20 years, having served as editor of TV Technology, Video Technology News, Internet News and Multimedia Weekly. His contributions have appeared in Communications Today and Enterprise Networking Planet and as web content for numerous high-tech clients like TwinStrata and Carpathia. Follow Art on Twitter @acole602.

Add Comment      Leave a comment on this blog post
Jul 12, 2016 12:00 PM Ron Ron  says:
Love the article! couldn't agree more with the key claims around the mentality and the danger of placing too much hope in "build it and they will come" but even more so on the issue of scale. Part of the reason this "production cliff" is so hard for organizations to cross, let alone scale is an inherent issue with the toolchain. that is that each tool in the chain (CI, Test automation, release etc...) is built from the technology silo it was designed for and the CD process isn't accountable for - this makes scaling an issue and also caters for all sort of Rube Goldberg constructions when organizations hit the wall and start forcing all sorts of integrations.. this is why I believe a good orchestration platform must be at the core of any enterprise DevOps initiative. Reply
Jul 14, 2016 3:30 PM Betty Zakheim@Tasktop Betty Zakheim@Tasktop  says:
To ensure DevOps is done right the first time organizations should first define the term. Then they should outline metrics that allow them to objectively determine whether they are achieving their goals. We all agree that DevOps represents a culture of cooperation across the development and operations teams. But differences emerge in the interpretation of that concept. For some, doing DevOps is limited to automating software delivery from the version control system, through build and test and into production. For them, metrics such as “the velocity of software deployment once the version control system has code updates” clarify the DevOps transformation goals. In this case, they don’t include upstream activities, such as code development or determining the code to develop. For others, DevOps is more holistic. The cycle time starts with either the business need (such as the creation of the epic, requirement or user story) and ends when that business need is deployed in production. It’s insufficient to say that DevOps initiatives should allow us to deploy software at will. We need to define what that entails so the entire organization is clear on objectives and if they’ve succeeded. Reply
Sep 14, 2016 12:12 AM kartik kartik  says:
I completely agree with Arthur cole what he said in the above article is true. DevOps is the fastest evolving technology around the world. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.