The term “DevOps” has a hybridized, geeky-ish ring that will never be understood by the business at large. But, ultimately, DevOps could make or break the business. Why? Because many companies — especially in today's insurance sector — now hinge their fate to information technology, and the ability to respond to markets and customer needs in a rapid manner. Some sectors of the industry, such as life insurance, are locked in competitive battles for customers not seen in decades.
The rapid delivery of products, solutions and information is key. Companies need to digitize as much of their operations, relationships and channel delivery as possible to be competitive.
There are two sets of people who are delivering digitization on such a grand scale to organizations: the developers, who create the code that runs these new applications. Then there are the operations teams, who make it all run smoothly, and help work out any bugs.
The problem is, developers and operators don't work alike, and don't even think alike. Developers tend to be free spirits, working through the night to get what they need to get done. Operations people tend to be task and schedule-oriented, focused on the day-to-day needs of the business, and making sure solutions are running when business leaders and managers expect them to be up and running.
DevOps has its roots with Toyota a few decades back, when managers realized that their car designers weren't working in sync with production people. DevOps is more than a merged process — it is a meeting of two separate cultures to work out how new innovations will be quickly surfaced.
So what's the best way to bring about DevOps? NetworkWorld's Brandon Butler outlines three key steps. And for anyone in the IT management space for any appreciable length of time, the ways to get DevOps started in enterprises shouldn't vary that dramatically from other initiatives:
1. Get top-line support. This is always the key to any and all business technology initiatives. Sometimes grassroots or bottom-up approaches catch on, but DevOps requires a restructuring of workflow and change in organizational culture.
2. Don't try to boil the ocean. “Identify small areas where developers and operators can work more closely together,” Butler advises, while also noting that the reason DevOps is needed is because developers and operations people tend to work in their own silos. “Perhaps DevOps could be used for new, cutting-edge initiatives within the organization, not as a replacement for the core development efforts. Identify two or three big-picture, overarching goals that everyone can aim for, then there’s a more likely chance to show tangible results.”
3. Pay attention to security considerations. The security equation changes in a DevOps world. Security practices will need to get baked into ongoing work versus being assigned to a quality assurance group at the end of the process, Butler says. DevOps entails “rapid development, testing, and deployment,” which moves “QA from the end of the process to the beginning of the process.”
Joe McKendrick is an author, consultant, blogger and frequent INN contributor specializing in information technology.
Readers are encouraged to respond to Joe using the “Add Your Comments” box below. He can also be reached at joe@mckendrickresearch.com.
This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.
The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.
