Tag: AI/ML

  • The Advent of Intelligent Software Engineering 

    The Advent of Intelligent Software Engineering 

    Today, to maintain competitiveness, every company needs to behave like a software company and deliver new solutions with high velocity, quality and reliability. New features need to be introduced at a rapid pace, but with high-quality expectations. At the same time, deployment releases and operations are getting complex, debugging and traceability in production are increasingly difficult, security is more prominent, uptime and reliability needs have scaled up dramatically … the list goes on.

    In short, traditional software engineering is changing radically.  Some trends causing this disruption include:

    • Cloud is eating software. And that has not only changed the infrastructure where software is hosted but also how applications are architected, developed, packaged and deployed. Cloud is driving the adoption of cloud-native technologies; serverless components and containerization have changed how we build applications. The hard line between development and infrastructure team is getting fuzzy. 
    • Cybersecurity is now a boardroom concern. Rising cyberattacks and malware threats have left everyone vulnerable. Traditionally, software was released every few months, leaving enough time for security testing by specialists. Today, with the advent of very rapid release cycles, security checks need to start early in the development process.
    • AI/ML is the new electricity but is causing shocks. AI/ML-powered use cases are finding their way across platforms, and across industries. Traditional software engineers are not familiar with AI/ML and ML developers are not familiar with engineering disciplines and best practices, leaving a big divide in engineering maturity.
    • When one company raises the bar, others are expected to follow. Consumer expectations are constantly changing. They expect the same experience that they get from Amazon, Uber and Google from every application. It is expected that you provide a seamless, frictionless experience that your platform is available anytime, on any device and that it is fast and secure. 
    • APIs are fueling innovation: Innovation at speed and scale is not easy, but APIs can enable exactly that by tapping into the collective power of the crowd. Today, any developer can use platform-provided APIs to build a new, innovative solution. An API-first mindset is emerging, and the app store model (e.g., Apple App Store, Salesforce AppExchange, AWS Marketplace) has changed how we think of innovation and creating new platform extensions. 
    • Low-code/no-code platforms are quickly evolving, making it easy to develop small, situational applications without writing any code. Citizen developers are emerging. 
    • Modern architecture paradigms drive new ways of working. Modern platform architecture has evolved significantly in recent years from monolithic applications to SOA to microservices- and API-based distributed platforms. Event-driven architectures have gained prominence. Streaming architecture has become increasingly popular to support massive scalability. This has a significant impact on how engineering teams are organized and how they build, test, deploy and manage new platforms. 
    • Legacy platforms are slowing down growth. Legacy applications built 20+ years ago needs to be modernized for today’s context. Modernization is a massive exercise depending on the age, technology and the size of the application. But modernization is easier said than done. The legacy and the new worlds need to coexist for a while and need a bridge strategy from both a technology and cultural perspective.

    To meet these changing demands, engineering needs to become a lot more intelligent.  

    The Advent of Intelligent Engineering

    We can bring intelligence to engineering by using more data to manage projects, leverage AI/ML analytics to bring improve engineering productivity and predictability, leverage more automation and apply the right process to the right problem. 

    Data-driven Decision-Making in Engineering 

    Engineering teams use numerous tools in the development environment for code repository, bug tracking, code scanning, build, test, deploy, etc. Popular tools include Azure DevOps, GitHub, Atlassian and Jenkins, among others. These tools generate lot of granular data. All these data silos can be aggregated and used to track interesting metrics around:

    • Developer productivity: How much time is spent on writing how much code versus other activity; story points delivered versus committed
    • Software quality: Number of bugs generated; rate at which bugs are being fixed; number of bugs that slip into production 

    Additionally, on top of this data, one can build an intelligence layer using machine learning to draw hidden insights, highlight co-relations and conduct better root cause analysis. These insights can bring greater predictability to engineering outcomes. For example, whether or not developers can meet a release schedule, the level of quality, etc.

    Data provides evidence of how your teams are performing. It helps in removing potential roadblocks and enables better communication with all stakeholders. It can be used to better manage project performance and be leveraged for objective decision-making. Despite the availability of this data, engineering leaders are still operating in the dark. Decisions are made based on intuition and gut feel rather than on hard data. It’s time to become more intelligent by using data in project performance tracking and decision-making. 

    Elevate Productivity and Predictability of Engineering Services With AI

    AI/ML is disrupting every industry and is now finding its way into software engineering. AI/ML-enabled developer tools are emerging that can be leveraged across the software engineering life cycle. These tools can not only save time for repetitive activities but also improve software quality in large and complex tasks. 

    AI/ML-enabled tools can enhance a developer’s daily life from coding to testing. Today, AI-powered tools can scan and analyze code to provide intelligent code completion suggestions, flag any deviation from coding best practices (naming convention compliance, variable misuse, etc.), perform peer review, convert code from one language to another, find security vulnerabilities, etc. Dynamic application security testing (DAST) solutions use AI to discover potential attack vectors in milliseconds which would otherwise take a few days. AI/ML can help auto-generate HTML code from hand-drawn UI sketches. AI/ML also can help developers automatically generate unit tests from existing code and provide suggestions about improving tests.  

    In fact, testing is the biggest category that can benefit from AI/ML-based intelligence, specifically in large complex applications. QA teams who rely on manual testing are not able to keep pace with the rate at which code changes and releases are done today. AI/ML-enabled tools can help testing teams in a number of specific ways. 

    • Change impact analysis: AI/ML can help with coverage analysis and identify which tests need to run based on what has changed in the application.
    • Test creation: AI/ML can help test teams create test cases from plain English descriptions and can also learn how to improve tests over time; AI/M also can automatically heal broken tests. AI-powered tools can automatically convert manual UI tests to API tests.
    • Visual testing: AI-powered image comparison technology can enable visual testing to analyze the UI screen differences detected across tests. 
    • Test analysis: AI can analyze test cases and defect metrics to increase test coverage while reducing the number of tests.

    It’s time to become more intelligent by using AI-powered tools to augment engineering teams, improve their productivity and bring predictability. 

    Intelligent Automation: Beyond Development Processes

    Today, there are a lot of automation options in the software development life cycle. DevOps enables automation of build, test and deployment of new versions of your software. You can also automate other activities such as test automation, code scanning, performance test, etc. DevSecOps enables automation of security processes (e.g., code scanning for vulnerabilities) into the engineering life cycle. AI/ML-powered tools can further drive automation improvements (e.g., improve flow in your CI/CD pipelines.) Overall, automation enables higher team productivity and results in the rapid or on-demand release cycles required for business agility.  

    Automation is not just limited to development activities, it also applies to other parts of the engineering life cycle, for example:

    • Infrastructure-as-code (IaC) tools can automatically provision and configure cloud infrastructure environments (storage, network, etc.).
    • Monitoring tools can automate monitoring for availability, production load metrics and security problems and generate alerts. 
    • Log management: The number of logs generated in today’s ecosystem is vast and it is impractical to collect them manually. Log management tools can automatically aggregate and analyze information from logs.

    Leveraging automation aggressively and using it throughout the engineering life cycle can make software engineering much more intelligent. You should be automating repetitive tasks and low-value processes and use the saved time for higher-value activities.

    Making Agile Smarter

    There are several popular software engineering methodologies available such as Agile, Scaled Agile, the Spotify model and more. Regardless of the methodology or process you use, intelligent application of the right methods and tools to the right problems can make them more effective, efficient and intelligent. For example, traditional Agile processes were originally designed in the manufacturing space and were then adapted to develop mature software. But in today’s fast-changing market, development teams need to rapidly and continuously try new ideas either to demonstrate new business features or for technical validation of emerging technology. This is true not only in the early stages of new product development but also on existing platforms where you need to keep pace with changing market dynamics. Be ready to experiment.

    We need to get smarter about selecting the right process and tailoring it to your needs rather than let the process dictate your outcome.

    If Software is Eating the World, Complexity is Eating Software

    While product engineering has been around for a long time, modern software engineering is a lot more complex than just writing code and following Agile processes. Intelligent engineering practices can get solutions to market faster with better quality and reliability and gain more time for innovation to keep up with today’s speed of business.

  • VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Herbert Diess is out at VW because software is hard (yo), fiber optic cable is hard to find, and the guy who said LaMDA was sentient is dumped by Google. (more…)

  • AI: It’s What Staff Crave!

    AI: It’s What Staff Crave!

    If you’ve seen Idiocracy (Side note: I am not recommending the movie; I’m using a phrase from it we’ve all heard. The movie itself was a comedy not at all meant to be family-friendly when it was made, and changes in social mores since its 2006 release make it far less acceptable today), you are familiar with the title phrase I’ve used here. That’s what is repeated almost religiously to justify why they buy/use/drink Brawndo, an energy drink.

    One of the scenes involves people telling the star that plants need Brawndo—“It’s got electrolytes … That’s what plants crave!” This is repeated over and over until he asks, “What are electrolytes?” After some stuttering and failures to answer, someone says, “It’s what they make Brawndo out of.” Someone else inevitably tacks on, “It’s what plants crave.”

    Now, substitute “AI” for “Electrolytes”. That’s where we seem to be. Ask a vendor what algorithms they’re using, where their training data comes from, the difference in results between the test reservations and the real world. Most will end up saying a lot, not answering your questions and ending with, “It’s what staff crave!” or some such.

    A few companies will lay it all out there, assuming you can parse through the information and are familiar with the AI training algorithms they are using or the algorithms they’re using to classify inputs against the dataset. And these companies are grand because they (a) know what they’re actually doing beyond “It’s got AI/ML, it’s what staff crave,” and (b) Expect that you are knowledgeable about the data you’ve asked for or are capable of looking it up in this age of wonder that has boundless information at your fingertips.

    Don’t let your vendors get away with just repeating “It’s got electrolytes” over and over. AI and ML are a massive help in some areas, but they’re not yet a panacea and success rates vary wildly whether we’re talking problem domains, datasets, algorithms, training style, etc. Make them tell you the details. Where the data comes from and how big that dataset is. How much was reserved for testing and whether it was reserved randomly. Ask them what they hope AI will achieve, then ask them how that correlates to human interaction. Most AI today is still evaluating or replicating human interactions with something—most AI in IT particularly so. What algorithms were used to validate? And finally, make sure to ask for real-world results. I know people in data science and one has confidently said to me, “My models are 95% accurate.” When I finally dug into that claim (because my experience is that real-world use of AI/ML is almost never that accurate) it turned out that claim was true … for the reserved test data. So, the same dataset used to train got the same results on the reserved subset. That’s a good thing, but it is no indication of how said algorithm will do in the wild with unfiltered data. The big problem really is the switch from test data to real-world data.

    In fact, in IT, we are a little better off than most spaces wrestling with AI/ML, because very often there is no difference between test and training data in IT. A network security vendor will test against actual traffic—because they have access to massive volumes of it and it shortens the iterations to use what’s at hand and what the system is being trained for.

    And keep rocking it. The current iteration of IT is the opposite of the dark comedy future depicted in Idiocracy. You all are putting up systems and keeping them running at increasingly fast cadences; sometimes remotely because of COVID-19 or other work-related issues. Don’t stop turning out success for your coworkers and customers and take a moment to force vendors to explain what they’re doing with AI. If you’re a generalist like me, ask over email, though, so you can go look up the answers and make sure you understand the details.

  • EP 19: How AI/ML are Used in DevOps Today

    EP 19: How AI/ML are Used in DevOps Today

    Artificial intelligence (AI) and machine learning (ML) help improve the performance of DevOps teams by automating repetitive tasks and eliminating inefficiencies across the SDLC. By using AI, teams can test, code and check software faster and more efficiently. In this episode of DevOps Unbound, Brian Dawson, Judith Hurwitz, Alan Shimel and Mitch Ashley discuss how AI and ML are transforming DevOps and what new use cases await AI and ML in 2021 and beyond. The video is below, followed by a transcript of the conversation.

    [Intro Music]

    Alan Shimel: Hey, everyone. I’m Alan Shimel, CEO of MediaOps, devopsy.kinsta.cloud, Container Journal, Security Boulevard, and you’re watching DevOps Unbound. DevOps Unbound is sponsored by our friends at Tricentis, so many thanks to them. And DevOps Unbound is a biweekly show where we cover topics of interest to the DevOps audience.

    I am the host. My cohost is our CTO and CEO of Accelerated Strategies Group, my friend Mitchell Ashley. Mitchell, welcome.

    Mitch Ashley: Thank you. Good to be here as always, and with this illustrious panel.

    Shimel: Absolutely. And an illustrious panel it is. We have two panel members joining Mitchell and I today. Let me introduce you to both of them. They’re both great folks in their own right and I’m going to let them introduce themselves.

    Let’s start with our friend Judith Hurwitz. Judith, welcome to DevOps Unbound.

    Judith Hurwitz: Thank you so much, Alan. It’s a pleasure and an honor to be here.

    Shimel: It’s our pleasure.

    Hurwitz: So I’m Judith Hurwitz. I’m the coauthor of 10 books. Have been in the industry for 30-plus years. Focus on everything from DevOps, security, manageability in cloud, hybrid cloud, and really looking at how you take technology to transform organization. It’s a complex topic, not easy, but it’s what we’re in the middle of.

    Shimel: Absolutely. Then last but certainly not least, our friend Brian Dawson. Hey, Brian. Welcome.

    Brian Dawson: Hey, Alan. Thank you. Good to be on with you again. To tell the audience a bit about myself, as I’ve told you before, Alan, I’ve been in software development and delivery for about 30 years. I consider myself a technologist. And even prior to focusing on DevOps I’ve had a focus on optimizing software development and delivery.

    Excited to talk about AI. I kind of dabbled and dipped my toes in the space in my time that I spent at the company that is now PlayStation. Things have come a long way since. And during that time, I’ve spent the past 10 years of my career focused on identifying, applying, and spreading DevOps practices, so I’m excited to discuss the two together here with this group.

    Shimel: Absolutely. Brian, I’m not sure if you mentioned your present position with the Linux Foundation.

    Dawson: I did not actually, because also this organization I’m at today has a big footprint in the AI and ML space. So today I’m with the Linux Foundation. I oversee our developer relations and ecosystem development. And of note, within that is the LF AI & Data Foundation, which houses a number of impactful projects in this space.

    Shimel: Thank you. I just thought the folks at LF would welcome that, a little plug for them.

    Dawson: Well I appreciate it, thank you.

    Shimel: Yep. Alright. So the topic for today’s DevOps Unbound is artificial intelligence and machine learning. How can they help improve performance of DevOps teams? In other words, what’s their role in the DevOps world? Right? And let me preface our conversation by giving you sort of my view of it. DevOps for many people was all about automation.

    What can we automate? Let’s automate everything we can. Automate, automate, automate. And obviously in discussions around automation topics such as artificial intelligence and machine learning you would tend to think help with automation, and therefore anything that helps with automation is good for DevOps. And I should also say that we lump AI and ML together like they’re Siamese twins joined at the hip, and they’re not necessarily cojoined.

    You can have AI without ML and you can have ML without AI. At least I think so. I’d be interested in your thoughts. But has it lived up to the hype? Will it ever live up to the hype? Was the hype unfounded? Was it unrealistic?

    What role has AI and/or ML to this point played on DevOps and what will it play going forward? I think that’s our topic today. Any one of you, if you want to kick it off with your own feelings or respond, go right ahead.

    Dawson: Well I’d like to jump in as a troublemaker early on and say I challenge Alan that DevOps is really about automation as kind of the basis for the tie-in. If we look at it, DevOps is really a set of cultural practices and tenets that align DevOps and other software delivery stakeholders around the shared objective of delivering quality software reliably, rapidly, and repeatedly. Now the reliably, rapidly, and repeatedly component absolutely lends itself to some of the benefits that we could mine from AI, but I actually think it’s a great opportunity. If we don’t say DevOps equals automation equals AI, or rather we say DevOps equals a culture aligned around a shared objective and how can AI and ML help support those shared objectives.

    Hurwitz: I think you make a great point, Brian. I think one of the most important issues, and you mentioned culture. We have been for, what, 50 years through this development and operations perspective on how we get things done, and the promise of AI is, okay, I can push a button and it will take care of everything, and this promise has been there for, what, 20 years. The reality is it’s just not that simple. There are definitely things that we are doing today and we’re seeing evolve that is definitely helping the developers and the operational professionals.

    For example, if you have repeatable functions that happen all of the time, that, for example, if you press a button and a certain task should happen you can probably use a model and collecting massive amounts of data to do that automatically. And that’s a very good use of AI. We’ll work today – they call it MLOps or AIOps, and there’s a good reason why that’s what we’re focused on today, is because you’re looking for predictable patterns and predictable anomalies so you can avoid making stupid mistakes that, oh my god, why did I do that? I knew what the right answer was.

    But AI is not a panacea. And I think if we look back even two or three years ago, you had companies that all were saying, “Okay, we have automated, we’ve put AI into DevOps, and all you have to do is press a button and all of your problems are over.” That’s just not reality.

    Ashley: There’s the marketing AI and ML and then there’s real AI and ML. Marketing meaning everybody gloms onto the term and uses it in, let’s say, a case statement or an if statement in people’s logic and their software. Yeah, I started doing some work in AI in ’80s and ’90s programming in LISP and PROLOG and doing some corporate education in that area, some expert systems with triage, things like that. So I dabbled in a little bit there and then I was exposed to more recently about five or six years ago, worked with a gentleman named Dr. Bernard _____ who’s one of the experts in the field. And I asked him, “Help me understand why has machine learning taken off as a service.”

    He described it as a subset of AI, so that was his model anyway. What he told me really made sense and it kind of helps me understand where can we apply machine learning, and being kind of the most popular part of AI. He said machine learning takes massive amounts of data, and the fact that we have the cloud and all these applications creating data, a lot of the data exhaust, now people are going back and mining that data. So Judith, in your writing, in your books about data analysis and leading up to AI, machine learning is great for that because you can have supervised or unsupervised algorithms, supervised meaning that’s a cat, that’s a cat, that’s not a cat, or unsupervised which is just going to pour through the data and start to look for those patterns and trends and anomalies that you were talking ab out, Judith.

    So when people talk about using AI or ML, in our industry I always think about where’s there’s lots of data and can we leverage it in some impactful way? So as I look at products or technologies that claim they’re doing that, that’s at least one sort of criteria to sort of ferret out. Is it real there? Is there something real there? Or is it more spin and fluff to help us – you know, we all have case statements in our spot, right?

    Shimel: Absolutely. Actually, Brian, it looked like you were going to say something. I didn’t want to jump on you.

    Dawson: Alan, of course I have a lot to say, but nothing in particular. Since I’m off mute, I’ll say I absolutely agree with Mitch and Judith and underscore the points that they made.

    Shimel: Yep. You know what? I want to take a moment though and explore. Brian, you disagreed; DevOps isn’t about automation. And I get the whole cultural aspects of DevOps and all of that, but certainly automating as a way to be more efficient, to get more done faster, I think is part and parcel of the DevOps mindset.

    Dawson: Yeah. And if I may, without waiting to see where you wanted to go with that, I’d say it is absolutely important, but there’s a line Jez Humble would use in talking about CD. And frankly, I think the book that Dave Farley, Jez Humble and team wrote around continuous delivery is undercelebrated and under referenced. And in talking about that, one of the things he said is continuous delivery, and I’m going to say by extension some aspect of DevOps, don’t require any tools. I can do continuous delivery with a Bash script. The catch is is it’s not the most efficient in pursuit of effective collaboration, of delivery velocity so you can iterate.

    And as we’ve talked about in this past established, that controlled feedback loop, that requires things like automation to achieve those goals. Right? I just think sometimes when we talk about what we see going on with AI and ML and those terms we overload a principle or practice with expectations that aren’t core to it, and I worry a bit about that so I wanted to call it out. And sorry, Alan, I don’t know if that’s where you wanted to go with the commentary.

    Shimel: No, no, no. I want to go wherever you want to go, Brian.

    Dawson: Okay. [Laughs]

    Shimel: This is a collective. Judith, what about – I’m sorry, go ahead.

    Hurwitz: Oh, yeah. So Alan, I think one of the key issues is the whole area of continuous delivery. In previous generations, you would build an application and it would live pretty much as it was written, could be for 10 years. Today, applications are constantly having to be revised because customers change, partners change, the sources of data change. So unless you have the ability to constantly update and change and modify, you lose out. One of the values of using automation and using AI and machine learning models with lots of data is to support the ability to do this.

    You don’t have enough hands and enough brains to anticipate where problems may occur because you’ve changed things. How many times have we seen problems occur because somebody has added a new service to their environment and somebody forgot to change a configuration file? Now that’s not something that you need a massive brain to be able to do, but people get busy and they forget to do simple things.

    Ashley: I think, Judith, that’s a really good point, because I wanted to ask you about this in the software creation process. Given things are so dynamic now and constantly changing, understanding just the environment, the infrastructure-as-code all the way up through the application and how much all of that is changing, it seems like stepping in for humans in certain conditions in that environment is a great application of AI. For someone to synthesize all the factors that might go into where a problem exists or what might be causing a problem seems to be where some of those algorithms might be helpful. Do you agree with that? Has that been your experience of what people are thinking about for AI?

    Hurwitz: Yeah, definitely. I think what we’re seeing is this is where sort of the human factor comes in. You set it up so that if the printer is turned off don’t send me an alarm, fast, emergency, there’s a problem with the printer. We all have gotten used to that. But when there are problems that you’ve never seen before, that you don’t have data on and the model doesn’t take into account, then the AIOps or MLOps then gives you a message there’s something strange going on. I don’t know how to fix it.

    What do you want to do here? And so over time when that appears again, well now you had data this occurred once before. Maybe it was an anomaly twice. But then when you have enough data and enough experience over time then you build that into the model, so the next time that occurs you make a fix. On the other hand, you don’t want the system to say, “Oh, I know what that is,” make a fix, when it turns out no, no, no, you don’t understand the context of what’s going on here. And just because there’s a correlation doesn’t mean that there’s a cause for that.

    Shimel: That’s a good point.

    Ashley: It’s not always about automating a response to it, right? Everyone in the security world are very cautious or skeptical about those things happening, blocking legitimate traffic. In the financial world that’s a huge issue that we run into. So you point out a good scenario, whereas we see repetitive patterns over time and that can help machine learning algorithms now understand, okay, that’s what that pattern looks like. So you can identify what it is next time instead of it’s just an anomaly.

    Dawson: Yeah, it’s interesting, Mitch, that you say that. And going back to the starting topic about AI and ML not really achieving its promise yet, and as you called out getting data as an issue, it’s not necessarily applicable to every space. You need a level of determinism and predictable patterns that you can learn from and build on. And I have for a long time been excited that when we look at CI and CD, when we look at, Alan, the automated workflow of software development and delivery, or even if it’s not automated kind of the standard, there’s a couple of things that you do have.

    You’re doing builds, sometimes thousands a day, builds and deployment, getting that out into prop. You could be generating a ton of data. And also in its nature, you’re striving to achieve a level of consistency and repeatability in how you deliver software. And I’ll say I’m not an expert to the level some of the people on this episode are, but I get at a very top level get really excited about the opportunity for AI and ML to help better CI and CD and align with the principles of DevOps. What I see it really helping is reducing cognitive load so developers can focus on coding, innovating, and solving problems while helping ensure that quality and stability that’s difficult to maintain while you’re moving fast.

    So just thought I’d call out, and I am curious to see when vendors and others really start to do like what our friend Kohsuke has done with Launchable, and really apply AI and ML to the left-hand side or Dev side of the process to reduce the load and ensure quality and stability.

    Shimel: Guys, we’re all lumping AI and ML, AI and ML, AI and ML. Does it have to be AI and ML? In my experience, a lot of what we call AI and ML is a lot more on the ML than it is on the AI. Right? So it is fair to call it truly AI? Is it really ML? And maybe ML is for today and AI is a tomorrow thing. I don’t know.

    Hurwitz: So I think there’s definitely a problem of nomenclature here. What we’re really dealing with primarily now is models and modeling data and creating models from data. That’s the reality of today. I think that there is a lot of misuse of the term AI. There have been some absolutely wild predictions. I can’t remember the name of the computer scientist who predicted that he would be able to replicate the human brain –

    Ashley: Marvin Minsky.

    Hurwitz: – with AI. No, this was past Minsky.

    Ashley: Oh, was it after? Okay.

    Hurwitz: Yeah. This was like in the last five years.

    Ashley: Oh, okay, okay.

    Hurwitz: So over time, you’re always going to be dealing with models. You’re never going to get rid of the models. AI is sort of the next – models are a subset of what you eventually achieve with AI. But AI is really a concept that will probably take decades to evolve, and I think one of the problems we have right now is where you have vendors, and I’ve talked to hundreds of them over the years, where they say, “We have an AI application,” because it’s a hot buzz word.

    And you can look back and in the history over the last 30 to 40 years and see whatever the hot topic is all of the vendors say we do that. So I think that that’s one of the problems that businesses are facing right now. What is the difference? What does it really do? How does it make your company better? How do you use this technology to be prepared for change?

    Ashley: I think that’s a good way to break it down, Judith, too, because early days of AI were about emulating human thinking. We’re still long from – I’m not sure – all my intelligence is artificial, by the way. I acquired all of it. I don’t think I was born with any of it. But that was kind of where it started, and then AI became about expert systems largely. And then algorithmic learning, machine learning algorithms, was really where I think most of the activity is today because of that prevalence of data.

    It seems like most organizations are faced with sort of one of three strategies. What do we look for from our vendors and how they may use AI in a meaningful way or machine learning in a meaningful way that’s going to help my business? Do I build models myself from the data, like you were talking about, Judith, to apply to like a financial analysis kind of situation? More of an expert system. Or do I use machine learning algorithms in my own software to do interesting and valuable things that my software can do? And maybe you play in all three of those or a subset of those, but that seems to be the question I think most individuals or organizations are at.

    We’re not at a place where we can go build models, but we’re looking for these capabilities either in our own code or in third party products.

    Hurwitz: So I heard an interesting story from one of my clients a few years ago, maybe five years ago. He had a client that was very gung-ho about AI. So he went out and he hired five data scientists, paid them $1 million each, gave them their own space, and left them alone. These are the smartest people on the planet. Came back in six months.

    He didn’t want to bother them, they’re so smart. Alright. What have you found out? Have you written this application? And they said, “Well, we’ve been discussing this for six months and we have determined that algorithm we’re going to use.” The point is that they worked in isolation, they thought they were the smartest people on the planet, they did not talk to people on the business side about what business problems they had, they didn’t talk to the people who understand corporate data, they didn’t ask them what data do you actually have, what data do you need, they didn’t talk to people who knew the business strategy or the business processes that were in place or needed to change.

    So it really is a team sport, and I like Brian’s discussion in the beginning about culture because it really is about sort of hybrid organizations where you have leaders that know a little bit about all of these areas and then a team that’s brought together that can work across these areas.

    Shimel: Fair.

    Dawson: Judith, can I ask do you have any recommendations for DevOps teams on how to evaluate or investigate where ML is a solution? And I ask this based on observation – we’ll see if we agree – that oftentimes people are looking for a problem to apply the solution to as opposed to for ML as a solution to a problem they’ve identified. I’m just curious if you –

    Hurwitz: I violently agree with you. So I think a lot of times people get so enamored with new technology that they look at it as a way to solve all problems. And for a DevOps team I think we’re finally getting to the stage where there’s really reality in DevOps. It’s not the developers who are saying, “That’s not my problem; the operations people have to make this work.” There’s really beginning to be this collaboration between development and operations, and this shift left is definitely becoming real.

    So that’s definitely true, but for these teams to be successful they have to have a holistic view of where is your business going? What do they actually need? Why have they come to you and say we’ve go to do something? Is it just because it would be cool to do something and spend money or is there a real rationale behind this that they need? What’s the pain that’s out there that they can solve.

    So they have to start with that. They have to start not only collaborating between developers and the operations team but with the business leaders, with the people who understand all of the data, people who understand security. So all of this comes together in very much a holistic pattern.

    Shimel: Fair. Fair. Hey, guys, we’re way past halfway through here and I wanted to kind of turn our conversation to the future. We’ve had a discussion on sort of the history of AI and ML and lessons learned, et cetera, but when we look forward, Brian, you mentioned the Linux Foundation has, I don’t know if it’s a daughter foundation or a subgroup dedicated to AI and like technologies. What do we see when we look sort of near-term future? Forget, yes, one day we’ll mimic human brain patterns. Who knows if we’ll be alive by then. But near term, what do you see? What is Linux Foundation planning for?

    Dawson: Well, so looking forward, and it’s funny because you brought me in and I started to think about dream the impossible dream of what’s going to happen in the future, I will call out and will mention again I said at the start the Linux Foundation is a parent foundation of what we call a Linux Foundation open source project that hosts other projects. So LF AI & Data, you can call it a sub foundation of Linux Foundation because they host, I believe at this point, 12 graduated projects with about 20 to 30 projects in incubation. So we’re talking 30 to 50 projects under the LF AI & Data umbrella that are all working on various aspects of shared efforts, multiple large commercial organizations as well as standards bodies coming together to drive the future of AI and ML.

    What I do see coming out of LF AI & Data Foundation in the short term is standards and foundational implementations, i.e. moving sort of beyond the rudimentary discovery around AI, building packaged or gray box implementations that everybody agrees and collaborates on, which I think will help unlock the less initiated, less expert vendors to begin to deliver truly AI-based differentiating capabilities. So to put that in short, because it was a lot of words, is I think it’s about establishing a foundation for us to start to build on and accelerate our progress within the AI and data space applied to DevOps.

    Hurwitz: And so Brian, I think that you’re 100 percent right, and that’s when commercialization really happens is when we have those standards and when everybody agrees to use those foundational services. I think the challenges that we face are how to get the commercial vendors who don’t necessarily want to – they want to give lip service to these standards but they really want you to only use their version of the quote/unquote standard so that customers never leave. So it’s that stickiness factor that they are looking for. So I think it’s a hard journey.

    Dawson: Yeah. Well I think, Judith, you actually nailed the reason the Linux Foundation exists frankly, and if we look at Kubernetes as a model, it was hard pressed. Google could’ve easily said, “We’re not going to hand this over to the Linux Foundation. We’re going to dominate this space. We are going to be the modern cloud OS.” But they understood for it to gain traction, for it to grow and truly offer benefit industrywide, they had to hand it over to the Linux Foundation to grow and manage.

    They had to bring in Microsoft, they had to bring in Amazon to play in that space. And I see LF AI & Data serving that same role, what I tend to call in some language unlocking innovation, or as our tagline is, decentralized innovation. I would beg to say that that is – we didn’t call that out directly, but that’s one of the challenges that we’re seeing in the AI and data space. If there’s not short-term monetization we’re not going to do it, and if there is then we want to own it. So can we create an impartial playing field for everybody to come in and innovate together, and then build commercial solutions off of that.

    Hurwitz: Yeah, it’s a challenge. It really is. I think Kubernetes is a great example. I think data in some ways is more complicated because data is really the crunch.

    Dawson: Yeah. Well I know everybody wants to own it. Everybody wants to own the data.

    Shimel: No doubt about it.

    Ashley: There’s also discussion about AI needs to become an engineering discipline as opposed to this sort of edge specialty. It doesn’t mean that it necessarily is going to be applying everywhere, but I think how we apply AI to certain kinds of problems. It seems to me the two most ripe areas are that highly complex environment. So with more and more infrastructure that’s automated, more things have gone to digital, how do you manage the infrastructure or manage the triage problem solving? And then of course the other areas, people will find _____, continue to find _____ where AI can be applied to gain competitive advantage in a certain domain or space.

    And it seems like that’s the trajectory we’re on for quite a while. I don’t think it’s ever going to be AI takes over everything and it’s the thing that replaces DevOps or whatever. But it seems to me kind of a tool. Sorry. Go ahead, Judith.

    Hurwitz: No, what I was going to say is very interesting. If you look at healthcare, for example, if you look at the spectrum from I can automate certain DevOps functions that are repeatable, where I can identify patterns, and as I collect more data I can automate more things, you have something like healthcare, which in terms of orders of magnitude of complexity are just huge. And what I’m seeing is a lot of the vendors who think that I’m going to tackle healthcare with AI and we’re going to own the industry, a lot of them are getting out of the business because right now it’s just too hard and it will be too hard for quite a while.

    Ashley: That’s true. The medical industry in many ways [laughs] is a hard nut to crack.

    Dawson: Yeah. If I may start to dream a little and chime in based on something you said, Mitch, I do see that in the near term we are at a point where we talk about modern software development and delivery, the rapid pace with which we’re delivering change. We’re building on inventions and progress made over decades. Library reuse is very heavy. We are getting to a point where as we build more complex systems we have to figure out how can we outsource sort of maintenance and management, for want of a better word, to use it kind of grossly to solutions like ML?

    How can ML help us continue to improve, grow, and build on what we’ve done but manage the scale and complexity? And I think we’ll move from some standardization, foundational blocks, we’ll apply more ML in both the operations and development space to help manage that complexity to maintain stability, but then I also eventually see the next stage being now how do we apply ML and surface it to a developer at the time of a commit? Here’s the expected outcome of this change is, to help provide guardrails to the developer, the end state – or I wouldn’t even say the end state.

    I think we’d agree existentially there’s never an end state. We’re at a point where we don’t even have explicit CI/CD pipelines. We can commit code to a repository, the language can be inferred, we can give cues or signals to infer where we want it deployed, how we want it deployed, and I actually see ML and to an extent layers of AI just figuring out what to do with code at rest. So if you flash forward in 10 years and we’re truly applying these to technologies at scale in the cloud, I’d just change a line of code.

    That change automatically is delivered to production and AI and ML is helping us do that. So that’s sort of my dream. I don’t hit compile, I don’t hit build, I don’t build out stages and workflows. I just change code and that’s running in a system somewhere.

    Hurwitz: So don’t you also want to have the ability to say before you say – you look at what’s happening, and don’t you want to sort of at least at this stage say are you sure you want to do that? Are you sure you want to delete that pile?

    Dawson: Yes.

    Hurwitz: So until we get to the point – because you have to be able to trust that the system is smart enough to understand if I make this change what cause will that unleash? Because we’re not dealing with a perfect world in DevOps by a long shot.

    Dawson: Yeah. I do want that. I want protection. I want it to know where the vulnerabilities are and warn me, and I do think, Judith, that would be a prerequisite into this deploying code at rest or truly applying Dev AI.

    Shimel: Fair enough. Hey, guys, we are just about out of time. I think this was a great discussion. If there’s one thing I could take out of it though is that the crystal ball remains cloudy in terms of how this is all going to play out, and we’re going to have to wait for it to kind of come into focus. But it certainly will be an important part of software development, of operations going forward, and it’s an increasingly important part. But for now though we’re –

    Ashley: I think the crystal ball is a Magic 8 Ball. Ask again later.

    [Laughter]

    Shimel: Right, ask again – that’s a good one, Mitch. But for now, we’re going to call an end to this episode of DevOps Unbound. Again, thanks very much to Tricentis for their sponsorship. Thank you so much, Judith, thank you so much, Brian, for appearing here and we hope to see you on a future episode. Mitch, as always, great job riding shotgun with me.

    Ashley: Good to partner with you. Absolutely.

    Shimel: Absolutely. But this is it for this episode of DevOps Unbound. This is Alan Shimel. Have a great day, and we hope to see you soon on another DevOps Unbound as well as don’t forget every month we do a live roundtable open to you, our audience, with questions. So stay tuned for that as well. Take care, everyone. Bye-bye.

    [Outro Music]

    [End of Audio]

  • 3 Pillars of Autonomous IT Ops

    3 Pillars of Autonomous IT Ops

    Imagine a future where human IT operators and intelligent systems work together in a virtual operations room; the systems do the heavy lifting while the humans supervise. This may seem like science fiction, but the truth is we are already on the way to that future with AIOps. While actual AI-augmented teams are still quite a way off, AI/ML tools are slowly but surely becoming more ubiquitous within IT Ops, NOC, DevOps and SRE teams and leading us into this not-too-distant future.

    In the last five years, the number of internet users grew by 50%. In the last two years alone, more data was generated than in the entirety of human history up to that point. Today, 5 quintillion (that’s 18 zeros) bytes of data are produced by smart devices daily. These massive volumes of data are having a huge impact on digital operations.

    Looking at the enterprise, we see similar trends: More tools generating more data and with it, greater complexity. This is due to many factors, including the transition to the cloud, M&A activity that introduces new tools and data into an existing organization and the adoption of new technologies and methodologies such as CI/CD, microservices and more. At some point, there is so much data and everything becomes so complex that IT Ops teams reach a breaking point where they can no longer manually manage the data being generated.

    And when that point is reached, outages and service disruption become an everyday reality, as IT teams are pulled away from their strategic, business-critical projects into what is essentially firefighting. 

    Implementing more observability and monitoring tools simply exacerbates the problem, and scaling teams isn’t cost-effective in the long term. The more forward-thinking solution is automation, and even more so, autonomy. 

    The Road to IT Ops Autonomy 

    Autonomy is the ability of IT Ops to operate with minimal to no human intervention. It relies on the automation of the incident management life cycle so that humans are needed only for supervision, in the same way that a single operator can supervise a modern and highly complex robotic car assembly line.

    How can we hope to reach IT Ops autonomy?  The following three proposed pillars can act as a guide: 

    Pillar One: Automate

    Pillar Two: Predict and prevent 

    Pillar Three: Democratize

     Pillar One: Automate

    We must automate as much as possible across every step in every aspect of incident management. It won’t happen overnight, but with time and with the help of AI/ML it is doable.

    Consider the autonomous driving analogy.

    Just a few years ago, cars were manual, with little to no automation. Then we moved through partial autonomy to where we are today–conditional autonomy–where the car can drive itself in ideal conditions. This is a level of automation that we are beginning to accept; some of us cautiously, others with more enthusiasm! Meanwhile, progress continues toward higher levels of autonomy, in which vehicles will be able to drive themselves in most conditions. One day, maybe, we’ll get to the holy grail of full autonomy, where the car will drive on its own–perhaps we won’t even need a steering wheel!

     

    Similarly, in IT Ops, automation is a process and it will take time to build not only the capabilities required but also the necessary trust in AI/ML technology. Such a journey typically begins with human-driven automation, as “if-then-else” types of automation are added manually. For example, if a certain alert appears, a ticket will automatically be assigned to a specific person. As our confidence grows, the next stage could be AI-driven suggestions, whereby AI applies what it has learned from previous human actions to suggest what to automate, but the human expert decides whether to accept the suggestion or not. 

    At some point, we will progress to allowing AI to partially automate some tasks—perhaps those that are less risky, such as collecting diagnostic information and adding it to the alert, so that the incident responder automatically receives both together. We may even automate some parts of our system; perhaps within a staging environment that isn’t production-critical and, as such, is a good place to validate that the automation is working as expected. Over time, as our AI and ML capabilities develop and our trust in them grows, we may eventually reach full AI-driven automation, with no human involvement at all—the AI will simply detect the fault and resolve it. 

    Pillar Two: Predict and Prevent 

    Typically, when assigned an incident, a responder will take note of the incident’s priority. But they will also rely on their common sense and past experience in deciding how to respond. So, for example, if a P3 incident had recently escalated to a P1 in 30 minutes and a similar P3 incident now appears again, our responder will probably prioritize it, even over other incidents, to avoid a similar escalation.

    While this is one of the advantages of human logic, the flip side is that the IT environments in which we work are vast and complex—no human can possibly remember every potentially relevant detail. What’s more, if a different responder dealt with the earlier incident in our example, the current responder would not have the same insight. What is needed is an element of enrichment that can input leading indicators into the platform for the next operator to see and act upon to prevent an incident.

    This is where AI can help. 

    By identifying patterns in the data haystack—linking different incidents to the same root cause, for example—AI not only generates insights that help resolve these incidents faster but can also predict a certain outcome. This is done by anticipating a future chain of events so that appropriate preventative action can be taken before the event occurs. For now, this preventative action may be manually taken by the operator, but at some point in the future automation may enable the problem to be identified and fixed by the AI with no human intervention before it results in an outage.

    Pillar Three: Democratize

    The last pillar that will help us achieve full autonomy in IT Ops is democratization of AI. AIOps should not just be accessible to advanced, mature organizations with an army of data scientists working behind the scenes. Just as anyone can accomplish almost anything online these days with just a few clicks, any organization should be able to adopt AIOps and enjoy its benefits! 

    Democratization is about making relevant information accessible to anyone who needs it, when they need it, and in a manner that is easily applicable and actionable. AI should be accessible through simple user interfaces, with no need for coding; the benefits of machine learning should be available to people that don’t (need to) understand machine learning models. 

    This democratization can be achieved by making AIOps platforms simple and accessible to all—from the admin to the user. For example, an AIOps platform might automatically suggest how admins should prioritize incidents for operators, to make triage easier and provide instructions that even a non-expert can follow. The more such features are built into AIOps platforms, the more democratized AIOps will become.

    Data volumes will continue to grow exponentially in the coming years, and the only way to eventually conquer the tyranny of overwhelming data will be to reach autonomy in IT Ops. 

    If you’re an AIOps vendor, keep the three pillars in mind so your customers can continue to progress towards autonomy.  If you’re an IT Ops leader or tooling architect, and IT Ops autonomy is part of your vision, make sure that your AIOps vendors’ platforms and tools have been architected with these pillars and their principles in mind. 

    How far are we from achieving autonomy? Only time will tell. But one thing is for sure—we will get there, and if the COVID-19 pandemic has taught us anything it’s that we may be seeing machine-augmented teams sooner rather than later. 

  • The Future of IT: Smart Tools, Intelligent Technology

    The Future of IT: Smart Tools, Intelligent Technology

    In the last few years, the lines between information technology and development have been blurred. Developers need to know about infrastructure, and administrators need to know how to code. Advances like containerization, orchestration, continuous integration and infrastructure-as-code (IaC) happened in tandem with DevOps’ rise. The advantage of DevOps is that you can quickly build and deploy products. That comes at a cost, though, and that cost is infrastructure complexity. The answer to managing that complexity lies in technologies such as artificial intelligence (AI) and machine learning (ML).

    How can AI Help IT?

    Intelligent technology has come a long way in recent years. Machine learning and artificial intelligence are finding their way into more and more technology. New tools are beginning to emerge that can monitor and manage complex systems with relative ease. There are several clear upsides to using these systems in IT:

    • Instant notifications when there is a problem.
    • The automation of tedious IT tasks.
    • Dynamic infrastructure adjustments to help with traffic spikes and other changes.

    Training an AI to keep systems running optimally, apply updates and alert IT staff to problems in real-time is entirely possible today. By automating away a lot of tedious, manual work like digging through logs, IT is free to focus on mission-critical objectives instead of babysitting servers and monitoring dashboards.

    What Does That Mean for IT Jobs?

    Some people worry that advances in AI will lead to a world where robots take human jobs. While there will undoubtedly be some domains in which AI and ML make more sense than a person, those same technologies will also create new jobs. As IT teams are unburdened from tedious tasks, they can expand into working with ML and AI technology. IT teams are ideal for guiding business decisions about what tasks benefit the most from intelligence technology. So while IT jobs may be transformed by AI, there is no reason to believe that they will disappear. It is more helpful to think of AI as a new tool for IT instead.

    Where can IT Implement AI Tools?

    AI is best used for tasks where there is a lot of data. Having a human comb through log files, databases and dashboards is a slow process. An AI could continuously monitor everything, all the time, freeing up the IT staff to focus on the solution instead of tracking down which piece of the infrastructure is experiencing a problem.

    One area in particular that could benefit from AI/ML is fraud detection. Machine learning can analyze data to find fraudulent transactions much faster than a person ever could. And over time, it will get faster and more accurate at detection.

    Another area with potential for AI is the customer-facing helpdesk. Intelligent systems that have access to ticket resolution histories and device data may be able to handle a majority of requests without needing to use the time of an actual technician. If the AI fails to solve the problem, it can escalate the issue to a technician. As these tools mature, they’re impacting customer service processes, too; let the AI go as far as it can and then escalate less common and/or more complicated issues to a technician. This is an excellent example of how AI and IT can work together to provide the best possible outcome.

    AI and ML tools are the future for IT teams. These tools will be able to handle a lot of the tedious work that is currently done by people such as parsing logs, monitoring traffic and providing some measure of technical support. That leaves IT to focus on mission-critical issues and problems that AI and ML  cannot easily solve.

  • Using ML/AI to Support Infrastructure Monitoring

    Using ML/AI to Support Infrastructure Monitoring

    Successful infrastructure monitoring enables IT teams to ensure constant uptime and performance of their company’s systems. Technologies like machine learning (ML) and artificial intelligence (AI) benefit infrastructure monitoring by more quickly collecting and analyzing data from all of the hardware and software components that comprise the IT stack. Infrastructure changes are occurring faster than ever before, but complex systems, the unique nature of applications and lack of IT skillsets can cause challenges when integrating with these newer technologies. However, it’s more important than ever that sysadmins and DevOps teams understand how ML and AI can mitigate these roadblocks, support them in staying on top of infrastructure performance and rapidly address issues that arise.

    Intelligent Monitoring Support for Complex Systems

    The most tangible result of intelligent infrastructure monitoring tools and processes is near-immediate alerting of performance and uptime issues, which can then be addressed in an efficient and effective manner so no business interruptions occur. However, complex systems can stunt these benefits if ML and AI are not being used and manual monitoring protocols are still in place.

    Tools that use ML or AI lessen the work of IT staff immensely, freeing up critical business resources and aiding in overall productivity. Both technologies can automatically identify and update all IT stacks that comprise an enterprise’s infrastructure to keep systems up-to-date and aligned with established key performance indicators (KPIs). In addition, intelligent offerings can detect and factor those metrics against set standards so that early alerts to an “unhealthy” section of infrastructure can be identified, even as the IT stack is constantly changing. This drastically speeds up troubleshooting efforts.

    Differentiation in Applications

    The different applications supported by the various IT stacks will most often have unique service-level agreements (SLAs) for their performance and uptime, as well as remedies or penalties should those service levels not be achieved. Plus, system loads that stress the underlying infrastructure are frequently changed. For these reasons, it is important to identify what constitutes a “healthy” IT stack so that these minute parts of the infrastructure are not overlooked due to the variation involved.

    ML and AI can be programmed to track system baselines that support a “healthy” IT stack. These technologies are particularly great at finding novel and unusual patterns in data. As the monitoring and observability landscape becomes more complex over time, driven by real changes in how developers build applications and systems, the ability to spot and detect such patterns in data can be crucial in helping make sense of it, further cutting down efforts on manual searching, detective work and “death by dashboards,” which we’ve all experienced at one time or another.

    Supporting IT Team Skills with Intelligence Technology

    The role of sysadmins—and to a greater extent, developers—has shifted over the past few years to become nearly as complex as the infrastructure they oversee. Nowadays, it seems as though developers are required to have expertise in all aspects of infrastructure, from monitoring to Kubernetes to machine learning. This can take quite the toll on developers who possess such skills, but in a more realistic sense, developers that can do all these things are very hard to come by. The lack of these skillsets is pervasive in the industry, which is why ML and AI can be seen as supporting technologies—they can fill in these gaps, to an extent.

    With built-in intelligence and automation, ML/AI can enable even the most inexperienced sysadmin or DevOps professional to monitor complicated infrastructure like a pro, taking on most of the time-intensive work around collecting and analyzing the data and identifying where to troubleshoot. The main goal is to put humans in the driver’s seat, utilizing ML and AI for granular discovery of system issues, providing the metrics or charts that might be most relevant to IT staff as they troubleshoot their system and reducing the cognitive load of developers.

    With the vast benefits that intelligent technologies possess, integrating them into your IT stack can help mitigate challenges experienced with complex systems, application differentiation and the skills deficit experienced in the IT team. The important ingredient in making ML and AI effective in infrastructure monitoring is using tools that incorporate the right formulas, algorithms and automation that can best help determine success when it comes to your desired outcome.

  • Enterprise ML Investments on the Rise

    Enterprise ML Investments on the Rise

    The second wave of enterprise artificial intelligence and machine learning (AI/ML) adoption is building, and is expected to crest in 2021, as many organizations increased and accelerated their investments in tools and people.

    That was one of the unmistakable conclusions of our 2021 enterprise trends in machine learning report: 83% of the companies we surveyed said their AI/ML budgets had increased year-over-year, and we found that the average number of data scientists they employ has increased by 76% year-over-year. These changes came even as many organizations tightened their overall spending and refocused their strategic priorities amidst all of 2020’s disruption and uncertainty related to the COVID-19 pandemic. These companies aren’t simply moving forward with their AI/ML initiatives in spite of the pandemic; they’re doubling down on their investments because of it.

    Many organizations have begun to understand just how critical ML is to remaining competitive in uncertain and rapidly evolving conditions. When we ran a separate survey during the summer of 2020 to find out how businesses adapted to the pandemic’s impacts, it revealed a renewed sense of urgency around AI/ML investments: 43% of respondents said that AI/ML mattered “way more” to their business than they’d previously realized.

    Our independently conducted 2021 report included input from more than 400 leaders and practitioners across a diverse mix of technical and business functions, all of whom have a stake in their organization’s AI/ML strategy. They’re not just increasing their spending and staffing, either – they’re accelerating their pursuit of a growing number of enterprise ML use cases, with customer experience and automation leading the way.

    You need to be doing this, too. The second major wave of enterprise AI/ML adoption is underway, and you can still capitalize on the immense opportunities ahead. But the time to act is now. Organizations that take a “wait-and-see” approach are at risk of being left behind, particularly as so many other companies are scaling up their investments. Not only are your competitors increasing their AI/ML budgets (evident in the 83% YoY increase mentioned above), but they are moving their initiatives to the top of their strategic priority lists. Approximately three out of every four respondents (76%) in our 2021 report said they are prioritizing AI/ML over other IT initiatives, with 28% reporting that it is their top priority overall. These companies have realized that their success is directly tied to their ability to adapt to rapidly changing business conditions — and that AI/ML is the key to doing so.

    This is no longer the sole purview of elite technology companies. Companies of all sizes, across just about every industry, can get up and running with AI/ML, thanks in large part to the spread of easy-to-use tooling. The opportunities are more accessible than ever. You don’t need a ton of time or resources to get started — and it’s absolutely crucial that you do so soon.

    Your competitors are actively pursuing AI/ML initiatives today, regardless of your specific industry. We’re seeing many longstanding enterprises begin to drive huge transformations of their businesses and industries with AI/ML. More and more use cases are being pursued in legacy industries, from insurance to agriculture, healthcare to financial services and more. The bellwether financial firm JPMorgan Chase, for example, has even built an entire AI research program and data platform. There are virtually no industries where this is irrelevant. So, you need to act with urgency, as this second wave of enterprise adoption intensifies.

    You also need to build for operational efficiency and scale. We think of this as industrializing your machine learning operations (MLOps). While easy-to-use tools reduce the barrier to entry, they only get you partway to your destination. Invest in repeatable, automated processes or you’ll hit a wall of technical debt and other potential issues. MLOps paves the road to tightly integrated, well-aligned technology stacks, processes and teams that make it easier, not harder, to deploy more models in the future. This isn’t something you can wait on; if you’ve manually bootstrapped the deployment of even a handful of models to production, you need MLOps. Without it, you’ll quickly accrue unnecessary technical debt that will inevitably hinder your organization’s ability to scale and deliver meaningful business value.

    This is already a significant issue. Our 2021 report found that, while many organizations are increasing budgets and prioritization, it’s taking them longer to get models into production. Data scientists are still spending too much of their time on operational tasks, a problem that worsens as the number of models in production increases. This tells us that even as many organizations increase their spending and hiring, they’re actually allocating more of their growing resources toward manually scaling their AI/ML initiatives instead of investing in the operational efficiency that will maximize results.

    There’s a better way. Organizations no longer need to take a DIY approach to MLOps. There are robust solutions that can simplify many of the complex issues involved in scaling your AI/ML initiatives in production. Our report found that companies that use third-party MLOps solutions see improved outcomes compared with companies that go it alone and build and maintain everything themselves. They spend less on infrastructure, deploy models to production faster and tie up less of their data scientists’ time on model deployment.

    The pattern here is clear. Regardless of your particular industry, more and more businesses are identifying a growing list of use cases for AI/ML that can help transform their businesses and boost their competitiveness. They’re industrializing their AI/ML initiatives with MLOps to ensure their technology stacks, processes, and people are well-aligned. And, by doing so, they’re positioning themselves to rapidly adapt to and act on changing signals in their businesses.

    Don’t make the mistake of thinking AI/ML doesn’t apply to you or your industry. Doing so would mean missing out on potentially massive strategic opportunities, from new or growing revenue streams to increased efficiencies throughout your business operations. Your competitors are doing it; it’s easier than ever to get started and third-party MLOps solutions can help minimize technical debt and other operational complexity that will otherwise limit the positive business impacts of your initiatives.

    You can absolutely get in on the second wave of enterprise adoption, but the time to act is now. You can’t afford to wait.