Tag: Culture Change

  • The State of DevOps Is Just Fine

    The State of DevOps Is Just Fine

    There is a growing amount of hand-wringing about the state of DevOps; that adoption is not progressing apace, or that the full benefits of the methodology are not being realized by the majority of adherents. That we can and must do more and do it better, etc.

    That is just stupid. Or, my first reaction: “Bunk!”

    Yeah, I called an idea stupid. No, I didn’t call you stupid. Don’t give me a reason to. The world is full of stupid ideas, and this is one of them. Here’s why.

    DevOps has seen a decade of unprecedented adoption – yes, unprecedented. PCs were not adopted by businesses at the rate that DevOps was adopted, once it caught on. Virtualization took the business world by storm and, frankly, wasn’t even close to the adoption rate of DevOps. Agile greased the wheels and got people thinking about better ways; we all knew the weaknesses of how we were doing things, and DevOps gave us an option that addressed those weaknesses. We took it. We ran with it.

    So talking about how it is stalled, when adoption is darned near-ubiquitous? Silly.

    Those concerned are further zeroed in on one aspect of DevOps – not enough culture change. Let’s face it—automation is easier, the ROI is more obvious and even when ROI is vague, the elimination of busywork from the schedule of developers and operations alike is huge. Some organizations were never going to move beyond that point; others eventually will, but aren’t in a rush. Organizational changes do not define DevOps any more than automation does—DevOps is the process of streamlining software creation and delivery—and both automation and culture change contribute.

    The “full benefits” of DevOps are … what, exactly? That is another silly part of the proposition that a slowing of DevOps adoption is negative. Automation improves the creation and delivery of software, silo elimination improves the creation and delivery of software… The full benefits of DevOps are improvement. That has always been the stated goal—to make it better, smoother, more repeatable. Wherever an organization is on implementation, it is almost guaranteed that their creation and delivery is “better, smoother, more repeatable.” So, benefits are accruing.

    And each organization has different needs. DevOps is a methodology. It has never been the perfect solution to every IT problem—though there are still pundits that will try to tell you it is. Automation is always a positive; Agile and DevOps—well, that is less true. You know your organization and your apps, so the “right methodology for the job” is absolutely your call, not some vendor’s or pundit’s. So, “adoption slowing” partially represents orgs/projects/apps that have opted not to pursue some of the more radical changes DevOps implies (yes, radical. Automation is just a logical extension of scripting; redesigning team organization and reporting relationships is absolutely radical by comparison).

    Which is a good place to leave off. Your apps, your org, your environment. You know what is going to do the most good. So keep doing it. Push for it if the org isn’t there yet, be the change that is needed. But be aware of cost/benefit. Sometimes, the changes being asked for just aren’t worth it. So make sure they are before you push too hard, and if they’re not, make sure you’re comfortable with why and can defend that decision.

    And keep rocking it. Those apps are delivering to users, no matter where you are in DevOps adoption. And that says it all about you and the team. Thanks, for all of your users that never think to say it.

  • Enterprise Infrastructure:  Adapt or Face Extinction

    Enterprise Infrastructure: Adapt or Face Extinction

    In my previous blog, I explored how new ways of working—DevOps, Agile, cloud and startup thinking—have brought in a tectonic shift in the ways of working of enterprises. For infrastructure leadership and management, this is nothing short of a perfect storm that they need to navigate.

    While these new ways have impacted every aspect of technology including development, testing and project management, infrastructure and operations have remained the last bastions of traditional thinking, practices and approaches. Even with the rapid rise of DevOps practices in the recent years, we have just seen pockets of change in the infrastructure space, be it adoption of infrastructure-as-code practice, cloud in its numerous variants (private, public or hybrid) or containers and cloud-native technologies. But these changes all fall short of an enterprise-scale change that matters. What is missing is a systemic view of infrastructure as a value stream and transformation that ventures beyond the skin-deep changes limited to a few front-end digital capabilities.

    Infrastructure Transformation on the Horizon

    However, this is changing now; one by one, the barriers to infrastructure agility are breaking down. To put it simply, there are four dimensions of this change, based on various enterprise transformation initiatives that I have been involved over the years

    Radical new Operating Models

    New operating models are emerging to meet the business demand for infrastructure agility. There are primarily five patterns or a combination that enterprise are espousing in the operating model space:

    1. Shared service: This typically involves applying lean, value-stream mapping and Kanban techniques—in simple terms, the emphasis is on transparency, business-aligned prioritization of work and limiting work in progress.
    2. Responsive shared service: In this model, specific infrastructure members are “seconded” to application squads for more responsive service. However, there are limits to secondment model, in the ability to scale beyond a few iconic programs of work.
    3. Cross-skilling: This model involves infrastructure and application team members learning skills across each other’s disciplines with the goal of making delivery teams self-reliant.
    4. Disrupting with cloud: As the name suggests, enterprises are disrupting their own traditional infrastructure capabilities by aggressively pursuing private, public and hybrid cloud capabilities.
    5. Insourcing: Increasingly, there is a trend to insource responsive cloud and DevOps-based services to near-shore locations. “Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively),” according to Gartner’s survey of CEOs in 2017.

    Reimagining the Legacy Technology Stack

    Legacy systems based on technologies such as the AS400 or mainframes have been the bedrocks of technology for decades, but they also have been blamed for constraining agility. Many organizations have realized that replacing legacy systems with open system stacks is not an easy feat. Consider the fact that IBM continues to report an increase in mainframe sales over the last few years, including Q4 2017. This points to the fact that legacy will be part of the enterprise landscape for years to come—as such, incumbents need to be able to leverage the legacy stack to compete with digital challengers who are unencumbered by similar technology constraints.

    However, it is not all somber. There is a new wave of optimism driven by old guards, including CA and IBM, and new, including Compuware and ARCAD, that are bringing modern engineering practices such as continuous integrationcontinuous delivery (CI/CD), automated code analysis, virtualization, lightweight integration and test automation to these platforms. These new practices not only give these systems a new lease on life, but they also enable modern enterprise systems to be built iterative and incrementally—and not be handicapped by legacy constraints anymore.

    Intelligent Enterprise Resource Planning Software

    ERP software such as SAP/R3 are the backbone of many enterprises across industries. Historically, ERP software products have not kept up to speed with modern engineering practices and flexible architecture, which are fundamental to agility. The good news is that the ERP landscape is changing as product vendors are embracing cloud and API-led integration—IDC calls this “intelligent ERP” or “i-ERP.” Consider this: In 2025, SAP/R3, the largest ERP product in use, will no longer be supported officially, and enterprise planning programs (albeit, in a waterfall way) will move to SAP HANA Enterprise Cloud, the company’s new generation ERP platform.

    Culture and People

    Years of the drumbeat of Lean, Agile and DevOps ways is yielding results, especially in those organizations that see this as a people change as much as technology change. People in the infrastructure world are changing  from operating being behind a queue toward being customer-focused, collaborative and value-seeking. Organizations need to address the structures that restrained it from moving forward on the journey. Traditional organizational structures don’t account for team strengths, nor do they give everyone fair input in regards to overall direction. Rather, structures should be set up that allow managers to empower teams instead of teams living to carry out management demands.

    Ultimately, the key to creating agile and responsive infrastructure in organizations starts at the top, from the CXOs who need to realize the scale of change and inspire their teams on the need for change—or face extinction.

    — Aditya Vadaganadam

  • Culture Change: Where It Matters in DevOps

    Culture Change: Where It Matters in DevOps

    Red SquareLori and I were in Russia in the late ’90s. It was an interesting dichotomy of life in a changing country. While we were there, the government devalued the ruble—just cut three zeros off the end of everything—to bring it into historical line with other world currencies. It was odd, because there was a mass of old money and a smattering of new, and most systems were not yet reconfigured to handle the new prices. Thus we paid 180,000 rubles to fly from Moscow to Rostov.

    But the physical implications were not the issue. The cultural implications were. We stayed with a very nice host family in Moscow, and talked long with them about pretty much everything. The older generation tended toward the old system, while the younger generation toward the new. Thus, the father of the family, in his 50s, blamed the west (specifically the United States, but since we were from the United States, I think the vodka made him stress that part) for losing his job as an astrophysicist. He also blamed the west for their currency woes. If yesterday, you had half a million rubles in the bank, today it was 500, so his angst was understandable. He blamed trade issues for that. His wife agreed with him, and scolded us for buying them nice things, since they would have to pay to keep them usable.

    Their adult son—and indeed most of the younger  generation—was the polar opposite. The younger generation thrived in the new environment, saw a bright future and laughed at today’s misfortune. It would be better tomorrow, and they were adapting to the new open environment to make sure it was.

    No, this is not a “get out of the way with your old thinking” blog. It’s a “be smart with your new thinking” blog. One problem endemic to the youth of Russian culture when we were there was they believed the rules no longer applied rather than believing there were new rules and new ways to interpret the old rules. It got many into trouble.

    To Quote a Friend: Culture, It’s a Thing

    There are some in the DevOps community who like to talk only about culture, because the non-automation benefits of DevOps are most felt in culture change. This is a not-unreasonable stance, and though I am definitely an aficionado of the automation side of DevOps, I see the benefits of culture change and embrace them where they are most impactful. I also acknowledge that in a full DevOps implementation culture change is inevitable.

    One place where most organizations could put more forethought—regardless of how the project is developed/deployed— is in releases. Think this through as a customer, not as a DevOps engineer. You have been burned by companies horribly missing a deadline after announcing features that you were waiting for (most of us have, anyway). By this point you have also been burned by companies releasing with the feature you wanted, only to find that it barely (if at all) worked, but now that it was released, the company would make it better over time.

    Now switch back to being an IT professional. We know the pressures and issues around releases.

    I think the biggest improvement commercial enterprises can make is to decouple marketing releases from Dev releases—to watch a project go through CI/CT/CD/ARA until it is solid, and only then start planning a release date. While this isn’t fully in tune with rapid delivery, the marketing team has a whole set of activities to perform that are dependent upon a certain level of functionality. Weekly stand-ups and continuous delivery do not make that functionality real on the date it was promised, everyone involved in the process knows that. So planning like it will be is as inefficient as writing code before you have a product idea.

    For internal teams, it’s a little bit different. There is the opportunity for Dev/Release engineers to stay in contact with representatives of the customer (normally managers or team leads, but whoever represents the customer), and adjust everything. Expectations can be managed if a certain functionality prove difficult to get working right, or release dates can be managed except in the most politically charged environments, and slight changes can be made to requirements—things such as, “Well, if we do it this way, we can meet deadlines, but it will impact this other thing,” can be brought to the customer. Having a representative of the customers on the team is sort of like disassociating marketing release from DevOps delivery: There is the chance to make sure it’s right before it hits users’ hands.

    Oh Yeah, Culture

    But I’m not here to tell you how to manage the process, I’m really here to talk about the culture. It used to be that if a needed feature wasn’t ready, the feature was cut or the release was delayed. All that Agile and DevOps have really added at that late stage in the game is a third option—release it with a substandard feature.

    In the end, either users (in an enterprise setting) or someone looking out for users (in a commercial setting) need to make that call. Far too often, Dev and Ops are making it, and users are suffering for it. Change that. Give the power to those you are working for. The app you’re developing is aimed to serve a purpose for a set of users. If a new release does not offer them what they need—even if you can check a box and say it’s in there—then don’t release.

    The thing combined Agile and DevOps does generally give us is more predictive ability. It’s not perfect, but we do know sooner if there will be problems. Generally speaking, it is easier to slip release dates early in the process, simply because the release is not as anticipated.

    It’s About Why

    Some teams that used to cut features because they couldn’t meet deadlines are now teams that put in sub-standard features so they do meet deadlines. There are good reasons to plan a graduated rollout of a feature or feature set, but “couldn’t get it implemented” isn’t one of them. The granularity of Agile means that estimates should be tighter, because you’re estimating smaller chunks at a time. The ability of DevOps to deliver a more consistent end product and configured environment should mean there is less delay in the deployment cycle. So the correct answer is to find out what users want, go that route and then examine where you went wrong so you can do better next time. Sometimes “do better” will mean better estimates, sometimes it will mean using less new or questionable technology, sometimes it will mean controlling change in the environment outside the project—or accounting for it in estimates. But improvement should be the goal, all of the time.

    In the end, you’re creating a tool designed to serve the needs of a certain set of users. I don’t want to be sold a snappy laptop with an advertised 1TB SSD drive only to get delivered the same laptop with an external, full height, MFM encoded drive touting a whopping 110 MB. So why would it be okay to do the equivalent in software (or, in a couple cases I know the details of, firmware)? Don’t be silly, of course that’s extreme. Maybe the machine comes set up to boot from 5.25-inch floppy instead, to reduce shipping overhead.

    — Don Macvittie

  • It’s About Communication, not Silos

    It’s About Communication, not Silos

    Too often, when enterprise folks talk with DevOps aficionados, we get a loud chorus of “Culture Change” and “Take down the silos,” and frankly that scares any sane enterprise IT person. Not because they fear change, but because they fear that those of us who are fans of end-to-end DevOps have no clue what we’re talking about.

    Don't throw the baby out with the bath water.
    Baby vs. Bath Water – By Richfife (Own work) [Public domain], via Wikimedia Commons
    And to some extent, that impression is not misguided. There will still be a development team. There still needs to be a selection of operational specialists. Eliminating these are not changes anyone is proposing for enterprise use. Indeed, if an organization has an investment in Cisco UCS, they still need a UCS specialist. The system is complex, and the more knowledge you have of it, the better it can be managed. Sure, automating as much as possible is a worthy goal for all such specializations, but even automated, the UCS person still needs to be able to expand/modify/maintain the automation. Another good example is NetOps (or whatever we’re calling it today): The person with in-depth knowledge of your ADC will still need to have in-depth knowledge of your ADC.

    So, then, what we’re really talking about is increased communication. We’re talking about a small, cross-functional team to smooth the areas that DevOps is very good at, but specialized knowledge is still needed. Increasing communication is key to every DevOps implementation, regardless of tool set; the ability to predict future work based on updates is almost essential in any faster-moving environment. Indeed, Lori and I were discussing this morning, wondering how many of those enterprise Slack channels are being used to provide a running commentary across the team of what is happening upstream. But that’s another blog, I think.

    It is not that DevOps people are clueless, nor is it that they want to eliminate specializations (well, some claim to want to, but they have a marketing reason to do so), but rather, it seems that many of us DevOps folks have gotten so wrapped up in change (it is a big change to streamline both Dev and Ops) that the baby is being thrown out with the linguistic bathwater.

    If you’re talking DevOps, talk about increasing communication, not destroying silos. Secure DevOps is evolving now, and shows the model more clearly because of it—developers and ops are given more of a role in security and auditing, but they are taught and overseen by the security team. This does not eliminate security, but does increase the security of what is being produced.

    While we’re at it, switch from bulk “Culture Change,” too. While there is a fair amount of culture change—moving to proactive and more frequent, with roadblocks minimized or removed and non-essential changes treated as, well, non-essential. But “streamlined dev/operations” might just be a better way to talk about it. After all, the brazen voices still seem to sing of wrecking balls from on high crashing down, and that’s not an effective way to get buy-in for change.

    In the end, the point is more repeatable, more stable, more manageable processes and systems. Let’s talk more about that, and less about Destructor, shall we? Sell the concept; don’t force-feed it. There’s a lot of good to be had, and using terminology that is both confusing (Define “Culture Change” in a generic, applicable sense) and often frightening is not helping people understand (or want to understand) how it can help.

    — Don Macvittie

  • DevOps: The Innovation Power Couple

    DevOps: The Innovation Power Couple

    If “Dev” and “Ops” are the power couple of tech, “DevOps” is the holy matrimony that takes innovation from trainwreck to fast and repeatable. At most businesses, however, Dev and Ops still sleep in separate rooms and agree only on their mutual contempt.

    Dev (Development) and Ops (IT Operations) usually are divorced or ready to serve the papers because their incentives clash. In Ops’ opinion, Dev is an idiot—always out late drinking with friends, he comes up with wild ideas and wants to implement them immediately. Dev can’t make anything work on real servers and can’t write scalable, stable code.

    To Dev, Ops is a total code-blocker—she makes Dev go through “change management boards” and slows down progress. She lets the competition get to market first. So every day, Dev and Ops have an angry shouting match that ends in tears.

    I wish I were exaggerating. My coworker Brandon Cipes once walked into an interview for a product development position. The interviewer broke down crying because the relationship between Dev and Ops had gotten that nasty. They refused to meet with each other, let alone be in the same room.

    When Dev and Ops have a dysfunctional relationship, they struggle to communicate, collaborate and get results. Their organization will fail at innovation because it lacks the cultural, technological and procedural base to do otherwise.

    The missing base is DevOps. It’s a unified strategy for Development and IT Operations, and implementing it can have the following effects:

    1. Communication Becomes Unavoidable

    Normally, Dev and Ops play “telephone” because they’re physically separated and have too many points of communication. Emails, IMs, grudgingly accepted meetings and passing conversations ensure Dev and Ops never get the full message.

    DevOps fixes communication by assigning Dev and Ops personnel to the same teams. They sit in one room and work in a single squad (a.k.a. a pod or team) of no more than eight to 10 people. If they turn their heads, they see each other’s beautiful faces. Until promotions or career change do them apart, they can’t avoid talking and working toward common goals.

    In essence, DevOps puts “cross-functional” teams together and thereby eliminates hand-offs. Fewer points of contact, less telephone, better communications.

    1. Collaboration Gets Automated

    For many Dev and Ops teams, “collaboration” is another word for bureaucracy. It’s TPS report-ish stuff characterized by change review board meetings and laborious documents that tell Ops how to deploy new code. Dev and Ops might accidentally (or intentionally) withhold information from each other.

    In DevOps, collaboration is automated. Instead of change review board meetings, you use version-controlled software. The hand-offs from Dev to QA and QA to Ops are done by machine. A script deploys the code for Ops so there’s no risk of misfiring.

    “Collaboration” is no longer an ordeal or choice. Documenting and sharing the squad’s collective knowledge is wired into the process.

    1. Fast and Stable Releases

    Normally, a software deployment is like a sloth trying to cross US 101: slow, awkward and soon to be roadkill. That’s all thanks to bad communication and bad collaboration.

    With DevOps, you catch problems before they go live. Test automation prevents any need for manual checks. One person corrects the problem in a matter of minutes whereas before, a team of five might spend eight hours tracking down and fixing one bug. Ops feels confident that tested code won’t cause havoc.

    Thus, the upshot of DevOps is speed and stability. Before, Dev and Ops delivered maybe a few times a year and faced regular breakdowns. DevOps can deliver multiple times daily without a hitch.

    Say ‘I Do’

    DevOps is a cultural, procedural and technological transformation. As in a marriage, both partners are responsible for good outcomes. Linked as they are on one squad, Dev learns to care about stability and Ops begins to value innovation.

    If “agile” is about making businesses nimble and quick, DevOps is about applying agile principles to technological development and operations. Ultimately, it’s about beating your competition to the next big thing.

    Dev, easy on the drinking escapades. Ops, live a little. Tie the DevOps knot and make some innovation babies.

    About the Author / Zubin Irani

    Zubin Irani is co-founder and CEO of cPrime, a full-service consultancy that focuses on agile transformations and project delivery solutions for hundreds of software teams, including more than 50 of the Fortune 100. Connect with him on LinkedIn.

  • Baselining Metrics to Measure DevOps ROI

    Baselining Metrics to Measure DevOps ROI

    Assessing the ROI of DevOps normally is done against a company’s baseline cost. The problem is, most organizations do not collect or evaluate the cost of “automating and delivering” innovation; they usually are more focused on the innovation product itself. As an example, if a company creates an application hosted on the web that offers its customers the ability to purchase inventory, the company usually is obsessed with knowing how that application performs: How many people are using it? How often does it fail due to bugs? How many sales are made? The company typically focuses on the end product—on the application as it touches customers and potential customers. The delivery process that precedes the application being loaded into production is not usually the subject of intense scrutiny. At least, most organizations are not evaluating the speed of delivery and process effectiveness of delivery prior to an embrace of DevOps methods and tools.

    This lack of scrutiny results in the lack of a baseline to compare against. Say, for example, a typical programmer (prior to DevOps) uses a mix of scripts, human intelligence and human verification to create and verify a build. Prior to DevOps, the goal is simply to create the build and get it out there to look at it, and decide what to do next. Most programmers are not obsessed with how efficient this entire process is; for them, it is a means to an end. So most programmers do not keep records of the average amount of time it takes to create the build from beginning to end. This is even more true of the deployment process. Once a build has been created (again prior to DevOps), getting it deployed to the target environment might involve a few different teams (depending on the class of test environment that is targeted). The process may involve email requests to other support teams or filling out a ticket to get it done. Once again, most organizations spend little time tracking this process from end to end; it is only ever a means to an end.

    If, in fact, an organization was watching closely how long it takes to get a build created and how long it takes to get a deployment completed, that organization would be running toward DevOps at full speed to see improvements it otherwise could not achieve. It is the things we do not measure that receive little attention—until they break. Once our deployment process has become so onerous or so complicated or so burdened with approvals required that nearly nothing gets deployed, then we begin to look at it. This creates a culture of “squeaky wheel syndrome,” which makes both our development and our operations teams focus only on reactionary issues, while proactive concerns die on the side of the road. There is no time to invent proactive improvements when you are constantly fighting the fires of something else that is seriously broken. This culture must also change if DevOps is to succeed broadly in your organization, so keep note of how far it may be infected in how you run things today.

    Preparing for Collection

    Given that most companies lack a real baseline to compare against in this area, realize that collecting one will take an investment itself. This baseline metrics collection cost is usually added to the cost of the investment in DevOps. It is a bit unfair, as you are effectively saying, the soap company will also have to bear the cost of determining how dirty we are before we invest in the soap that will clean us. The makers of soap tend to think you already have a sense of how dirty you are, or you would not be looking at buying soap in the first place. But without an accurate assessment of knowing the extent of the problems (in this case, the investment of time you spend today), you will never know the ROI of having made the improvement of DevOps (the after picture).

    Also, keep in mind that measuring anything manual is difficult. This sounds like a saying from Captain Obvious, but consider that manual work efforts require additional manual work efforts to capture them and record them in some kind of system. If, as an example, my typical programmer spends 15 minutes of every build doing human verification of the build, this amount of time is reflected nowhere. Hourly employees typically record how many hours they work per day, not what tasks they spent during the day. Even the employees who log work hours more discreetly tend to record only that they spent “x” amount of hours doing “development,” not what general task categories occurred within the heading “development.” So there are no electronic records out there that can be gathered automatically that will reflect the 15 minutes spent doing human verification of a generic build of an application. The only way to know this is a personal interview, followed by someone keying the data into a collection system of some sort.

    Knowing that the information you seek for a baseline will come in human interactions as well as some automated logs, start the collection using a tool that allows for maximum flexibility for those efforts. Spreadsheets come to mind. When the effort to collect a baseline begins, you will have some ideas about the kinds of data you wish to collect and how it might exist in your organization. But it is impossible to know exactly how the resulting efforts will be completed. In short, you don’t know what you don’t know. While you collect metrics you will invariably come across someone who reveals critical metrics-related information you were not “planning” to collect. But once the revelation is made, you will need to incorporate the “new” information to really provide an accurate baseline assessment.

    Determining the Baseline

    The next step is to begin the collection process itself. The critical data to examine usually can be gathered by looking at “human” time involved in a given core “process” of the automation and delivery of innovation, and then the “machine” time involved as well. For example, the time a programmer must spend prior to the launch of a build (not the coding time)—all the prep work doubling checking that the system is ready to launch the build scripts (or ready to manually push the buttons)—would be considered “human” time. The execution of the scripts to create the build would be considered “machine” time. Then, all the work done after the build is created to verify it and make sure things are as the programmer expected, again can be put into the “human” time category. DevOps will systemically automate both the pre- and post-time activities the “human” currently invests, so all that time will count in the ROI.

    The above example is good when one person has full control of a process from end to end. When other teams must get involved to complete a task, the “human” time begins to skyrocket. If, for example, a programmer or release manager, must get a request email (or ticket system equivalent) to deploy a particular build to a particular target environment, the entire life cycle of that ticket becomes part of the “human” time you need to track as your baseline metric. Even when shops create a two-day service level agreement (SLA) for turnaround, it still represents two days of delay (due to “process” time) in the life cycle of a deployment. The time “humans” actually spend reading requests, approving requests and routing requests is all time that DevOps will automate and eliminate. Finally, when the correct support team (usually Ops) pushes their own script buttons to do the deploy, that part of this process is once again “machine” time. As you can imagine, the end-to-end time of a given deployment can be days in the pre-DevOps methods and only minutes in the post-DevOps methods. Self-service deployments can reduce this time even farther, removing handoffs, reducing risks and delivering innovation at will.

    Further classification of this metric data can be useful as well. For example, you may wish to break down “machine” time into its relevant subcategories such as build script execution, deploy script execution, test script execution and release script execution. You also may want to break down the “human” time a bit further as well into pre-build/deploy verification, post-build/deploy verification and test script results evaluation. Finally, you may wish to break “process” time down further into request generation, request routing, request approval, request declination and request notification. DevOps will be able to give you discreet visibility into the time you saved in these subcategories, although since baselining is generally a one-and-done effort, you may not want to hunt this level of detail. It is down the road where this kind of subclassification becomes useful—for example when you are trying to determine if one set of tests runs faster than another or one cloud provider runs faster than another.

    Evaluating the Baseline

    Having gone through this exercise, a hidden or secondary benefit emerges. Your organization begins to understand much better what it has been investing in the current delivery of innovation processes. Generally, immediate areas of concern emerge and provide the DevOps services delivery with a road map for which areas to attack first to provide the company with the biggest bang for the buck. Without a baseline effort such as this in place, your DevOps services delivery plan will be based on anecdotal thinking or on executive mandate that may not be substantiated by the data on the floor. Having a baseline provides a road map for delivery based on concrete evidence on what should matter most to the business in making improvements. No one can argue with the numbers (assuming they were collected with care). The road map may reveal which applications in your organizations portfolio should be targeted first for DevOps.

    Also, your organization now understands much better “what” data in this process it sees as relevant to continue collecting even after DevOps is implemented. As DevOps is primarily an automation set of tools and methods, DevOps should be able to deliver these metrics in an ongoing basis. This allows continued metrics efforts to be automated without further human labor and can provide continuing proof of the value of DevOps to the organization, as over time the numbers continue to improve. Since the lion’s share of manual tasks disappear with DevOps in place, there should be no reason to have to manually collect metrics data as you move forward.

    Finally, having an automated metrics collection system put in place by DevOps, should lead to the next evolution in thinking: simulation. Well after the initial ROI for DevOps services has received the accolades it is due, an automated metrics collection system should provide all the raw data needed for some predictive analysis. Tweaking variables or process points or “machine” effectiveness should result in increased speed of delivery that can be measured (even before it is reality) based on the data you have been collecting systemically. Understanding the impacts of these changes is worth more than its weight in gold, because you can weed out the planned changes that simulation advises against before they even hit the road map, let alone occur in your world.

    Impacts to the Bottom Line

    There is already enough anecdotal evidence in existence to entice companies to embrace the DevOps journey. However, as your strategy begins to look to deepen down the stack from application code level to middleware, database and operating system, each layer could be assessed against a baseline to determine if your road map is sound and, more importantly, in the right order for your best ROI. This applies as well as you look to expand your DevOps journey laterally with additional services such as automated testing and evaluation, gated progression, automated provisioning, release orchestration, configuration management database (CMDB) integration, production provisioning on demand and monitoring integration. Each new service can be assessed against a baseline to determine if its ROI still meets the demands of your finance department and if your road map here is in the right order for biggest bang for the buck.

    The subtle win by performing baselining is the culture change it dispenses through your entire organization. Baseline metrics tell your development team and your operations teams (as well as the business units looking on) that you intend to measure performance and improve it systemically. Just because something was not examined before does not mean it will remain so, and a forest fire does not have to be the motivation to do so. DevOps is a proactive improvement to your delivery of automation. Collecting that baseline for your ROI, begins to seed the idea that proactive improvements are important to your executive teams. It is a demonstration of action over platitudes. It begins to eliminate the forest-fire responses in your employees, and creates a new forward thinking point of view. This cultural change is worth more to your company than any implementation of any one given tool or method, it goes back to changing how you think about delivering innovation in your individual job. That is what DevOps can do best.

    To continue the conversation, feel free to contact me …