In my career, I've experienced a general hesitation to fully embrace continuous deployment, and in large part, the reasons are understandable. But, because technology is changing so rapidly, I believe hesitation can lead to missed opportunities – or worse, losing relevance in a fast moving landscape. If business transformation is on your agenda, I hope to convince you to take a closer look at continuous deployment to help get you where you need to go.
As an example of the “one foot in, one foot out” approach, I've seen organizations create robust internal private clouds, but then they neglect to open up the dashboard for self-service to their clients. If organizations adopt agile methods, but allow legacy compliance processes get in the way of embracing continuous deployment, the advantages of cloud automation might not be completely realized. The four-eye requirement is a standard in many organizations, which requires that no change can be made without at least two people verifying the work. But this shouldn’t preclude an agile and fast change request process that ensures the minimum amount of time necessary between test and deployment.
How do you measure success with CD?
It's not always that these organizations are simply resistant to change. Sometimes this hesitation is the result of immature financial models, which can stand in the way of creating the transparency needed for the pace of change that occurs with continuous deployment. In traditional IT, every time a change request is processed, there is a cost associated with it. How do you measure and manage costs when changes are continuous and automated?
The short answer is that, with continuous deployment, you just have to measure it in other ways. While these concerns are valid, they should not hold back companies from giving continuous deployment a fair chance. My advice for these companies on the fence is that it's reasonable to start small and to select a particular service to transform end to end to fully take advantage of continues deployment. Don’t let legacy models prevent you from taking full advantage of agile methodologies on those services that can most benefit from continues deployment, like web-based apps.
How to get started with CD
Focusing on new workloads is an ideal starting point, especially if you have workloads that are web-based, created for distributed environments, or using new technologies like non-SQL services. Go little by little, try to find the paths of least resistance, and then keep moving from there. That's not to say that you can't tackle the more difficult workloads with continuous deployment, but it's wise to take the time to build a solid case for it, as well as your own confidence.
Using a DevOps model can help you achieve continuous deployment. DevOps requires software and services to be redesigned for a distributed environment that is not monolithic. Otherwise you'd have to re-deploy the entire database every time you want to make a change. For DevOps to work, you need to redesign the service with agility at its core.
If you get started down the path of continuous deployment with low-hanging fruit first, then you can begin to showcase the potential advantages of redesigning those monolithic services. From there, it can become a snowball effect. Once you redesign, you can likely move toward open software. If you adopt more open software, you can save on licensing expensive software, and you can make it in a more distributed environment. That means you can go from expensive or obsolete hardware to a more commodity hardware that can easily go everywhere.
Finally, and it may go without saying, but evaluate everything. Find out your savings on licensing, hardware, and possibly also usage of other public hardware that eliminates the need for actual capital on your side. The economies of a scale on DevOps models will continue to pay as more and more are adopted. Once you prove the advantages of continuous deployment, you can more easily make the business case for its role on other services.
Maria Azua currently serves Barclays Bank as a Managing Director of Global Infrastructure Engineering focused on IT strategy, design, and solutions. Previously, she spent more than two decades at IBM progressing from engineering contributor to multiple officer level roles leading Cloud, Big Data, and Mobile innovation, revenue growth, and operations efficiency. In addition, Maria is a Digital Advisor providing technology acquisition value due diligence, engineering thought leadership, and talent assessment to boards, CEOs, and venture funds. She is the published author of The Social Factor about igniting the creative process; developed 50 patents on a variety of Software solutions, and a recipient of technical leadership awards from sources such as People Magazine, the Women in Technology Hall of Fame, and the Governor of New York. She has a Doctorate in Computing Science, an MBA, a Master's in Computer Science, and a B.S. in Physics.
