devopsy.kinsta.cloud

Tag: technology adoption

  • Puppet Survey Suggests DevOps Adoption is Stagnant

    Puppet Survey Suggests DevOps Adoption is Stagnant

    Puppet today published an annual State of DevOps report that suggests overall adoption of DevOps practices has stagnated.

    The survey of 2,650 IT, development and information security professionals finds 83% are implementing DevOps practices, to a degree. However, only 18% of respondents are working for organizations that have highly evolved, automated DevOps processes in place. More than three-quarters of respondents (78%) are somewhere along the path toward achieving that goal.

    A full 90% of highly evolved DevOps teams have automated most repetitive tasks compared to only 67% of mid-level organizations, the survey found. In addition, 91% of highly evolved teams report a clear understanding of their responsibilities.

    Not surprisingly, the biggest hurdles identified are more cultural than technical. The most common culture blockers at mid-level organizations include a culture that discourages risk (21%), unclear responsibilities (20%), deprioritizing fast flow optimization (18%) and insufficient feedback loops (17%). In contrast, less than 2% of highly evolved organizations report resistance to DevOps from the executive level, the Puppet report found.

    Nigel Kersten, a field CTO at Puppet, said during an online panel that, after more than a decade of DevOps advocacy, people continue to be the biggest limiting factor when it comes to adoption. Specifically, from a compensation perspective, many IT operations personnel tend to feel undervalued compared to developers, noted Kersten.

    Another challenge enterprises encounter is trying to balance the need to create a standardized IT environment that can be managed and secured consistently and the desire of DevOps teams to embrace new tools as they see fit. Senior IT executives often tend to make platform decisions based on cost criteria that don’t always account for the need to enable agile development methodologies. Most of those platforms are designed to be managed by an IT administrator using a graphical tool rather than via a command line interface (CLI) and application programming interfaces (APIs) that appeal to DevOps teams.

    As a result, individual pockets of DevOps teams that select and maintain a platform of their choosing are emerging within enterprise IT organizations. Those teams often view their chosen platform as a better alternative for advancing developer productivity. Finding and retaining site reliability engineers (SREs), for example, to manage those DevOps platforms is a major challenge for most enterprise IT organizations. Most IT administrators lack the programming skills needed to become an SRE, and it’s not clear how many IT administers are inclined to acquire those skills.

    Conversely, it’s not clear how many programmers want to programmatically manage IT infrastructure at the expense of time they would otherwise devote to writing code. Organizations that can only hire a limited number of developers may not want to shift responsibility for managing IT operations to the proverbial left simply because they need more code to be written faster. Finding and retaining developers, in many cases, is just as much a challenge as hiring and retaining SREs.

    Advances in automation and artificial intelligence (AI) should make it easier for organizations to embrace DevOps best practices in the months and years ahead. However, it should be apparent to all that adoption of those best practices across an entire enterprise still requires a significant amount of time and effort, and will for many years to come.

  • Building Effective Digital Transformations

    Building Effective Digital Transformations

    Enterprises have reportedly spent upwards of $5 trillion on their digital transformation efforts, yet they’re also not hitting their objectives. In fact, in many industries, such as banking, health care and utilities, only half of organizations are keeping pace with their digital transformation expectations.

    According to Joe Garber, global head of strategy and solutions at Micro Focus, it’s essential to set goals early and clearly. Garber said most organizations find that their primary objectives for digital transformation fall into one of four buckets: optimizing for speed by prioritizing enterprise DevOps, maximizing agility with hybrid IT, driving insights with predictive analytics, and enhancing the ability to protect users, applications and data with advanced security measures. “Establishing a framework early on helps inform next steps,” he said.

    Once those categories are in place and prioritized, many organizations can benefit from starting small with one department or one geography. This will enable organizations to test their theories and control their trials more closely, but also leverage positive results to establish a business case for future projects, Garber said. “Just be careful to think broadly and long-term when you decide what technology to deploy—software that may be good for a small-scale operation can break down or paint you into a corner if you’re not looking at the big picture and select technology that can support your enterprisewide requirements,” he said.

    Contentstack chief operating officer Matthew Baier advises organizations to pick a real-world challenge and provide a proof of concept that could garner a quick win. Be sure to note upfront the goals and key performance indicators. “Another piece of advice is to include both the affected business and IT teams in the project, to capture feedback holistically about what impact digital transformation efforts have across the organization,” he advised.

    Nabil Freij, CEO at GlobalVision International said pilot projects are key to effective implementations. “Before transforming your entire processes, you need to make sure that the proposed transformation will bring sufficient monetary, quality and/or schedule benefits before they are proliferated across the board,” he said. “This is not hard to do. Be selective with the pilots that you undertake. Make sure that they are representative of the majority of the work that your teams undertake on a regular basis. Create key metrics that are important to meet and measure and track them. After a few pilot projects, you will have enough data to start making conclusions regarding further testing or regarding starting across the board or limited implementations.”

    With objectives down, it’s essential to get the right people in place. “The first step in developing a successful digital transformation strategy is bringing together the right people to assess the current state of the workplace environment,” said Dave Maffei, president and chief revenue officer at Akumina.

    “To get the right feedback, organizations should deploy a survey and interview their employees across business units and job functions to understand what technology and processes they value most, as well as what challenges they face while performing their job duties,” said Maffei. “Without completing this essential step, organizations won’t truly understand what solution they need and could be missing out on solving existing challenges to the overall employee experience. Having internal feedback will allow organizations to understand what their ideal solution might look like.”

    Larry Wolff, CEO, Wolff StrategyPartners, added that a team of digital transformers should be established, if possible. “If an enterprise has the luxury of time, such as no imminent existential threat, then they may want to set up a single, high-performing team to tackle an initial phase of the digital transformation. Set them up for success so that others want to emulate them and drive the next phases,” he said.

    “People are naturally apprehensive about change. Drive one positive change initiative to diminish those fears and get more and more people on board,” he added.

    — George V. Hulme

  • Taking Stock of DevOps: Where to from Here?

    Taking Stock of DevOps: Where to from Here?

    Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

    First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

    Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

    So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

    … a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

    That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

    DevOps Works Because It’s Good for Business

    Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

    That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

    An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

    Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

    DevOps Shouldn’t Start and End in IT

    The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

    This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

    Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

    From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.