devopsy.kinsta.cloud

Author: Brendan Hayes

  • A Prescription to End the Myopia of Software Metrics

    A Prescription to End the Myopia of Software Metrics

    “People don’t want a quarter-inch drill. They want a quarter-inch hole!,” Theodore Levitt, Harvard Business Review.

    As someone who has purchased many drills in my life—and drilled my share of holes—this quote has always struck me as a bit, well, myopic.

    Don’t get me wrong, I’m not arguing with the sentiment behind the quote—that organizations need to focus on customer needs versus the products they make—but perhaps the example could be updated to reflect our times.

    Part of the issue I have with this quote is that, unless you only want a peep hole, a quarter-inch hole is not a solution in and of itself. No one needs a quarter-inch hole in isolation.

    You are most likely working on a bigger project that requires multiple holes. You have an outcome in mind, that outcome requires some holes drilled and a drill is the best way to make holes. The holes are an intermediary step.

    For example, the last time I purchased a cordless drill was because I was remodeling my kitchen and my existing drill had reached the end of its useful life. Of course, I needed to drill holes in the process, but that was not my ultimate objective—the kitchen was.

    By now you are probably asking yourself, “What does a 60 year old quote about marketing myopia have to do with DevOps and software development?”

    I would argue that the same principle applies to the metrics we apply to software development. Using myopic measures of success can prevent us from meeting the needs of customers, or of our own organizations.

    In a previous post, I wrote about a Forrester Report that urged CEOs to end the madness of software metrics and called out software organizations for using arcane, indirect measures of success.

    Some of the metrics we use to measure DevOps success today are the equivalent of measuring the number of holes we have drilled, the speed at which we drilled them or the quality of the holes. While these are certainly important to gauge, they do not correlate directly to whether we are meeting the needs of our customers, or of our own organization.

    As a follow-on to the report referenced above, Forrester conducted a survey of over 300 senior business and software leaders, which uncovered some interesting data points.

    Eighty-six percent of respondents said it’s important to align software delivery practices with the overall objectives of the business. And 80% said measuring the overall value of software initiatives is important or critical. Makes sense.

    Yet, very few are actually tracking business-oriented metrics that align to those goals. Only 38% are correlating software initiatives to their impact on revenue, and fewer (37%) are attempting to measure ROI for software development. Impact on customer experience was slightly better, but still measured by less than half of respondents (45%). These are metrics most business leaders care about—but few software organizations are tracking them.

    The study highlights the metric madness—or myopia—that causes disconnects between software development teams and business leadership. BizOps is a new framework that is gaining traction in the industry because it promises to eliminate this disconnect.

    At its heart, BizOps is a framework for optimizing software development and delivery to foster the achievement of business objectives. Essentially, BizOps helps connect the dots between traditional measures of software progress and metrics of business success. It’s what we need to end the myopia of software metrics.

  • Is It Time to End the Software Metric Madness?

    Is It Time to End the Software Metric Madness?

    We have all heard the phrase “What gets measured, gets managed,” often attributed to Peter Drucker—interesting note about this quote, Drucker didn’t say it. In the DevOps space, or application development and delivery generally, this quote is often used as a justification to measure things like deployment velocity, bug fixes, lead time and so on, as a way of gauging success.

    One can find countless articles with titles such as “X Key Metrics to Track DevOps Success.” Many of these use a version of this quote to justify measuring attributes that are all essentially related to the speed and/or quality of work.

    Deployment velocity, lead time, bug fixes, etc., are effective ways to show that an organization is producing software rapidly, and with a degree of quality. But, are these really the best ways to measure success?

    In almost any other industry, the answer would be “no.” These traditional software delivery metrics are a measure of work progress. They do not account for whether that work progress results in meaningful value, or business success.

    Take an automobile manufacturer, for example. If Acme Cars can produce hundreds of thousands cars annually (speed), and they all drive down the road perfectly (quality), would they be a successful business?

    What if no one wants to buy all those cars? GM was able to produce many thousands of Pontiac Aztecs, but they were condemned by journalists and consumers (Walter White notwithstanding) as the ugliest car ever created, and demand was far short of projections.

    What if the cars sold, but they all sold for a loss? In the case of the Aztec, Pontiac needed to sell 30,000 annually to break even, but they never came close to that mark. Many today consider the Aztec as being at least partially responsible for the demise of the Pontiac brand.

    Measuring the speed and quality of production is essential but not sufficient. Yet, for the most part, that’s what software organizations are tracking.

    This could be why Forrester Research wrote that “CEOs must end the madness of software metrics” in its report “CEOs: Foster the Software Teams and Talents Your Firm Needs.” Forrester goes on to say that “arcane, indirect measures of success and ROI…confound conventional management techniques.”

    Instead, there needs to be a correlation to business outcomes, such as profit margin, ROI and customer acquisition, according to Forrester. Highly successful organizations are already doing this. Others need to take steps to ensure that “everyone in software delivery gauge success with business measures.”

    This same philosophy is what’s driving increased interest in the concept of BizOps. BizOps is a framework for optimizing software development and delivery to foster the achievement of business objectives. Essentially, BizOps helps connect the dots between traditional measures of software progress and metrics of business success. It’s what is needed to end the software metrics madness.

    Read more about why BizOps is becoming important in this blog by Kieran Taylor.

    — Brendan Hayes

  • DevOps, Continuous Delivery – It’s All About Automation

    DevOps, Continuous Delivery – It’s All About Automation

    I spent a large portion of my career in the networking industry, marketing routers, switches and other gear that makes the internet work. Networking—like many industries—is currently undergoing a revolution that is in large part driven by software. Functions that used to be delivered as a standalone device can now run in software (not unlike the apps on your smartphone); and software is also being relied on more to make decisions about how traffic is routed through the network.

    I still read up on the networking industry occasionally, and if you’re looking for an expert opinion or just good journalism in this space, you’d be hard-pressed to find a better source than Craig Matsumoto. Craig wrote an interesting opinion piece called “NFV, SDN, Big Data – It’s All About Automation.” You don’t have to know what those acronyms mean to understand the premise.

    What’s interesting is that the same premise can be applied to many of the things that promise to make software development easier, faster and cheaper. DevOps, continuous delivery, continuous testing—all rely on automation to be successful.

    DevOps, of course, requires more than just automation—as it’s also a cultural shift—but automation plays a huge role. The three main components of successful DevOps are commonly cited as tools (or technology), process and people (or culture). Automation is the primary goal of the first two: tools that enable you to automate previously manual tasks, and then establishing the processes that allow you to take advantage of this automation.

    The same can be said of continuous delivery or continuous testing. Continuous testing relies on being able to automatically generate test cases, automatically create virtualized testing environments and create automated calls for testing.

    The premise of a modern software factory also relies on automation. Any modern factory, whether it’s producing cars or toothbrushes, strives to improve efficiencies by eliminating as many manual tasks as possible.

    The fact that software development and operations are lagging behind other industries in terms of automating the production of its goods (i.e., software) is maybe a bit ironic, given that software development is typically seen as more technologically advanced.

    However, it’s also a result of the maturity of the industry and that fact that coding, by its nature, cannot be automated. But the tasks that surround the actual writing of code certainly can be automated, and that’s what the modern software factory promises. The more you can automate, the more successful you will be in delivering quality software faster, with reduced risk and costs.

    Automation seems to bring with it concerns about employment—that is, there is a not-unfounded fear that it’s possible to automate oneself out of a job. However, there was an interesting study that came out, focusing on the automobile industry—one of the most well-known examples of factory automation. The study concluded that:

    In the last six years, (2010–2015), according to the IFR (International Federation of Robotics), US industry has installed around 135,000 new industrial robots. The principal driver is automation in the car industry. During this same period, (2010–2015), the number of employees in the automotive sector increased by 230,000.

    Essentially, automation not only improved production velocity and quality, it also resulted in a net increase in employment.

    The message is clear: Automate what you can and only rely on manual tasks for what you must. If you focus on automating your software development life cycle, not only will you be able to deliver software faster, cheaper and with better quality, but you also will be well on your way to achieving continuous delivery and DevOps.

    — Brendan Hayes

  • In the Application Economy, Every Company is a Software Company

    In the Application Economy, Every Company is a Software Company

    Recently, I was in New York to attend the Third Annual DevOps Virtual Summit. (Yes, I had to be at a “virtual” summit in person—while it’s virtual for the attendees, it occurs in real life for the speakers, panelists and support staff.)

    The broadcast took place in a small recording studio that featured a lobby adorned with autographed photos from celebrities who had used the facilities previously. Sylvester Stallone, Al Pacino and even John Stamos—complete with a full mane from the “Full House” days—were all looking down on us from the walls.

    Anyway, as the speakers were introducing themselves in this lobby prior to the event it occurred to me that the sampling of speakers was illustrative of the importance of DevOps across industries. The companies participating in the event were not what you’d traditionally consider a “software business,” but yet they’d made an investment in their software development practice—recognizing the importance of competing in the application economy. It underscored the point that in the application economy every company is a software company, regardless of what industry they are in. Which is why the concept of DevOps and Continuous Delivery should be top of mind, even if your company may not see itself as being “in” the software business. Regardless of what end product your company sells, you rely on your software and applications to do so.

    Take a look at the panelists and the companies they represent to illustrate this: Silvia Prickel from United Airlines. Matt McComas from GM Financial. John Hashimoto from CNN. And Kelly McCartney from Jeweler’s Mutual Insurance Company.

    An airline, an automobile financing company, a news organization and an insurance company that’s been around for 100 years (literally). These are not companies that were born digital, like many of the web-based entrants you might typically associate with DevOps. Instead, these are traditional organizations that recognized the need to make a digital transformation.

    And the results were pretty impressive. We often focus on speed when we talk about continuous delivery, but it’s important to remember you also can see improvements in quality. The below image was taken from the United presentation and shows the dramatic decline in production outages.

    This is not to say that improvements in speed were not seen as well. Matt McComas from GM Financial spoke about how his company is now averaging 1,800 deployments per month, with each one taking just 3 to 5 minutes.

    I won’t give away any more important details here. If you’re interested to find out more, I encourage you to watch the replay of the webcast: http://bit.ly/DOVSreplay

    — Brendan Hayes

  • When Technology Doesn’t Matter

    When Technology Doesn’t Matter

    Over 10 years ago, Nick Carr wrote an article in the Harvard Business Review with the title, “IT Doesn’t Matter.” As you might expect, an article with a title like that generated a significant amount of controversy. CEOs from leading technology companies and other writers at the time panned Carr’s premise in a way that, in retrospect, seems a bit overly defensive.

    His point, after all, was not that IT was not unimportant; rather, IT (as vaguely defined in the article) was so ubiquitous that it was no longer a competitive advantage. Rather, it was what companies did with their IT technologies that provided competitive advantage. It’s also worth noting that his (seemingly) intentionally vague definition appeared to focus on the generic notion of IT as PCs, servers and things that had become commonplace at the time.

    This has been a common pattern throughout the history of technology: Early adopters enjoy a competitive advantage, but only as long as the technology they’ve adopted remains scarcely used. Any advantage goes away when the technology becomes ubiquitous. The technology remains important—even critical—to a business’ operations, but it’s hardly an advantage when everyone else has the similar technology.

    Carr’s article uses the example of electricity: In the late 19th century, when electricity was an emerging and scarce technology, factories that were able to leverage electricity for their manufacturing efforts held a significant advantage. Today, no factory can operate without electricity, yet it’s hardly considered a strategic asset.

    Today in the 21st century, we’re seeing a similar trend repeated, but on much compressed time scale. Providing free Wi-Fi was once a lure for customers of restaurants, coffee shops and the like, but today it’s essentially table stakes. Likewise, leveraging clouds was once a competitive advantage, but with more than 90 percent of companies using some form of public or private clouds, one would be hard-pressed to argue that cloud usage alone provides any significant advantage. However, how you use these clouds can, in fact, become a competitive advantage. CA offers a variety of tools to help you manage, secure and accelerate your use of clouds.

    It’s an important lesson to learn: In the application economy, early adopters enjoy an important—yet relatively short-lived— competitive advantage. Knowing when to jump on an emerging technology can be the difference between surviving and thriving.

    Today, there are several technologies that are on the cusp and moving quickly to adopt them can provide a significant competitive advantage. The ability to deliver software continuously—while not exactly a single technology—is on this cusp. Continuous delivery is a core component of a successful DevOps implementation, and means essentially what it sounds like: the ability to deliver software from planning to production in a near constant and continuous fashion. Achieving true continuous delivery means you must test continuously, develop continuously and release continuously.

    Continuous delivery is not easy to achieve, but for those who do the advantage is significant. Companies implementing continuous delivery can get to market 20x faster with 98 percent fewer production errors. That’s a powerful benefit.

    To learn more about CA’s portfolio of continuous delivery solutions—and hear directly from several customers—you can check out the replay of Jeff Scheaffer’s keynote presentation from CAWorld 2016.

    — Brendan Hayes