What's that? Your product is the code and the code is the product and automation is your middle name? How nice. You're the digital 1%.
Remember the hand wringing over the digital gulf between rural and urban Americans? We may not hear about it as often, but a big chunk of the population is still lucky to have 5 Mbps Internet links and thinks Between Two Ferns is an ironic hipster bar. Only a select few get to debate the merits of Google Fiber versus Verizon FiOS.
The latest iteration of the digital divide is happening inside corporate IT organizations. It's between companies with an Agile ethos baked in and those with more conventional IT shops. I recently attended a roundtable where Alan Shimel, editor in chief of DevOps.com, led a discussion on topics including whether the title “DevOps Engineer” is (or should be) a real thing, why DevOps is the last best hope for information security, and the concept that anyone can write Chef code.
We all need something to aspire to.
DevOps, in case you haven’t been paying attention, is the practice of adding Agile principles to the full IT lifecycle, ending the practice of developers writing code in a vacuum and then throwing it over the wall, leaving the operations team to figure out how to efficiently run it. DevOps is a great idea. InformationWeek's 2014 DevOps Survey shows it has traction, and it will likely be, if not the last hope, very good for security.
However, you have to wonder what the CIO of a traditional enterprise with a portfolio of 1,200 products, 16 datacenters, a few hundred branch or retail locations, and a few dozen just-won't-die legacy applications that have been running for 20 or 30 years is going to do with all this agility angst.
Purists may mock the term "DevOps Engineer," but there's no doubt hiring managers are looking for this expertise.
Andi Mann, VP of business unit strategy at CA Technologies, coined the term "big DevOps" to describe just that conundrum: Large, complex organizations that have been around for decades will have a difficult time adopting DevOps. In fact, what they eventually do may not look like “pure” DevOps at all. Yet they badly need the collaboration, flexibility, and speed of execution continuous improvement provides (Mann’s presenting on the topic at the InformationWeek Conference).
IT's seen this adoption gap before. “We could say the same about SDN, cloud, or big data analytics,” he says.
What’s different here is that you don’t need to buy new technology to start along the road to DevOps. It’s about a new way of working. Eventually, CA and other providers of automation suites do expect DevOps to bring about a renewed push to automate IT processes and software release cycles, which is certainly a worthy goal (and a revenue opportunity). For now though, DevOps is about process improvement, a change that’s badly needed anywhere ops teams still impose an iron fisted “stability uber alles” status quo.
[ Join Michael A. Davis on April 1 at the InformationWeek Conference for our workshop, The DevOps Challenge. ]
Today Mann says most of CA’s Fortune 2,000 clients are doing DevOps in small pockets, picking their spots carefully. “No one is using DevOps on their ERP,” he says. Where else DevOps isn’t happening: Core banking systems, companies looking to maintain ISO 270002, and those subject to strict audit controls where separation of development and IT operations roles isn’t optional. In other words, places where constant change isn’t your friend.
Still, if you want to be Netflix instead of Blockbuster, you can’t avoid continuous improvement for long. Mann cites a recent survey that shows adoption of continuous delivery principles helped respondents bring new services and products to market 20% faster. Our own DevOps Survey provides a snapshot of adoption in larger organizations -- 27% of 318 respondents (all familiar with DevOps) have 5,000 or more employees; 20% are over 10,000. Twenty-one percent have implemented DevOps, and another 21% expect to within a year. Top drivers: the ability to deploy apps faster with less downtime and overall improvement in infrastructure stability.
There’s no doubt enterprises differ from the web companies that have pioneered DevOps. But you don’t have to be Netflix or Zynga, rolling out dozens of code updates daily, to benefit from getting apps to market faster and being more flexible in meeting customer demand. A natural entry point is in the team that's developing mobile apps. Consumers of mobile apps expect frequent updates, says Mann, so the DevOps concept of dropping one new feature at a time, seeing how it works, and circling back fits.
Don’t feel you need to get religious about the DevOps concept. If you can get your developers and operations team working together on some projects, don’t worry if certain systems stay off limits. “This DevOps branding feels a lot like how Scrum takes the concept of agile and makes it rigid,” warns one IT pro in our survey.
Finally, Mann says, bring business units into the process. “DevOps does not start with dev and does not end with ops,” he says. “It must start with planning. The business must figure out where to apply these principles.” Can you afford to manage another 35,000 lines of code? Do you have the discipline to continually improve?
If not, maybe it’s time to question your culture.
Engage with Oracle president Mark Hurd, NFL CIO Michelle McKenna-Doyle, General Motors CIO Randy Mott, Box founder Aaron Levie, UPMC CIO Dan Drawbaugh, GE Power CIO Jim Fowler, and other leaders of the Digital Business movement at the InformationWeek Conference and Elite 100 Awards Ceremony, to be held in conjunction with Interop in Las Vegas, March 31 to April 1, 2014. See the full agenda here.
Lorna Garey is content director of InformationWeek digital media. View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.