devopsy.kinsta.cloud

Category: DevOps Culture

  • ‘DevOps in the Multicloud World’ Virtual Summit Puts IBM Z in the Spotlight

    ‘DevOps in the Multicloud World’ Virtual Summit Puts IBM Z in the Spotlight

    Got mainframes on the mind? Wonder how you can unlock the value of the platform for mission critical workloads? Trying to figure out where IBM Z fits in an increasingly cloud native IT environment? Those questions and others will be discussed in an upcoming virtual summit that explores the role of IBM Z —within the context of delivering higher efficiency and greater productivity for hybrid multicloud environments.

    “DevOps in the Multicloud World” virtual summit is scheduled to take place Oct. 24, starting at 10 a.m. Eastern. The day-long event features a passel of IBM experts, partners and customers sharing their knowledge and offering a deep dive into how to build and manage hybrid applications for agility in a multicloud world of continuous delivery. Panels and presentations will be held on a multitude of topics ranging from open source and DevOps to provisioning and user experience—all with a focus on the IBM Z systems.

    In addition, IBM customers will discuss how they’ve successfully included IBM Z in their multicloud strategies to improve their operations and bring real value to their end-user customers.

    Featured speakers include:

      • Barry Baker, Vice President, IBM Z Software
      • Rosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology, IBM
      • Mike Fulton, IBM Distinguished Engineer, CTO Enterprise DevOps, IBM Systems
      • Keith Wilson, Principal Technical Architect, USAA
      • Patrick Wawrzoszek, Senior Programmer Analyst, Scotiabank
      • James Gill, Mainframe DevOps Engineer, Triton Consulting (Lloyds Banking Group)
      • Arun Sharma, Product Manager Core Banking, DXC Technology
      • and more….

    In between sessions, attendees can roam the virtual conference hall, where they can chat and socialize with other attendees including IBM staff, and visit the virtual expo floor, featuring virtual solution zone stands equipped with video, downloads and even prizes for attendees.

    Perhaps best of all? Because this is a virtual event, you don’t have to leave the comfort of your own environs. Feel free to log in wearing your pajamas, even—we don’t judge!

    This event is free, but space is limited, so register now to reserve your spot today!

    — Charlene O’Hanlon

  • Legacy Systems Prove to be Digital Transformation Headwind

    Legacy Systems Prove to be Digital Transformation Headwind

    In a survey of 450 digital transformation leaders, a sizable 73% of respondents said that, through digital innovation, they have made significant or better improvements to the end-user experience. Twenty-two percent report much more significant results than that, they self-reported as having transformed or completely revolutionized end-user experience. That’s considerably higher than the 15% in the same survey in the previous year.

    These results, from the Couchbase 2019 Digital Transformation Report conducted within the U.S., U.K., France and Germany, are in stark contrast to results of a recent Kony survey which found, despite $5 trillion having been spent by enterprises on digital transformation, the vast majority of digital transformation initiatives fall short of customer expectations. Still, when it comes to digital transformation success, at least as far as its impact on customer experience, success is in the eye of the beholder.

    Of the $5 trillion spent over recent years, much of it has been invested in backend system improvements. If the Couchbase survey is any indication, there remains considerably more spending on back end and legacy systems. Despite the feeling of success cited in the survey, 86% of respondents said they are prevented from pursuing new digital services or transformation projects.

    Here’s why:

    • That 86% said factors including reliance on a legacy technology, complexity of implementing technologies and lack of resources and skills had prevented them from pursuing a new digital service or other transformation project their organization wanted.
    • A total of 55% said their reliance on relational databases somewhat limited their ability to implement digital transformation projects, while 17% said “severely.”
    • An 81% have had a digital transformation project fail, suffer a significant delay or be scaled back in the last 12 months.
    • A total of 42% said they were behind schedule, or at risk of falling behind, on their most significant digital transformation project.
    • A 73% said, while the huge potential of digital projects is often talked about, most of the time they fall short of being truly transformational or revolutionary–albeit a fall compared to the previous two years.

    Perhaps part of the challenge enterprises face is they are reacting to market pressure and not being led by business needs or visions for the business’s future created inhouse. According to the Couchbase survey, 52% have their digital transformation strategies set by IT and not business leadership. The drivers for these transformations tend to be, the survey found, reacting to business pressure such as customer demands for new services or responding to regulatory mandates. Surprisingly, the survey found, only 8% of transformative ideas executed are brainstormed from within the organization.

    Perhaps part of the reason why organizations are so reactive is because the rate of disruption is accelerating. According to the survey, 91% of respondents believe the speed of disruption in their industry has accelerated. In fact, 40% of respondents categorized that acceleration as rapid. Moreover, survey respondents plan on spending more on digital disruption this year over last, $30 million compared to $27 million.

    — George V. Hulme

  • Why DevOps is Like Football

    Why DevOps is Like Football

    When it’s done right, DevOps is an impressive feat. You have groups of professionals all melding together as one large team working toward a common goal. The groups–and the individuals themselves–perform their roles and hand off tasks to each other at just the right times. They follow pre-designed plans, but they constantly tweak those plans, in real time, to deal with variables that threaten to undermine the whole mission.

    This is DevOps in action. But take a closer look at some of the descriptors above and ask yourself if it sounds like something else that’s starting to creep into a lot of conversations this time of year. If you’re a sports fan like me, this sounds just like football.

    Let’s face it, football parallels have been attached to all kinds of institutions and practices–everything from the military to business to marriage. The emphasis on discipline, teamwork and execution can apply to most initiatives in everyday life.

    But I’d argue that football’s very structure aligns especially well with what we do in DevOps.

    In football, the goal is to move the ball from the line of scrimmage to the end zone. In DevOps, we have our own starting and ending points. Think of our line of scrimmage as the point where features get added to the application and our end zone as the point where an application is successfully delivered to a customer. Football has its individual units (offense, defense, special teams) and we have ours (development, quality assurance and operations).

    In football, the offense players have different specialized skills and all work together to move the ball forward to reach the end zone. The players start with a set of instructions (plays), which they all understand. This is like automation in a DevOps environment. A DevOps team execute its own plays, collaborating and improvising as needed to achieve their shared goal.

    Picture what this would look like in a pro football game:

    • The quarterback passes the ball: Think of a software developer handing off the application to a test engineer.
    • Linemen block for the quarterback: This is like quality assurance continuously protecting the application from bugs that threaten to sack the whole project.
    • A receiver runs a route and catches the ball: This is similar to an operations engineer preparing a server and receiving the application.
    • A running back runs the ball into the end zone for a touchdown: The application is deployed. Goal!

    The team has worked together and achieved the goal–in this case, a touchdown. They will be able to repeat this success time and time again because they have repeatable plays and they collaborate.

    Without a DevOps approach imagine what a football game would look like:

    No Automation: The team has no plays. Nobody on the field has any idea what his assignment is on each snap, so players basically do their own thing. All the speedy, skilled players yell “Throw it to me!” This kind of freelancing might work for youngsters playing pick-up football, but it won’t work in a more advanced game.

    No Collaboration: The positions don’t work together. Even if team members have plays and know them, if the linemen don’t block as a unit, a play will fail. If a running back zigs when linemen are opening up a hole for him to zag, the defense will stop him.

    No Shared Objectives: If everybody knows the play but they’re only concerned about executing their parts of it, the offense won’t get far. Imagine:

    • The quarterback being concerned with just getting the ball in the air, not where it goes or even if it is caught. The receiver can worry about that. End result: Lots of failed passes–and probably a few interceptions.
    • Linemen will block, but they’re not worried about who to block or when. End result: Lots of quarterback sacks.
    • Receivers will run routes, but they’ll choose where they want to go. They might run beautifully, and even get open periodically. But if the quarterback doesn’t know where the receivers are, the team won’t complete many passes.

    Without a DevOps approach, the chances of getting a ball to the end zone would be very low. And when it did get there, the process would be messy and unrepeatable.

    When football is done right, teams defend well, score a lot of points and rack up victories. When DevOps is done right, organizations deliver high-quality software to customers in a rapid, repeatable and reliable way. DevOps, like football, codifies a winning process that serves a vast group of stakeholders both inside and outside of the organizations playing the game.

    — Brian Dawson

  • How to Overcome Resistance to DevOps Implementation

    How to Overcome Resistance to DevOps Implementation

    The number of businesses adopting DevOps to make software releases happen faster without compromising on software quality continues to grow. Within the next five years, the DevOps market is expected to reach almost $13 billion. If you are among those who’ve decided to make a shift to DevOps, you are likely to experience resistance coming from the departments involved in a software development life cycle (SDLC), and even from end users, at the start of your DevOps journey.

    In this article, we will outline the reasons why your employees may resist the DevOps approach and show how to overcome their resistance.

    About DevOps Approach Implementation

    Among the benefits DevOps brings are the fast provision of new infrastructure, quick and reliable delivery of software updates, fewer post-release errors due to the implementation of continuous testing and the alignment of testing and production environments, etc. DevOps implementation requires efforts in establishing tight collaboration between the development, QA and operations teams, as well as adopting new tools and methodologies, such as containerization, IT infrastructure automation, continuous integration and continuous delivery (CI/CD) tools.

    A new approach calls for project managers, developers, infrastructure management, QA and operations teams to leave their comfort zones and get used to new working conditions. However, each stakeholder has reasons to resist DevOps implementation and requires a tailored approach to overcome them.

    The Resistance of Project Managers

    Why They May Resist

    Project managers (PMs) are the first to face the changes when the DevOps approach comes into force. Their resistance originates from a range of new duties, new responsibility and knowledge they need to add to their playbook, such as:

    • Persuading development, QA and operations teams involved in SDLC in the DevOps necessity.
    • Establishing constant collaboration between developers, the QA team and the operations team.
    • Getting familiar with DevOps-specific tools and techniques (CI/CD, continuous monitoring, version control tools, etc.) as well as cloud computing technologies like AWS, Azure, Google Cloud Provider (GCP).

    How to Overcome Resistance

    PMs should become DevOps evangelists as they will be the ones who will contribute the most to overcome the resistance of other parties involved. A CIO should provide a PM with sufficient training on all DevOps-related aspects. Such training should include the management of the development, the QA team and the operations team in the context of close collaboration between them. It should also provide the PM with the understanding of DevOps methodologies and tools–containerization, infrastructure as code (IaC), continuous integration and continuous delivery (CI/CD), cloud technologies, etc.

    The Resistance of Developers

    Why They May Resist

    Developers may resist DevOps adoption due to the following reasons:

    • They are not excited by the necessity to work with infrastructure engineers closer and deal with operational issues if the operations team is not competent enough to address them on their own.
    • They are comfortable with the technology stack they’ve chosen for a particular project and not accustomed to caring about how familiar the other project team members are with these tools and technologies.

    How to Overcome Resistance

    PMs should embrace their soft skills to establish a mutual understanding between developers and infrastructure engineers. They should also make sure infrastructure engineers can work with the tools and technologies developers may use within the DevOps approach, e.g., Docker, Jenkins, by providing them with relevant training.

    The Resistance of a QA Team

    Why They May Resist

    A QA team may feel concerned about a faster SDLC DevOps implementation, since it entails less time for testing. Test engineers now need to acquire new skills prescribed by automation across the entire SDLC. In particular, they face the need to learn new tools for automated testing (Selenium, Appium, fMBT) and API testing (JMeter, Postman).

    How to Overcome Resistance

    To make QA engineers less risk-averse, QA managers in cooperation with PMs, should provide them with appropriate training (tools for automated testing and API testing) and show the advantages DevOps may bring. An opportunity to increase test engineers’ qualification level, less effort on testing activities than required with manual testing are among such benefits.

    The Resistance of an Infrastructure Department Manager

    Why They May Resist

    In the pre-DevOps times, an infrastructure department manager was responsible for controlling the design, configuration and delivery of infrastructure for development, testing and production. With DevOps on board and the IaC approach implemented, the infrastructure manager may feel as if they lose control over the IT infrastructure provisioning and management. What’s more, the scope of the infrastructure manager’s responsibilities extends greatly since they’ll need to run the infrastructure department as a competency center.

    How to Overcome Resistance

    A company’s CIO should explain the infrastructure manager their new responsibilities upfront. The infrastructure manager should stay assured that they change the area of control, not lose it. Within DevOps, the infrastructure department manager has to transform their approach to work. They must be able to help a PM correctly arrange the development, QA and operations team for each particular project taking into account project complexity and size. The infrastructure manager must be able to proactively deal with the cases when the team members involved in software development lack qualification for a project, and not wait until the lack in teams’ competencies results in the project prolongation, for example.

    The Resistance of Operations Engineers

    Why They May Resist

    With DevOps in place, the operations team will have to coordinate their efforts with developers and the QA team from the very beginning of the project, as well as regularly report to the PM on the tasks completed, which is not the usual work approach. To be able to work in the DevOps environment, operations engineers will also have to get familiar with a range of IT automation, version control and other tools. What’s more, the operations staff’s responsibilities will now include the provision of the information on the IT infrastructure functioning to business and technical stakeholders.

    How to Overcome Resistance

    To help an operations team adapt to the DevOps culture, the infrastructure department manager should deliver training to make operations engineers familiar with new tools and technologies they will need to use, e.g., version control systems (Git, Team Foundation Server), software deployment automation tools (Chef, Puppet), etc. A PM, in their turn, will need their soft skills to increase the operations team’s willingness to work in close alignment with development and QA teams.

    The Resistance of End Users

    Why They May Resist

    It may sound surprising, but even the primary beneficiaries of the DevOps approach implementation may resist the changes DevOps brings. There are two reasons for it:

    • The time available for software acceptance testing gets reduced due to a faster SDLC.
    • Acceptance testing becomes automated, and end users hardly trust automated tests.

    How to Overcome Resistance

    To dispel end users’ DevOps-related doubts, PMs must do their best to earn their trust by establishing strong communication with end users. If, for example, end users know software testing covers critical software functionality and the probability of post-release errors is minimized, their confidence in software reliability and the overall trust in the DevOps approach rises.

    In a Nutshell

    Each party involved in software development has its reasons to be suspicious when the DevOps approach is coming on board. New duties, close collaboration, the necessity to apply new tools and other DevOps-related changes may make project managers, developers, QA engineers, IT infrastructure managers, an operations team and even end users resist the new approach.

    To overcome the resistance, a company’s CIO should maintain open communication with each party involved in SDLC, explain their new duties and listen to their concerns. It’s essential to make sure each team member realizes what changes and advantages DevOps brings into SDLC. To ensure they have the necessary knowledge and skills, appropriate training should be provided to project managers, developers, QA team, IT infrastructure manager and the operations team.

    — Andrei Lipnitski

  • Before We Burn the Martech Silo

    Before We Burn the Martech Silo

    There’s an ongoing debate about where marketing technology (martech) should sit in an organization. Does it live with the CMO, the CIO, the CXO–a hybrid strategist with both IT and marketing background–or some collaboration? As technology use grows, it’s tempting to move martech under another role. Before we burn the martech silo, like how McDonald’s, Uber, Mastercard and others are doing, let’s look at the implications for DevOps teams.

    A recent article in PR Week cited a University of Texas study claiming “only 40% of a corporation’s marketing-related activities today report to the CMO.” Martech is being siphoned off into other areas–sometimes slowly, sometimes abruptly. It’s because the tech outweighs the marketing, at least in the eyes of the C-suite.

    In March 2019, McDonald’s announced they were acquiring Dynamic Yield for $300 million. Dynamic Yield rose to fame as one of the leaders in omnichannel personalization. Translation: they watch visitors searching, viewing and ordering. Then, they show those related results to other visitors. With the deal closed, McDonald’s announced they were eliminating their CMO position and creating an SVP of martech reporting to the CIO. Automating the customer experience with in-store kiosks and mobile app ordering is their top priority.

    Another case where mobile app ordering dominates, Uber clobbered both its CMO and COO in June 2019, right after going public. Their rockstar CEO said he wants to be more involved in day-to-day operations. Uber rolled non-martech functions into a VP of marketing communications. For Uber, martech is the product–an automated experience connecting riders and eaters with drivers. Everything else is branding and communications.

    There’s a third org chart option: the CXO, or chief experience officer. More digital customer interaction is forcing a partnership between technology and marketing insight. Mastercard hired its first CXO earlier this year, bringing in a veteran from the digital marketing industry.

    What do these three moves have in common, besides moving martech out of traditional marketing?

    • All have powerful, ubiquitous brands with huge recognition.
    • Their core product shouldn’t change much moving forward.
    • Personalization shapes their offers using global and local trends.

    Here’s the thing: Marketing automation automates what marketing knows. When the current and future requirements are clear, evaluating martech tools is easier. Moving martech out of branding, advertising and communication to IT sounds reasonable until you realize what you don’t know.

    The martech silo often houses hunters, not farmers. Marketers have different metrics. They discuss impressions, and click-thru, and time viewed, and calls-to-action, and conversions. Strategy and content often have more impact on results than the delivery technology. In a fast-moving environment with many product or service offerings, what works once may not work elsewhere. Creativity comes into play, with cycles of learning.

    In today’s SaaS model, marketing can pick a cloud-based tool and explore possibilities with minimal IT support. That’s good, until data and process accumulate, needing a bigger silo. Be careful. Burning the martech silo can be far worse for the organization than leaving it alone, even with all the shadow IT downside. No matter who does it, picking tools for a martech suite before understanding requirements is a formula for disaster. Without integrated marketing experience, IT is set up for failure. It can cascade into marketing failure and finger-pointing.

    For a fluid marketing environment, a CXO is best suited for the job. They speak the language of both sides, along with representing external customers and their experience. If your organization doesn’t have a CXO, modeling a DevOps team responsible for martech in that image is the next best option.

    DevOps solves the problem of speed marketing needs in making changes. Teams also have deep experience in maintaining applications and overseeing security IT wants. Many teams already have a product marketing person managing their software requirements. What a martech DevOps team needs is people with customer and digital marketing expertise. This include creative writers, graphics artists and advertising and social media specialists.

    If that sounds like a problem without a CXO running air cover, you’re right. Budget and headcount come from somewhere. Both the traditional marketing team and the IT team want input, perhaps even control. The key for a martech DevOps team is behaving as if the silo had disappeared, no matter what the org chart says. The DevOps leader should keep everyone informed, managing up and across. It usually means creating different presentation views, one for marketing, one for IT and maybe one for the CEO. Make sure everyone gets answers to their questions in their language.

    We’re going to have more martech moving forward. Creating effective martech DevOps teams is a priority, even without sweeping C-level reorganization. Don’t just burn the martech silo–reclaim the pieces that work for both marketing and IT and build the right team around the customer experience. If you need help getting started on a bigger martech mission, let’s talk marketing strategy.

    — Don Dingee

  • There’s No Silver Bullet for 5G Deployment

    There’s No Silver Bullet for 5G Deployment

    When it comes to 5G, a common mistake is to think there is a silver bullet for successful deployment. Often operators assume there is one magic remedy that if introduced to their network, will see them succeed. For example, automation is a key pillar of the 5G era; end-to-end automation maximizes the efficiencies and responsiveness of 5G. However, it would be a mistake to assume there is one method of automation that leads operators to successful 5G deployment. There are a vast range of automation areas and use cases such as network slicing and DevOps that can play a key role.

    But first, the key point about there being no silver bullets was part of the reason Nokia commissioned Analysys Mason, a global research organization, to assess and index operators’ maturity and readiness for 5G transformation. With 5G deployment, there are a number of available automation options that need careful consideration.

    While the Index made a number of significant findings on operators’ readiness for 5G and provided guidance for how to align technology investments, one of the most intriguing sections was on DevOps. In short, the Index found DevOps, as a key part of network automation, will enhance the impact of 5G on customer experience and service agility, but on the whole is not being adopted.

    Key Findings from the 5G Maturity Index

    The 5G Maturity Index showed it is paramount operators invest in a variety of digital technologies that can enhance the impact of 5G, including artificial intelligence learning as well as new processes such as DevOps. The following are the most vital findings of the research:

    On Automation

    • The 5G world will be characterized by the co-existence of physical and virtual infrastructure for a foreseeable future–without automation, the cost of managing functions across the two worlds will be crippling for operators.
    • Even when there is a vision for end-to-end network automation, business process automation is not clearly tied to network automation and is often in its infancy.

    On DevOps

    • Only 32% of network operators are using or are planning to use DevOps by 2020 as means to improve consumers’ experiences.
    • A significant 35% of network operators have no plans to use DevOps at any point.
    • The level of confidence in DevOps is low.
    • DevOps is becoming the norm in cloud and data center environments, but they are only slowly extending into network services.

    Why Deploy in a DevOps Mode?

    It’s clear that network operators are not yet deploying in a DevOps mode on a major scale. But what are they missing out on? DevOps has been proven, in the cloud environment, to support rapid and flexible service creation–an important goal for operators. At the heart of DevOps is continuous integration, delivery and deployment. The process enables collaboration throughout the entire development pipeline from concept and building to deployment and testing.

    Furthermore, the continuous testing and feedback loops of DevOps enable teams to consistently provide up-to-date and reliable software to customers. This enhances the consumer experience and creates new revenue streams for operators. While operators should consider adopting DevOps, it’s equally important they view it as a part of the automation process–one of the key supporting structures to the building, but not the only one. Together with other vehicles for automation, DevOps is a building block for faster time-to-value and paves the way to an agile 5G environment.

    Conclusion

    DevOps has a critical role to play in meeting 5G networks’ requirements for faster time to customer and improving the customer’s experiences. What is crucial is that operators remember:

    1. There is no silver bullet to overall automation, a menu of complementary options is needed.
    2. DevOps is a critical part of this menu, because of its ability to create efficient processes which ultimately leads to a greater user experience for businesses and their customers.

    It’s critical to align digital technologies carefully to an overall transformation strategy with clear objectives–DevOps will be a critical element of this, but do not be tempted to fall for the tale of the silver bullet.

     

     

    This article was co-authored by Stefan Kindt, technology marketing at Nokia Software. Kindt heads the operations automation and DevOps marketing. Prior to his current role, Stefan was leading the cloud market development at Nokia where he was responsible for the market positioning of Nokia cloud to enterprises and communication service providers. With more than 20 years of experience in the ICT and telecommunications industry, Stefan has extensive knowledge in the data center as well as the telco space, with global market insight and first-hand experience from Asia and Europe.

     

    — Volker Held

  • Better Together: Why Software-Development Toolmakers Should Embrace Integration

    Better Together: Why Software-Development Toolmakers Should Embrace Integration

    It’s getting harder for businesses that are building technology tools to get attention, traction and ultimately widespread adoption. You can’t just launch an amazing new developer tool and hope developers will find you; providers need to zero in on a specific use case that empowers developers while also ensuring those developers will still have access to the broad ecosystem of other tools they need to do their jobs.

    The more forward-thinking companies in enterprise SaaS, public cloud computing and artificial intelligence are increasingly partnering with companies they might once have considered competitors to elevate the presence of all their brands among end users. By meeting in the middle, and integrating with a common-ground platform, providers join their customers where they are, on the platform that makes the most sense for them.

    Instead of forcing customers to choose, providers can take advantage of powerful network effects, where their tools become more valuable because they’re part of a network. It’s one of the oldest concepts in computing: Metcalfe’s Law states the value of a network is equal to the square of the number of users on that network.

    But building that network yourself can be time-consuming and costly, as many of those who’ve done it alone have discovered. That construction project can easily distract providers from their own core competencies, forcing them to spend time and resources on essential but undifferentiated development work.

    Network Effects

    The mobile side of tech has been operating under these principles since the launch of distribution platforms such as the App Store and Google Play, which introduced mobile developers to millions of potential customers. Those customers want seamless connections between their favorite apps and services to streamline their digital lives. They don’t want every app developer to create their own marketplace with incompatible payment methods, unfamiliar interfaces or strange hoops to jump through.

    The explosion of enterprise software vendors enabled by cloud computing and software-as-a-service models has created similar patterns. Cloud-native developers have embraced distribution channels such as the AWS Marketplace as the best way to find their customers, and enterprise companies such as Box and Dropbox are making integrations with rival products and office productivity tools (like G Suite or Office 365) an important part of their product strategies.

    “What seemed unfathomable merely a decade ago is now becoming commonplace as Fortune 500 companies are mixing and matching best-in-class technologies—from upstarts to cloud mainstays like Salesforce, Workday and ServiceNow—to power their business,” said Aaron Levie, Box CEO.

    But the work required to enable those integrations is substantial.

    Growing companies focused on building best-in-class tools for developers don’t always have the in-house expertise required to strike partnership deals with platforms and support customers with a world-class billing system. Likewise, end users often need to do their own due diligence when considering whether or not a promising new development tool will play nicely with their existing tech infrastructure.

    Go to Market

    Marketplaces are the best way to solve these problems. Service providers need distribution and integration with other development tools to reach end users, and end users want the peace of mind of knowing they’ll be able to properly evaluate a tool under consideration through a certified clearinghouse.

    Companies can certainly build API-level integrations on their own for one-off partnerships or integrations where performance isn’t a major requirement. However, when performance is vital, such as with databases or infrastructure monitoring tools, a more deft touch is required.

    These seamless, low-latency connections are only going to become more important in a multi-cloud world as companies use the power and scale of Kubernetes to build tech infrastructure that spans several different cloud providers and perhaps even their own on-premises servers. True service interoperability will require common frameworks to make sense of all those connections and allow developers to mix and match their favorite tools to create the technology stacks of the future.

    Enterprise software silos are a thing of the past. The future of software development will rely on tools that blend the best available services—no matter where they were born—and link developers, service providers and platform companies in flexible and dependable ways.

    The companies that figure out how to integrate best-of-breed software development tools with the leading platforms and services of our time will win. If you’re just starting out, let someone else handle the complexities of integration and distribution while you focus on creating the best developer tool you can.

    — Jevon MacDonald

  • Take the 2020 DevOps Institute Upskilling: Enterprise DevOps Skills Survey

    Take the 2020 DevOps Institute Upskilling: Enterprise DevOps Skills Survey

    Everyone is talking about upskilling but how do you know which skills are considered a must-have, nice to have and not as important these days? What are the hiring trends within the industry including the most sought after roles and plans? With the vast array of tools, technologies, process frameworks and human/soft skills, it is daunting to try to establish a meaningful enterprise upskilling program or personal upskilling strategy.

    DevOps Institute published the first-ever “Upskilling: Enterprise DevOps Skills Report” in 2019 based on a detailed global community survey completed by over 1600 respondents. The results were very deep and insightful. The 2019 Upskilling report provided the DevOps community with a solid benchmark on the state of DevOps skills across those categories. But once is not enough in a rapidly changing skills landscape. It’s time to do it again in order to analyze and validate the data year over year.

    The 2020 Upskilling: Enterprise DevOps Skills Report survey is active through December 20, 2019 and the second annual report will be published in early 2020. The new survey builds upon the 2019 report to help IT professionals understand the skills they need to become more T-shaped, by supplementing their depth of specific knowledge with a range of general knowledge. Further, it helps IT professionals understand the specific disciplines that will best fill the top of their “T.”

    We are once again honored to have organizations such as CloudBees, Continuous Delivery Foundation, Urban Code and others sponsoring and supporting this important project. The second annual Upskilling report will publish in February 2020. You can read the full press release here.

    Let’s never forget upskilling is a purely human endeavor. We need the help and support of enterprises, individuals, vendors, consultants and influencers. Please help DevOps Institute fulfill its mission to advance the human elements of DevOps by completing the survey and sharing the link with your friends, colleagues and community.

    Your effort will also go to a much need charitable cause. We’d like to do our part to help the under-served pockets of youth around the world and to that end, we’ve identified a global charity that aligns with our vision, Teach for All. We will contribute $1 for each completed survey and we are aiming for 5,000 participants.

    Teach for All tackles complex challenges facing children in disadvantaged communities as millions of children lack the education, support and opportunity they need to thrive. Teach for All is developing collective leadership to improve education and expand opportunities for all children, so they can shape a better future for themselves and the world around them.

    Every donation, no matter how small, can make a huge difference and we are happy to contribute on your behalf to thank you for your participation with the 2020 Upskilling Survey.

    Your participation is valued, and it helps support a great cause. Take the survey and share the link with your colleagues today!

    — Jayne Groll

  • Why ITOps Is Moving to the Cloud

    Why ITOps Is Moving to the Cloud

    There’s been a lot of movement in the IT operations management (ITOM) business lately, from the acquisition of SignalFx by Splunk to the PagerDuty IPO, and all signs point to a Datadog IPO in the future. What’s with all this consolidation? I believe we’re seeing the rise of a future-state of ITOM; that is to say, it’s the rise of SaaS-based ITOM. And it’s easy to see why.

    In my previous consulting career as lead enterprise systems architect, our team had an impeccable record in designing and implementing well-architected hybrid infrastructure solutions. We maintained an immaculate record and near-flawless customer satisfaction record. By project sign-off, our job was always done. And yet, returning to the same solutions six months later told a different story entirely.

    Well-architected solutions are similar to human bodies: They are perfect when they’re born but need constant care and feeding. These same solutions that satisfied SLAs, exceeded expectations and transformed organizational efficiency can easily degenerate, and just like our bodies have their nervous systems to monitor, brains to send alerts and tissue to self-heal, well-architected systems need operational maintenance to keep them humming.

    The traditional approach for solving this eternal need was and still is to design and implement well-architected IT operation management (ITOM) solutions, around a well-architected infrastructure. And yet, this is a self-fulfilling paradox because the ITOM solution itself needs the same care and feeding.

    There’s a Problem On-Premise

    ITOM is a broad term encompassing application and operating system (OS) performance, alerts, log management, notification, asset configuration, incident management and more. It typically involves the purchase of a suite of on-premise point tools addressing each need, and then to develop an internal framework to help those tools interoperate in a meaningful way. While that is possible conceptually, the facts on the ground reflect a very different reality:

    • Multi-vendor tools are often not designed to work together.
    • Creating an internal logical framework that orchestrates various teams and technologies can be very complex in large enterprises.
    • It’s near-impossible to create technical integrations flexible enough to adhere to inevitable organizational and technological changes that will affect this logical framework.
    • Predicting cost-of-ownership is nearly impossible since each tool is controlled by a different vendor, and the internal integration effort is often unknown.
    • Predicting the cost of the manpower required is also very difficult, as each tool requires its own set of specialists, in addition to integration specialists to make it all work together.
    • Upkeep is often overwhelming, as vendors offload software patches, upgrades and on-premises hardware costs to the customer.

    In the face of all these challenges, the end result is often unrealized value, overwhelmed operational teams, loss of service and inability to accommodate new technologies resulting business service disruptions.

    Why Cloud? Why Now?

    It’s historically been near-impossible to build a traditional ITOM platform on-premise. Vendors typically sell a collection of white-labeled tools cobbled together by acquisitions, and this is far from a platform. The complexity and the rate of technological change make it difficult to provide consistent quality and value across the various product lines. This puts the ITOps team squarely in the middle of a pickle: How can they ride the wave of a changing environment without relying on static tool suites?

    The Future is Flexible

    Enterprise ITOps has been stretched now more than ever. There is a serious skills gap, shortage in IT workforce and ever-increasing technical complexity. Time and resources are precious, and Enterprise ITOps need simplicity and predictability along with flexibility and control. Enter SaaS ITOM. By moving the ITOM function to a SaaS orientation, the responsibilities, workloads and daily tasks can transform according to the needs of the organization:

    Keeping Up with the Business

    SaaS ITOM can keep up with technological change, and keep pace with cloud, DevOps, artificial intelligence and more. In the world of SaaS, change is an accepted constant and not an inconvenience. What’s more, SaaS ITOM is infinitely more consumable than the tool suites of legacy past, and that reduces the learning curves associated with running ITOps.

    Keeping Up with Industry Needs

    A SaaS ITOM platform will be able to deliver a framework that’s both flexible and governed and can accommodate technical and organizational complexities. This agility is a feature of modern SaaS. SaaS ITOM can also integrate features running on a single code base supported completely by the SaaS vendor, who will absorb maintenance and upgrade cycles, freeing considerable and valuable time back to the operator. All of this results in a more predictable total cost of ownership, improved service quality and more value to the business user.

    It’s not news the world of IT is moving to the cloud. It is news, however, that cloud can offer such transformational benefits in ways we’ve never seen before.

    — Wael Altaqi

  • The State of DevOps Report 2019 Is Out

    The State of DevOps Report 2019 Is Out

    The Accelerate State of DevOps Report 2019 is out like every other year. Now, let’s talk about the key findings of this year’s survey:

    • The Industry Continues to Improve, Particularly Among the Elite Performers: Proportion of high performers have tripled, now comprising 20% of all teams. This shows the improvement is real for those who really are doing the right things.
    • Delivering Software Quickly, Reliably and Safely Is at the Heart of Technology Transformation and Organizational Performance: It is evident that speed, stability and availability leads to organizational performance in terms of profitability, productivity and customer satisfaction.
    • The Best Strategies for Scaling DevOps in Organizations Focus on Structural Solutions that Build Community: High performers favor strategies that create community structures at both high and low levels of organization. Having established community of practices, having proof of concepts, helps them become more resilient and successful. Dojos are becoming more and more important.
    • Cloud Continues to Be a Differentiator for Elite Performers, and Drives High Performance: The use of cloud as defined by NIST Special Publication 800–145, is predictive of software delivery performance and availability. High performers are 24 times more likely to execute all five capabilities of cloud computing:
      1. On demand self-service
      2. Broad network access
      3. Resource pooling
      4. Rapid elasticity
      5. Measured service
    • Productivity Can Drive Improvements in Work/Life Balance and Reduction in Burnout, and Organization Can Make Smart Investment to Support It: To support productivity, organizations can foster a culture of psychological safety and make smart investments in tooling, information search and reducing technical debts through flexible, extensible and viewable systems.
    • There Is a Right Way to Handle the Change Approval Process, and It Leads to Improvements in Speed and Stability and Reductions in Burnouts: Heavy weight change approval processes such as CAB, negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reduction in burnouts. It is nice to see ITIL 4 has adopted this best practice, and the CAB there is no longer mandatory.

    The study was done on varied departments and industries.

    Software Delivery and Operational (SDO) Performance

    Over the last 6 years, a set of key metrics has been developed to measure SDO performance which provides a high-level system view of software delivery and performance and predict an organization’s ability to achieve goals. Last year, one operational metrics were added and found this measure helps delivering superior outcomes.

    This puts the focus and proves operational performance adds to the overall performance of the organization and helps in achieving the outcomes. Availability becomes an important component to recognize the outcome and co-create value. In ITIL 4 we also find this being brought out in the Service Value System. Importance of operations in adopting DevOps is very important.

    The SDO for Elite Performers as per the Accelerate State of DevOps Report 2019

    This year the report has shown two research models to help drive improvement in both improvement in performance and productivity.

    Use of cloud has been one important factor. How it is used leads to the benefit generated out of it.

    The Five Essential Characteristics of Cloud-Related Result:

    Only 29% of the respondents who said they use cloud infrastructure agreed or strongly agreed they met all the five essential characteristics of cloud computing as defined by NIST.

    The report talks about technical practices.

    Executing for maximum effect:

    • Concurrent efforts at team and organization levels
    • Continuous delivery using automation
    • Team-level technical capabilities
    • Organization-level technical capabilities

    Factors within are:

    Importance of architecture still remains important at organization level. Relook at the change process, it’s an important point highlighted in this year’s report. Use of cloud services is giving more improvement. DR testing is as critical as any other testing.

    Change management needs to be tuned to facilitate continuous delivery. It should not be heavyweight and on the other hand do not compromise risk. Points to be looked at in change management are:

    1. Implementing segregation of duty
    • Use Version Control
    • Use Infrastructure as Code
    1. Role of CAB becomes more strategic
    • Helping teams to implement capabilities that improve performance by providing guidance and resource
    • Weigh important business decisions that require a trade-off or sign-off at higher levels of the business
    • Shifting detailed code review to practitioners and automation and providing more time for strategic decisions to leadership
    • Transition from gatekeeper to process architect and information beacon
    1. Clear change process with proper delegation of authority

    Psychological safety helps in improvement of performance.

    This report talks about improving productivity. How do we improve productivity? The following factors can help:

    • Useful and easy-to-use tools
    • Technical professionals and tools
    • Internal and external search
    • Technical debts

    Finally, the approaches to improve–heatmap of DevOps transformation strategies by performance profile.

    Learn more about the Accelerate State of DevOps Report 2019 and attend the DevOps India Summit 2019 to hear the global experts.

    — Niladri Choudhuri