DevOps should be about good decisions, not faster cycle times

DevOps may help get applications out the door and into production in a fast and furious manner, but that's not what makes such collaboration successful. Success is seen in the quality of the decisions made, and to achieve this quality, teams should be free to operate as autonomously as possible.

That's the word from Mark Schwartz, enterprise strategist at Amazon Web Services, author of A Seat at the Table: IT Lesadership in the Age of Agility, and a former federal government CIO. In a keynote address at the recent DevOps Enterprise Summit event, he observed that the best DevOps initiatives are those that strive to meet objectives, not requirements. Too many IT teams get locked into addressing the requirements that go into a business case, whereas they should be freed up to pursue overall objectives, he states.

This is the true essence of agility and flexibility. Teams, working in the trenches with business end-users, not being hamstrung by centralized corporate decisions. "With traditional way of making investment decisions, you would translate objectives into a bunch of requirements, and then you would put all those requirements into a business case, and then try to execute those requirements," Schwartz explains. "This is a little strange if you think about it, because adding those requirements actually adds risk to the project. You've now added the risk that your requirements are not the right ones."

By locking into requirements, "you've also tied the hands of the innovative people who you want to be thinking of good solutions," he continues. At AWS, he says, "instead of creating requirements, we just took those objectives and pass them to teams directly. so we would create a team that was a cross-functional team -- it included developers, operations and infrastructure people, testers, security people, and business operations people."

Ultimately, Schwartz states. "the important thing to realize is shrinking cycle times is not about doing things faster. It's not about the speed. it's about the quality of the decisions. When you put DevOps into an enterprise, it's not just about how quickly you can get stuff to market -- although that's important -- it's about how can your central organization still have good control, and still make good decisions while the action is moving really fast both in the business context and in the DevOps process."

In IT, Keeping the Lights On Paves the Way to Innovation

Schwartz also sought to dispel the widespread notion that there was a difference between IT maintenance spending and innovation spending. "We've had this myth in the IT community for a while that we have two kinds of costs in our IT budget," he says. "We have keeping-the-lights-on costs and we have innovation costs, and all of us say innovation is where we want to spend our money; maintenance is not where we want to spend our money. I disagree. I think a lot of what goes by the name of 'keeping the lights on,' a lot of that maintenance stuff is actually innovation work. It's actually what's advancing the business; it's actually what's changing the IT systems to keep them consistent with what the business needs."

Software doesn't need to be maintained "the way you have to maintain a car to make it keep functioning the way it always did," Schwartz explains. "Software keeps doing exactly what it did when you bought it. You don't have to put money into it to make it keep doing that. The problem is you never want software to keep doing what it did when you bought it, you want to keep changing it as your business changes. So the maintenance or keeping-the-lights-on spend to a large extent is remaking the decision that this is the right software for you to use, and making changes to it as you need to."