Jeff Schneider has delivered the same core message to more than 500 companies over the past 16 years: that IT planning, continuous delivery and automation are the path to better software.
As CEO of MomentumSI, an IT consulting firm based in Austin, Texas, Jeff helps teams overcome obstacles to aligning IT with their business needs. A big part of that is getting IT and software teams to communicate better — and much earlier in the software development process.
What’s the Problem? Depends on Who You Ask
The IT-business alignment problem looks different, depending on which lens you look through.
“If it’s the people on the application development side, the emphasis is on continuous delivery and releasing software faster,” Jeff says. “The two things developers consistently request are the creation of a continuous delivery pipeline and a self-service capability for getting the software they need. They want platforms on demand and don’t want to fill out forms and wait days or weeks.”
Infrastructure and operations teams have different concerns. “They’re trying to keep their software consistent across tens, hundreds or thousands of machines. The only practical way to do this is via modern automation,” Jeff said. “IT managers have different concerns — they want to lower the sysadmin-to-server ratio, and keep costs down without negatively affecting service delivery.”
From the executive suite, software delivery issues look like a silo problem. “They’re seeing that development managers have one agenda, and ops manager have another. The CTO or CIO’s job is to pull it all together, to get it more consistent and efficient.”
In each of these situations, the answer is to help people understand that the old-fashioned silos need to come down, and to focus on delivering software in a more agile fashion.
“Traditionally, architects think about availability, scalability and performance,” Jeff said. “But there are other non-functional requirements that ops teams are very interested in, like live patching, application portability and security concerns.”
If ops concerns aren’t addressed early on, they play out as problems that are harder and more expensive to deal with after a system has gone live. That’s why ops people need to be at the design meetings, and why Jeff is glad that growing awareness of DevOps has moved operations concerns front and center, “as they should be.”
IT Thinking Evolves as the Market Changes
A few years ago, Jeff saw large companies hiring Agile experts to help plan software projects. That was great for software project managers, but it didn’t help IT ops do their jobs better — nor did it facilitate communication between dev and ops teams.
The difficulty of delivering software faster, with fewer errors, has turned companies’ attention to DevOps. The improved communication and planning that result from DevOps practices bring better business results — and managers are taking note of that.
“The DevOps process improvement consultants think about how to change things across the silos,” Jeff said. “They rethink the methodology, and how things are handed off between the silos. They are your silo busters.”
Organizations that want to do continuous delivery, and want to do it well, have to invest in continuous testing, he said. What this really means is shifting from manual testing — that is, hiring a roomful of low-waged people who try to break the software — to having a test engineer design an automated testing suite.
Automating the test process eliminates many common errors, and enables continuous testing. That, it turn, means companies can deploy more frequently, and with much more confidence in the goodness of their code.
Automation Planning Makes Continuous Delivery Possible
Jeff said that doing continuous delivery right means bringing a Puppet expert into the software design project from the beginning.
“Organizations that are correctly implementing continuous delivery are pulling in the Puppet experts early in the lifecycle so they can treat architectural elements — such as databases and web servers — as modules that can be easily deployed and re-deployed.”
While Agile awareness brought welcome improvements to the software development cycle, growing awareness of DevOps brings a special benefit that’s important to Jeff.
“For the first time, developers and architects are gaining an appreciation for the ops teams’ jobs,” he said. “The more they understand the pain they’ve caused by throwing code over the wall, the more they understand how they’ve created architectures that are expensive to operate.”
That understanding, and the sincere desire to right past wrongs, should result in much better software — and better working conditions for everyone.