Software development must align with your business-side team
Software development has become a company-wide process, with business teams now offering their input. DevOps must learn to work with them for projects to succeed.
Ask the members of an information technology software development team who owns the DevOps pipeline, and they are likely to point to themselves. After all, software is their domain and they are the ones doing the work on it, meeting the requirements and delivering the products that make a business run. That's the way it has always been done. And in an IT environment focused on speed to deployment, they have become used to calling the shots. If a DevOps team is ready to put software into production before the business side is ready, they may be tempted to just go ahead and run with it anyway.
But the world doesn't work like that anymore. At one time, the business side of an organization may have outlined an operations plan and threw it over the wall for the techies to take care of in their own way. But today, software has become so crucial to so many organizations, and so intertwined with its success or failure, that the process can't be done separately. CEOs and boards of directors are now being held accountable by stockholders for software delivery. And that makes software development an organization-wide matter, requiring input from across the entire enterprise. The technical team doesn't own it; they may be responsible for executing it, but the accountability now lies with the business side.
With security, compliance, legal issues and other factors, DevOps teams need to take a comprehensive view of software's integral role. Just as business-side bosses need to become more conversant with technical terms, IT teams now need to start thinking and speaking more in the language of business. It's a change that could take some time. It starts with challenging some long-held assumptions about software development.
Breaking down barriers between DevOps and business teams
The first realization needs to be that DevOps is no longer a purely technical domain. The change is underway in some places, as today we see DevOps merging security, privacy and ethics, to name three areas, into development. But it needs to be widespread. Developing this new mindset requires the involvement of security teams as well as others in the early stages of development. It would reflect how the definition -- and potential impacts -- of software has gone beyond the strictly technical to involve other elements of the business. For example, a team may be asked to prove that a facial recognition app is unbiased, a question with legal and business implications. Having other teams involved in development could help answer that question.
Technical teams also need to let go of the idea that risk decisions are up to them. Regarding risk and business overall, DevOps teams may have understandably tended to focus on technical questions, looking at any problem in terms of IT, while perhaps assuming that the business side just didn't "get it." That's another habit that needs to be undone. For one thing, as areas within an organization become more tech-focused, such as legal and human resources, the business side is also becoming more fluent in technology terms (if not the actual execution). Rather than making the call themselves, DevOps teams should be giving the business side options because the ultimate decisions, as well as the responsibilities, rest throughout an organization.
Managing the changing software development lifecycle
Similar to when developers collaborate with security teams to bring security and compliance into the development process at the starting gate, DevOps teams need to have cooperative relationships with other departments. In the rapid-fire environment of DevOps -- focused on the speed of development, constant testing and continuous delivery -- teams can sometimes lose track of the checks and balances that affect other teams as part of software development best practices. They might sidestep governance guidelines, skip some metrics or fail to account for risk. Incorporating security and testing into the DevOps process can deliver software that's both fast and secure. But the same approach needs to be adopted throughout an organization.
Getting to that point could take a little time. Ultimately, it's more of a sea change in management processes, starting at the top and spreading a culture of collaboration throughout an organization, as opposed to a top-down approach in which the change is dictated from above. Every element of an organization needs to work together, including the DevOps team, and that can begin with breaking down all the old barriers.
About the author
Altaz Valani is the Research Director at Security Compass, responsible for managing the overall research vision and team. Prior to joining Security Compass, Altaz was a senior research director at Info-Tech Research Group providing CIOs, IT managers, directors and senior managers with trusted advice and analysis around application development -- including Agile, cloud, mobile and the overall SDLC. Other past roles include senior manager at KPMG and various positions where he worked side by side with senior-level stakeholders to drive business value through software development.
