Tag: automation

  • The Impact of Automation: Considering 3 Facts

    The Impact of Automation: Considering 3 Facts

    I’ve been interested in the ramification of automation on human employment for a while now. My profession, IT, is bringing more automation to the planet every day. I would be irresponsible to not understand the ramifications of my work.

    Recently in my research I came across three facts that gave me pause. The facts are:

    1. Due to improvements in automation, it takes fewer people to create more goods and services.
    2. We are producing more good and services than we ever have, possibly more than we might ever need.
    3. Just as it takes fewer people to create goods and services, fewer people are garnering more of the wealth being created.

    The implications of these facts are dramatic and the implications are far-reaching. Allow me to elaborate.

    Fewer People Create More Output

    Consider this fact: In 1790 90 percent of the people in the United States were engaged in agriculture. Most of the people fed the population. Two hundred years later, 2.9 percent of the population was engaged in agriculture. A relatively small amount of people create enough food for all.

    Also, consider this one: In 1980 it took 26 people to create a $1 million in output. Today it takes 2.6.

    The pattern is obvious. As time marches on, it takes a lot fewer people to create a lot more wealth. Why? Automation technology. Every year we create more hardware and software that does work previously done by humans. Automation never tires and produces as much as we want, when we want. The trend is strong and consistent. The rate of innovation is increasing. And as the rate increases, more people will be displaced by machines and software. I talked about this extensively in the first article I wrote in this series.

    Let’s move on.

    We’re Producing All We Want — and Then Some

    Today China, India, Brazil, Vietnam, Indonesia, Pakistan, Thailand, Mexico, Italy and Turkey combined produce 18.5 billion pair of shoes year.  That’s more shoes made a year then there are people on the planet. (The current population worldwide is 7.5 billion.)

    Today there are 260 million cars registered in the United States,  which comes out to a little more than one car for every adult in the population.

    The number of cellphones in China in 2014 is 1.14 billion, in India there are 1 billion and in the United States there are 327 million. Just about everybody in these countries has a cellphone. And the prices keep dropping. Eventually, everybody on the planet will have a cellphone—which, by the way, has more computing power than did the computers onboard an Apollo spacecraft.

    Productivity no longer is constrained by the capacity of human labor to create goods. Whereas before the Industrial Revolution not enough goods were produced to satisfy consumer demand, today things are reversed. The modern struggle is finding enough buyers to purchase what’s been made.

    As I mentioned earlier, we’re really good at making as much as stuff as we want, whenever we want. And yet, despite this abundance, there is a problem.

    Wealth is Concentrated to a Few

    A report that came out earlier this year reveals a troubling fact: Eight people on Planet Earth own as much wealth as 50 percent of the rest of the global population. True, there is some dispute going on about the methods by which this number was determined. But, even if the number is 30 percent, the disparity in the distribution of wealth is astounding. More wealth is being concentrated to fewer people even as automation becomes more prevalent. Abject poverty may not be rising, but increased displacement of workers is. As workers become displaced, their wealth diminishes.

    Saying “Things must change” is absurd. Things will change. The question is, “What will that change look like?” Will we have a fully automated society in which there are more than enough shoes to go around, or will we still have a world in which there are those that go shoeless?

    What Do We Do Now?

    In previous articles I’ve talked about Universal Basic Income (UBI) as a possible way to address the problem of providing income for displaced workers. UBI is a viable solution, but not one that will to come to fruition in the near future. The problem is here today. So, what do we do?

    Read on.

    Economic Sustainability Over Economic Growth

    I’ve mentioned many times, there is a good argument to be made that the jobs taken away by automation are not coming back, nor will there be an abundance of new jobs to replace those taken. My prior article supports my assertion. Eighty-eight percent of job displacement is due to automation. The need for human labor is diminishing at accelerated rates. That’s the bad news. The good news is that automation has allowed us to grow our productivity more than we’ve imagined possible. But growth is not the answer. On a planet full of shoes, there are still those who go shoeless. The change we need to make is to move from an economy based on growth to one based on sustainability.

    Changing the Way We Talk About Things

    I’ve come to accept that we cannot grow our way into economic prosperity any more than we can grow our way into good health. In fact, too much growth can kill you—just ask someone who suffers from morbid obesity. So I made the change in how I talk about prosperity. I no longer use the term “economic growth.” Rather, I use the term “economic sustainability.” I am a big believer that thinking follows language. Change the way we talk about something and we’ll change the way we think about that thing. If we want to have a sustainable economy, we need to start talking that way.

    Creating Wealth for All

    Okay, I’ll come clean. I think that given the current trends, too few have too much. More wealth parity is required. But, as we have learned on the terrain, overt wealth redistribution is not the answer. We cannot tell somebody we’re going to take away a part of their wealth without upsetting them. But, we can set an example in the benefit of sharing the wealth to benefit all. We in IT have been doing it for years—it’s called open source. We learned a few years back that when we give it away, we get it back. The trick now is to go beyond IT and make the open-source mindset part of our civic sensibility.

    At some point in the not-too-distant future—say, about 20 years—we will be at almost total automation. If trends continue, there will be few with a lot and a lot with a little. People that don’t have a lot don’t have much to lose. Wealth inequality creates turmoil, unrest and overt aggression. If you think not, take a look at the excesses of France under Louis XIV which, by the time you got to Louis XVI, led to the French Revolution and the Reign of Terror. Or consider that the wealth disparity during the last generation of the house of Romanov led to the Russian Revolution. Nicholas dined in lavish halls while the serfs starved. Lenin prevailed.

    Wealth parity creates political stability and political stability creates prosperity for all. Achieving wealth parity comes about by sharing. Again, we who have code on GitHub know this. Again, the trick is to make the open-source dynamic part of our civic sensibility.

    Let me close by providing one more fact. One of the thing I’ve learned in my research is that as the population rises in a country, so does the GDP.

    Figure 1: Population growth among 9 most populous countries, 1960 -2015 (Source World Bank)

    Figure 2:  GDP Growth, 1960 -2014 (Source World Bank)

    But, again the trend is that the wealth goes upward to a few. So we have a choice. As automation increases, we can learn to share the wealth and create a world that is stable, sustainable and prosperous. Or we can keep the current trend in place, allowing the few to have the most. And because we don’t need a lot of human labor to maintain the levels of production possible, rather than risk ongoing political upheaval and civil unrest, we can just get rid of those that unfortunately are on the wrong end of the distribution curve. Their labor is no longer needed.

    Is such an idea vile and extreme? Yes, it is. Is it one without precedent? I’ll let you be the judge.

    — Bob Reselman

  • Automation Killed QA – It’s Time to Deal With It

    Automation Killed QA – It’s Time to Deal With It

    Quality assurance (QA) had a good run.

    From the time it was considered an afterthought by organizations and software vendors alike to the era of massive outsourcing contracts, followed by significant vendor investments in related tooling, and, finally, its recognition as a critical success factor among high-performing organizations, quality has evolved to become even more important than functionality to end users.

    Customer experience, today, is defined by speed and quality above all else. Namely, can I access the information and products that I want in the blink of an eye and get expected feedback based on input? As a result, customer experience has also shifted: It’s all about application experience, not the friendliness of a checkout cashier or sales/service rep.

    With this massive shift toward customer experience platforms (think omni-channel) and increasingly lofty expectations, the operative question becomes, How are we enabling velocity in our testing practices to ensure the highest quality while keeping up?

    We’ve tried everything from outsourcing to insourcing, investing in tooling, investing in people and even building testing architecture teams to oversee the automation, quality and consistency of testing results. Roughly seven years ago, my top priority for testing teams was to automate 30 percent of our tests. Today, if you are not 100 percent automated, or close to it, you are severely lagging in output.

    But what’s next? What if I’ve automated all of my tests and my manual testers have been replaced with automation engineers, but I’m still having quality issues and being perceived as a bottleneck?

    The answer is simple. Automate everything.

    Makes sense, right? Isn’t everyone telling you that? But what are we defining as “everything” from a testing perspective? Therein lies the problem; we are thinking about testing as its own factory within the larger software development life cycle.

    While we believe we are changing this perception by going agile and moving most QA functions into scrum teams, the reality is we still look at testing as a standalone function. Centralized or decentralized, this is the case, and we need to think differently.

    Automating for quality begins with defining requirements. How am I ensuring that I’m covering all cases? How do I ensure I’m translating the business requirements properly? These questions, the time it takes to answer them and the risk of human miscalculation all impact quality and velocity.

    We must start our automation for quality at the beginning, during establishment of business requirements.

    Let me introduce you to next-generation QA. Intelligent “continuous testing” platforms are replacing humans for testing, automating tests, creating data and building test cases. These platforms are able to translate model-based business requirements into complete automation—test cases, test data and test script automation.

    Orchestration across your software development life cycle creates your environments, lays down your test data, deploys your software, runs your test scripts and reports results. No more human error, no costly resources and guaranteed test coverage that ensures quality.

    Integrating your existing automation around continuous integration, portfolio management reporting, and execution reporting to this framework now gives you the ability to report and automate your ideas all the way through to outcomes.

    Early adopters are already doing this. QA as a functional organization is gone. If you aren’t already automating to this end, you are severely behind.

    Questions?  Comments?  Perspective?  Have at it in the comments below.

    — Ron DeCanio

  • Increasing Your ‘Bionic Footprint’ with DevOps

    Increasing Your ‘Bionic Footprint’ with DevOps

    “The Six Million Dollar Man” was a 1970s TV series. In the show, NASA astronaut Colonel Steve Austin is severely injured in a crash and is “rebuilt” with bionic features that enhance his strength, speed and vision beyond normal human capabilities. The main tagline was, “We can rebuild him, we have the technology.”

    I recently was watching an old episode and it got me thinking about how the show is analogous to the genesis of DevOps—specifically, how individuals with an operations background have to “rebuild themselves” to keep up with the speed and direction of the technology industry.

    Over the years, there have been several decrees of “Unix SysAdmins are going away.” I have always firmly disagreed with that assertion. Rather, I believe that SysAdmins have to continually evolve their engineering skills to stay relevant and, more importantly, gainfully employed. It was also becoming increasingly apparent that the manual tasks of deploying infrastructure, keeping it patched, monitoring and the myriad other things a SysAdmin performs every day could not keep up with the demands of the increasing pace of the digital world and the onset of cloud computing. Infrastructure is moving rapidly to being automated and programmatically deployed and the talent needs to adjust accordingly to stay relevant.

    With many enterprises adopting the agile methodology and moving toward a continuous integration/continuous delivery (CI/CD) pipeline, the culture of DevOps became a reality. Due to the increased velocity, there became a clear need for the core tenets of DevOps culture, which include culture, automation, measurement and sharing (CAMS). In Six Million Dollar Man terms, this was simply “Better … Stronger … Faster.”

    Embracing DevOps through CAMS is similar to the superhuman enhancements that composed the rebuild of Steve Austin, which took him from man to bionic man. Here are the four ways that DevOps can increase your enterprise’s “bionic footprint”:

    Improve Culture

    Even Austin’s bionic features only got him so far; the bionic man had to rely on his team to complete his dangerous missions unscathed. The same is true in the enterprise: Building a collaborative culture is crucial for success. Culture is paramount in maintaining overall velocity without adversely affecting quality. Developers and operations teams need to function in concert to ensure a resilient application and infrastructure.

    Increase Velocity via Automation

    Automation greatly increases velocity, akin to how Austin’s bionic legs allowed him to run at high speeds and make great leaps. Automating processes saves time, money and lets your team focus on more complex tasks—a win-win for productivity gains.

    Measurement

    Steve Austin had a bionic left eye that enabled him to see in the dark as well as detect heat. This provided him precise measurements of his surroundings in any situation, enabling him to gain the upper hand against adversaries. Similarly, measurement gives insight into all aspects of the software development life cycle, application performance and other key metrics. Without insight and transparency into measurement, your team is essentially working blind.

    Sharing

    Austin had a bionic right arm that had the strength equivalent of a bulldozer. Strength and resiliency are increased by teams that work and communicate effectively made possible by DevOps.

    To summarize, I strongly believe that the mantra of “Better … Stronger … Faster” should be that of every DevOps team moving forward. DevOps’ parallel of CAMS upgrades your team’s capabilities to perform more productively. There is no end game; the objective is about continuous improvement, velocity and sustainable growth. Enterprises that want to undergo digital transformation need to adopt this cultural approach to increase their “bionic footprint” to succeed.

    About the Author / Mike D. Kail

    Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

  • DevOps: Making the Boring Things Stay Boring

    DevOps: Making the Boring Things Stay Boring

    “I, For One, Welcome Our New Robot Overlords,” is the title of Mykel Alvis’ (@mykelalvis) session at the 2016 All Day DevOps Conference. He wasn’t trying to curry favor with the new robot rulers, a lá Kent Brockman, but, instead, was evangelizing on the importance of precision in DevOps.

    Mykel is the DevOps Coach at Cotiviti Labs, the development arm of Cotiviti. Every day it handles healthcare data, which as you know happens to be some of the most regulated and protected data around. As Mykel said, “We don’t do cat pictures on the internet.” A mistake, breach, security flaw, etc., could mean the exposure of privacy and financial data for millions of people. But, it is a large organization, with exposure that needs to be managed. It has 200-plus repositories, three to four deployments per day, 15 developers and 0 operators (sort of). Without the right discipline and rigor, costly mistakes could happen.

    Hence, Mykel’s need for the robot overlords. As he noted during the conference session, robots have, “Lower utility, but greater predictability.” They do exactly what they are told, and they do it the same way, every time. By contrast, humans are superior to responding to unpredictable events. Mykel’s goal is to leverage the strengths of each. Cotiviti Labs has systems, policies, procedures and a culture in place that supports the automation of tasks as much as possible to ensure mistakes are kept to a minimum and the humans can focus on the unpredictable. The company is striving to make the boring things stay boring. Cotiviti calls it “The Labs Way” and here is how it does it:

    • Treat everything as code. Everything. Infrastructure, data, everything. As an example, it performs pull requests to get status updates for executive reports.
    • Test the code. 
    • Perform formal releases. Cotiviti builds its code in very specific ways, with extremely rigid gatekeeping processes.
    • Releases produce immutable artifacts. Once something has been released, it will never change it. It could, but it doesn’t.
    • Keep everything. Not in a huge, unorganized file system. In an organized repository.
    • Failing tests mean a failed build.
    • Design your systems to be automated. Cotiviti doesn’t do things that can’t be done automatically.
    • Deal with those systems only through automation. This is probably the most challenging thing it does since it is extremely hard to convince developers to write their code to do this.
    • Operations IS developing. Operations is not a bucket for development. Operations is a development task. You treat it like it is real code.
    • Because everything is code. Everything.
    • All defects are defects of code.

     

    To achieve this, Cotiviti:

    1. Standardizes
    2. Evaluates
    3. Tests
    4. Discards the useless
    5. Owns it

    None of this comes easy. It challenges norms. It pushes boundaries. It mandates discipline. (Pull quote – “Discipline is the bridge between goals and accomplishment.” – Jim Rohn) Your team has to understand you have a way to do things, there is a reason, and it will reduce risks and make sure everything works. It will keep the boring, boring.

    You can watch Mykel’s full presentation from the All Day DevOps conference here (30 minutes).  The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

    Want more to read? This is blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps for Small Organizations: Lessons from Ed”. Next week, look for “Getting out of the Job Jungle with Jenkins,” a discussion by Damien Coraboeuf.

    — Derek E. Weeks

  • Automation, ChatBots Can Improve DevOps

    Automation, ChatBots Can Improve DevOps

    At its heart, the goal of DevOps is to foster better communication between the development team and operations team at an organization. When these two teams are systematically connected, they can easily stay in sync on most issues and there is strong coordination in building and delivering the product to customers.

    Automation and ChatBots can play a big role in the connecting development and operations. They open the door for companies to go beyond simply being alerted when something happens in a chat application, allowing an employee to take action after receiving the alert either in an automated manner or by providing guidance to the employee on which actions to take.

    Automation: Creating Smart Alerts That Don’t Require Follow-Up

    Monitoring applications, systems, virtual machines and networks are a key part of any operations team. There are a number of tools that are used for this purpose, including CloudWatch, Splunk, Rollbar, Pingdom and Newrelic. These tools typically alert the operations teams when there are issues. Engineering teams, on the other hand, use tools such as JIRA and Github to track tickets and manage their agile development process. Alerts from the tools used by operations are helpful, but they still require some manual follow-up. For example, imagine a critical alert is reported by one of the tools because of a product issue. Follow up on this alert would require:

    • Creating a ticket in JIRA/Github with all the relevant information to help diagnose the issue.
    • Escalating that ticket so that it gets looked into right away.
    • Keeping the required people in sync as the status of the issue changes.

    This entire process can be automated. When automated, the workflow operates like this:

    • When the monitoring tool senses there’s something abnormal, like error rates above certain thresholds or a critical failure, alerts are sent and a ticket is created in JIRA or Github automatically with all the relevant information about the issue.
    • Taking this a step further, based on the type of issue, it can be automatically assigned to the right person and even post a message on the appropriate Slack channel.
    • As engineering works through the issue, everyone is automatically informed in Slack when the ticket is updated.

    The key to getting this scenario automated is to leverage an integration and automation platform that is powerful enough to handle complex workflows, yet easy to use so that these automations can be built in minutes. Users don’t want to work for your automations, they want their automations to work for them. With that in mind, the platform should also be flexible so changes can be made to the workflows without any engineering effort (i.e., an automation platform where integrations and automations can be built and changed without any coding).

    ChatOps: Monitor and Orchestrate via Chat Platforms

    With all the apps being used by DevOps, it is difficult for any team to stay on top of monitoring and managing issues while also taking actions across all these tools. Studies show that app hopping is not efficient and results in constant context switching, which negatively impacts productivity.

    ChatOps allows users to stay on top of everything including orchestrating workflows right from chat platforms such as Slack. To make ChatOps work, users need a bot that works in tandem with an integration and automation platform. The bot works with all business apps (even the tough ones with custom objects such as Github and Salesforce), is customized to meet the specific needs of the business and can extend to address all operational needs.

    Here are three ways users can leverage bots for better DevOps:

    Smart, actionable alerts: Rather than have a firehose of alerts coming in, users can define various thresholds, monitor velocity of alerts and, based on these settings, post an alert to the relevant channel or person on Slack. Bots can also prompt the person to take action based on the notification.

    Stop services, virtual machines: Bots can connect with any app, or service that has a HTTP/REST API. Not only can they monitor various apps and environments, they also can start and stop them.

    Workflow orchestration: Various workflows such as managing incidents, escalations and deploying code are all triggered and managed through Slack.

    Automating DevOps has significant benefits in overall increased engineering and operations productivity. The key to automation success is to select an integration and automation platform that is secure, resilient, can handle complex workflows, can be easily customized to meet the specific needs of the business and can be managed through Slack. It should be easy to use so automations can be built fast and changed easily as workflows change. Automation and ChatOps will streamline business workflow, keep the important players from both development and operations informed and increase productivity for everyone involved.

    About the Author / Gautham Viswanathan

    Gautham Viswanathan is the founder/head of products at Workato, www.workato.com. He also leads the team in creating Workbot For Slack, a bot designed to be customizable and allow you to do work in your apps right from Slack. Gautham has a deep background in integration platforms and was previously the head of products and engineering at TIBCO. Connect with him on LinkedIn.

     

  • DevOps for Small Organizations: Lessons from Ed

    DevOps for Small Organizations: Lessons from Ed

    Ed was demoralized. He had just heard a speaker who would change his life. He knew he needed to change, and he knew what the end goal was. He just didn’t know how to get there. He needed fresh air. He needed endorphins. What better way to do that than go on a six-hour run through some of the seedier neighborhoods of Vegas to the edge of the desert.

    Ed Ruiz (@eruiz06) is the senior director of IT for the Association of Schools and Programs of Public Health (ASPPH), and I heard him share lessons learned from his conversion to DevOps during the marathon All Day DevOps Conference (free, online).

    Here’s where his journey started. Earlier that year, ASPPH recognized a need to modernize its membership structure. The organization had ballooned from 31 to 106 members. Ed had a staff of 10, supporting 54,000 students and 13,000 faculty serving in 141 countries. ASPPH was steeped in following the Microsoft Enterprise handbook, deploying via the waterfall method every thee to six months, and recognized it needed to update its IT infrastructure.

    There, among the glitter and glam of a ballroom on the Strip, Ed heard DevOps Evangelist Andi Mann (@AndiMann). Ed was glued to what Andi had to say. “This is what our organization needs,” he thought. But he quickly became demoralized because he didn’t know how to lead the drastic change.

    During Ed’s run following Andi’s keynote, he realized he need to start with a vision. Spoiler alert: Ed was successful, but not without a few hiccups. Ed shared four lessons he learned during the session to help the rest of us pursuing our DevOps journey.

    1) Articulate a Vision. Your team needs to understand what the organization does, why it is important, and how this change allows the organization to be more effective.

    2) Start with Culture and Sharing. The DevOps mantra emphasizes the equal importance of Culture, Automation, Measurement and Sharing (C.A.M.S.). Too often people are drawn to automation and measurement first. It is what they know. It is the DevOps tools that are fun to implement. According to Ed, overemphasis on tools is a huge mistake. DevOps is called DevOps because it is implementing a culture of sharing between development and operations. Automation and measurement are tools to facilitate sharing, but if your team isn’t on board with culture and sharing, DevOps will fail.

    3) Prune the Bad Apples. We all know that person (they go by many names: Dr. No, Negative Nelly, Milton). You don’t want that detractor in your organization. When Ed decided to keep a  Dr. No on his team because of his technical acumen, it took half of Ed’s team quitting before he realized the bad apple needed to be pruned from the tree. Dr. No’s negativity was contagious and led to poor morale that was eroding the culture needed for success. Ed’s advice? You can teach skills, but you can’t teach a positive attitude. Hire for the attitude first.

    4) Leadership Buy-In is Essential. Priorities and budgets will change and setbacks will happen. When you have buy-in from the leadership, it creates room to fail. You can pick yourself back up and take another step toward your vision.

    We don’t know what else happened in Vegas over those five days, but we do know Ed came home a changed man and he changed his organization. We all can take some lessons Ed learned and apply them to our own transition to DevOps.

     

    http://https://www.youtube.com/watch?v=Kv6PJTp3uq4&feature=youtu.be

     

    You can watch Ed’s full presentation from the All Day DevOps conference here (30 minutes).  The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

    — Derek E. Weeks

  • 5 Ways DevOps Can Help Improve IT Security

    5 Ways DevOps Can Help Improve IT Security

    You already know DevOps can make software delivery faster and more efficient. But did you know it can help to keep software more secure, too? Here’s how.

    DevOps refers to a set of practices and cultural priorities related to the way software is designed, produced and deployed. It emphasizes collaboration between developers (the people who write code), IT Ops (the folks who manage software in production) and everyone in between—such as software testers and designers.

    When done properly, DevOps greatly reduces the time it takes to bring software from idea to implementation to end user delivery. It also adds efficiency to the software delivery process in many ways. It allows different team members to work in parallel, for example. It also ensures that coding problems are found early in the delivery pipeline, when fixing them requires much less time and effort than it does once a bug has been pushed into production.

    DevOps and Security

    But making software delivery faster and less costly isn’t the only thing DevOps does. DevOps also helps make software more secure.

    It does this in several ways. Consider the following:

    • Visibility. DevOps encourages constant communication between all members of the IT organization. That maximizes each team member’s visibility into the software being developed. In so doing, it places as many eyeballs as possible on the code, at all stages of delivery—which maximizes opportunities for your staff to find security flaws before code is released into production.
    • Automation. In the DevOps world, software delivery tasks are automated as much as possible. With automation comes consistency and predictability—and a much lower chance that human error during a manual process could introduce a security vulnerability.
    • Fast updates. DevOps enables a much faster pace of software delivery. That means that security bugs (and bugs of all kinds, for that matter) can be squashed very quickly by rolling out a fix.
    • Tool-agnosticism. With DevOps, you can use whichever tools or programming frameworks you like. You’re not bound to particular platforms or vendors. That’s important from a security perspective because it empowers you to adopt the tools that are most secure for your needs—not the ones you’re locked into because you have an outdated, inflexible software release process.
    • Agile technology. While DevOps doesn’t require you to use any specific type of tool, DevOps teams tend to favor next-generation architectures and technologies, like microservices and containers. These help to make apps more secure by reducing attack surfaces and enabling quicker reaction. If you deploy your app using containerized microservices, it becomes harder for attackers to compromise your entire app, because an attack against one microservice doesn’t give them control of the other ones.

    DevOps isn’t a silver bullet when it comes to cybersecurity, of course. Keeping your systems and data secure requires careful planning on a number of fronts and implementing a variety of tools.

    But DevOps—especially a highly automated, DevOps-based release process—should be one important weapon in your cybersecurity arsenal.

    — Chris Tozzi

  • Welcome to the Continuous Delivery 101 Podcast

    Welcome to the Continuous Delivery 101 Podcast

    No matter what industry you’re in or how old your business is, your software often determines your success in today’s application economy.

    Applications are the face of your business—both the way it performs and the speed with which you can incorporate new ideas and innovations, driven by the efficiency of your software development life cycle—determines whether your company can survive in this competitive market.

    Software doesn’t just support the business today, it drives the business—and your organization’s livelihood in this application economy comes down to your ability to quickly deliver world-class capabilities. As a result, more organizations than ever are turning to the practice of continuous delivery (CD) to improve their ability to plan, build, test and release applications to market.

    With this increased focus on continuous delivery methodologies and practices, we’ve established a new podcast that highlights the importance of utilizing CD, along with adoption techniques and other best practices.

    Dubbed “Continuous Delivery 101,” the series features some of today’s leading  experts in the field discussing where they’ve seen CD success, across some of the world’s top organizations and across multiple industries.

    The first episode in this series covers CD fundamentals and the software evolution that has made continuous delivery so critically important.

    Beginning in the ‘60s, this first wave of this software evolution saw mainframe systems brought in to automate business tasks. A second wave saw the emergence of ERP/CRM-based processes, so we could improve how we run contact management and transaction processes.  Today we’re in the third wave, which started with the widespread adoption of mobile and web technologies, with all of these paradigms intersecting in perfect convergence.

    Businesses that have mainframe and distributed systems, that have CRM and ERP system, that have web fronts and mobile apps, are utilizing these continuous delivery tools to innovate faster than ever before. These organizations are being forced to reinvent how they communicate with customers and how they deliver goods and services to stay relevant in the market.  This third wave, where business is now driven by IT, is the biggest disruption that we’ve seen.

    To hear a lot more on this topic, check out the  first episode of the Continuous Delivery 101 podcast via YouTube or the iTunes store, where you can find it on the Podcast App by searching for “Continuous Delivery 101 podcast.”

    Software delivery, fueled by CD, is evolving at a furious pace.  Stay tuned for more expertise and best practices.

    — Scott Edwards

  • Predictable Progress: Tracking DevOps Maturity Metrics

    Predictable Progress: Tracking DevOps Maturity Metrics

    As DevOps methodologies continue to evolve, we’re naturally seeing an increased emphasis on the cultivation of related maturity metrics.

    For instance, in the 2016 State of DevOps Report, researchers with DORA took an initial stab at creating relevant ROI measurements.

    Similarly, a new report issued by researchers Coleman Parkes, sponsored by CA Technologies, offers additional evidence that as agile and DevOps processes continue to expand, today’s practitioners are increasingly employing metrics to optimize their efforts.

    The report, titled, “Accelerating Velocity and Customer Value with Agile and DevOps,” finds some form of adoption among nearly every enterprise, with 87 percent having adopted agile to some degree and 73 percent leveraging DevOps.

    Related to the overall maturity of these practices, those organizations that are moving to embrace the techniques most broadly are predictably seeing greater returns. Yet, despite the widespread adoption, only a third have deployed either practice widely, according to the research.

    Percentage of Advanced Adopters Reporting Improvements in Customer Experience

     

    Based on a survey of 1,770 senior business and IT executives, the study also closely investigates the specific KPIs that organizations are using to gauge how agile and DevOps initiatives are translating into customer interactions.

    Most notably, “advanced” agile and DevOps adopters have observed more than an 87 percent improvement in overall customer experience, compared to “basic” adopters.

    In terms of how those efforts are affecting business drivers, Coleman Parkes finds:

    • Advanced agile practitioners are experiencing a 40 percent improvement in time-to-decision, compared to 33 percent for basic users.
    • Advanced DevOps adopters have noted a 42 percent improvement in speed-to-market, compared to only 24 percent for basic practitioners.

    Key Performance-Invoking Indicators

    To that end, the research highlights specific KPIs that organizations are using to measure the impact the agile and DevOps practices are having on customers. In fact, the study finds that between two thirds and three quarters of all the organizations surveyed have established such measurements.

    At least half of these focus on business or customer-related metrics, reflecting how “critical software has become to businesses’ ability to achieve their core mission,” Coleman Parkes researchers note.

    Among the mostly widely invoked metrics, include:

    • Business growth (specifically revenue): over 73 percent
    • Operational or process efficiency: over 73 percent
    • Employee productivity: over 73 percent
    • Customer experience: over 71 percent
    • IT-related costs: over 71 percent
    • Speed-to-market: over 71 percent
    • Customer satisfaction (via NPS): over 70 percent
    • Time-to-decision: over 70 percent
    • Quality of development: over 70 percent
    • Employee retention: over 64 percent

    If increasing applications delivery speed and overall organizational velocity are, in fact, the primary goals of engaging agile and DevOps, the research bears out that the techniques are having the desired effect. After all, the survey finds that time-to-decision and speed-to-market are being accelerated among approximately a third of the organizations studied.

    Related to other notable KPIs, Coleman Parkes highlights that a full three-quarters of adopters have moved the needle on overall customer experience, along with employee recruitment and retention, a significant benefit that was also highlighted in the State of DevOps Report.

    Along with positively impacting customers, the reality is clearly that agile and DevOps are also making a big difference in allowing companies to improve the atmosphere for their workers—a huge benefit when you consider the shortage of talent in IT today, and how much it typically costs to attract new employees, just as DORA’s researchers noted.

    Other key findings by Coleman Parkes include “before and after” metrics that many organizations are observing related to their continued adoption and advancement of the involved methodologies themselves.

    I encourage you to download the entire report, and leverage it to measure how far you’ve come with Agile and DevOps transformation—and where you may need to re-examine your efforts.

    — Aruna Ravichandran

  • DevOps is More Than Just Automation

    DevOps is More Than Just Automation

    DevOps is a lot of things. What DevOps is, what DevOps does and how an organization adopts and implements DevOps tools and practices are largely subjective, but there are some foundational elements that are fairly ubiquitous. One of which is automation. As pervasive as it is, though, DevOps is not automation and automation is not DevOps.

    The Preface of “The DevOps Handbook” lists a number of prevailing myths about DevOps, including the idea that DevOps is just “infrastructure as code” or automation. The book goes on to explain:

    While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.

    The book also shares an anecdotal quote from technology executive Christopher Little: “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”

    I prefer a golf analogy. If DevOps is the game of golf, then automation is like the putter. The game itself may be played for different reasons by different individuals—exercise, competition, just to get out and enjoy nature—but the fundamentals are the same no matter what the ultimate goal is. There is a wide variety of clubs available and strategies that can be employed to get the ball from tee to green, at which point the putter is somewhat indispensable. It is technically possible to tap the ball in using some other club, but everyone will agree that the putter is the best tool for the job. As necessary as a putter may be, though, the putter is not golf and golf is not the putter.

    The important thing to remember is that automation is simply a tool or method for achieving the goal. It, like any other facet of DevOps, has to be part of a broader cultural shift and mindset.

    It was about a year ago that I theorized that microservices could make the “Ops” in DevOps obsolete. If everything—infrastructure included—can be implemented in code and automated, will we still need people to be involved? The answer then—and now—is yes, because DevOps is about more than just automation. Its evolution is to one of enabler rather than job-killer. As more functions are automated, people can focus on bigger and deeper issues and create new innovations instead of focusing on mundane, repeatable tasks.

    You can’t do astronomy effectively without a telescope, and you can’t play golf effectively without a putter. Similarly, you can’t effectively do DevOps without automation—but it is theoretically possible, because it is just one element of DevOps.

    I can’t imagine why anyone would want to do DevOps without automation, though. It wouldn’t make any sense—like trying to look at the stars without a telescope, or sink a golf ball from 18 feet with an 8-iron. Although DevOps is more than just automation, the most effective and efficient way to succeed at DevOps is to automate everything that can be automated so you can stay focused on the big picture.

    — Tony Bradley