Anything related to emerging technologies, in this case we’re referring to DevOps, can take a while to generate widespread adoption. There’s a certain level of commitment and attention required to fully engage key stakeholders. Then, they need time to try things out, break things, fix them, and organically uncover the benefits of that technology – or in this case, that cultural practice – on the job.
However, organizations are increasingly adopting DevOps, particularly in cloud computing, and best practices are emerging. If you’re serious about unifying your software development and operations, consider this advice from Michael McClure, one of our trainers, who helped develop our DevOps Academy.
Provide a suitable investment.
When people adopt new technology, there’s naturally a high level of excitement. It’s usually a case of, this is going to solve all of our problems! Those holy grail high expectations are often disappointed because that rarely happens. At least not right away.
But too often leaders will drink that particular Kool-aid and rationalize a poor upfront investment. They’ll think of the cost savings associated with DevOps and the cloud, and erroneously assume they don’t need to budget a sizeable annual sum because of the money they’re going to save. In reality, it may take a few years of independent project use to breed familiarity and adoption amidst the staff, and actually inculcate the new technology into business operations. Underfunding can jeopardize an otherwise – potentially – successful implementation and adoption effort.
Build a governance model.
The number of services and resources organizations have to handle can become challenging to manage without a governance model. To adequately manage your DevOps, cloud and other tech resources, it pays to create policies and a governance infrastructure before you actually need them, not after. You want to have a system in place to effectively track, secure and manage all technology resources and services. The model will dictate how each service is used, when, what data is available to whom, etc.
Don’t neglect testing protocols.
It’s never a good thing for users to find performance issues in your software and then tell you about them later. You should have sufficiently tested your product beforehand because people will talk. You don’t want bad word of mouth to damage your new software’s chances in the marketplace before it gets off the ground. To avoid bad publicity, testing – preferably automated and continuous – should be in your DevOps stream long before software goes into production.
Select an agnostic DevOps tool.
The path of least resistance is not necessarily the best way to go when choosing the right DevOps tools for your organization. Meaning, choosing a public cloud provider that is tightly linked to one platform may cause problems long-term. When possible, use DevOps tools that are available or useable on more than one public cloud provider. Doing so helps to reduce both the effort required to migrate applications between clouds and the “tool overload” generated by DevOps + Cloud.
Train. It’s important.
To adopt DevOps in the cloud may require a technical as well as a cultural shift in your organization. Training can help to promote acceptance and adoption. Hopefully you have already established a learning friendly culture that will welcome the promise associated with agile software development, and embrace proactive monitoring, continuous integration and the improved communication and collaboration associated with DevOps at its best.
Key stakeholders should participate in training programs on Python, Chef, Docker, and other languages, and that training should include some type of mentoring or a comprehensive lab environment where learners can practice what they learn.
To make DevOps work, leaders should not try to make one-size-fits-all decisions, especially early on. Organizations should try things out to see what will work for them, and that includes vendor relationships. But too many organizations leave silos in place, which are like death to agile, feature-driven, cross-functional teams that need to share information to identify problems and potential solutions.
Management must be agile as well. If not, you won’t have the necessary communication paths, organizational structures, or the right processes in place to get the most ROI from DevOps and cloud technology. Your DevOps and cloud technical pieces will languish idle while ineffectual meetings are held and unrelated decisions are made.
Organizations should drive authority down through the management levels so that decisions can be made quickly and easily. Then tools like DevOps and infrastructure and development building blocks like the cloud can help shepherd in business decisions that positively influence the bottom line.
Most cultures resist this because it’s not the traditional command and control, top-down management structure. This empowers people in the lower rungs of the organizational ladder below, and it’s less predictable. Embrace it. Project plans and dates often change rapidly, and they should to keep pace with what’s happening in the marketplace. An agile culture will help.
Large, complex organizations that are looking to make a significant transformational shift to DevOps or cloud technology and adopt a learning culture that will support their integration and use may want to consider the aforementioned best practices. These can help to avoid the more common organizational snafus that can hinder implementation, adoption and tank a perfectly useful technical upgrade before it has a chance to create any benefits for the business.