Tag: application automation

  • CodeSee Unveils Enterprise Codebase Visualization Platform

    CodeSee Unveils Enterprise Codebase Visualization Platform

    CodeSee this week launched an enterprise platform based on its codebase visualization and mapping tools that makes it easier for developers to navigate and learn how an application was developed.

    CodeSee CEO Shanea Leven said this capability makes it simpler to understand how a codebase is constructed, including the application programming interfaces (APIs), without having to read each line of code. Organizations can use the CodeSee Enterprise platform to review code in addition to making it easier to add new developers to a project, she said.

    The CodeSee Enterprise platform makes it possible to automatically detect, visualize and link to the code used to create every connection between the services that make up an application. That capability is especially useful for any security review of an application before or after an application is deployed.

    A code automation feature codifies and automates the code knowledge that previously could only be passed from one developer to another, Leven noted.

    It takes a significant amount of time for developers to pore over a codebase to understand where they might contribute. The larger a codebase is the more challenging it becomes to make meaningful contributions.

    By definition, application development in the era of microservices is now a group effort. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to more easily collaborate when most of them may have never actually met in person.

    The amount of focus on developer productivity has increased substantially since the start of COVID-19 pandemic spurred organizations to accelerate a wide range of digital business transformation initiatives. Developers are generally challenging to recruit and retain, especially individuals familiar with the latest cloud-native platforms for building and deploying applications. Making it possible for developers to more easily contribute to multiple application development projects has never been more critical.

    Of course, most developers would rather spend more time writing code rather than studying it. The amount of time devoted to understanding codebases and maintaining development environments far exceeds the amount of time spent writing code. Many developers are not always going to be able to take advantage of advances in application development without the aid of a DevOps team to provision new tools and platforms.

    One way or another, the rate at which applications are being developed and deployed needs to accelerate. An uncertain economic outlook is increasing the pressure on business leaders to digitally transform processes in a way that increases both revenue and profitability. The application experience is especially critical because customers are not inclined to patiently wait for organizations to finetune their digital processes over an extended amount of time.

    Less clear, however, is the level of stress individual developers might be willing to tolerate. There’s no doubt most of them are sympathetic to the needs of the organizations that have hired them but that does not necessarily mean they’re willing to continuously work overtime to achieve goals that might not be attainable using the tools they have at hand.

  • DevOps and Hybrid Cloud: Life in the Fast Lane?

    DevOps and Hybrid Cloud: Life in the Fast Lane?

    Scream if you want to go faster! When it comes to a dual hybrid-cloud-and-DevOps rollout, most organizations would admit they’re eager to get going a little bit faster. But what started so enthusiastically can turn to frustration (and a different kind of screaming starts) when they’ve accelerated into this major transformation without considering all the necessary elements.

    The benefits are clear. Hybrid cloud backed up by DevOps is an efficient vehicle for change. A robust DevOps platform can be a make-or-break factor in developing a hybrid cloud strategy that goes the distance. Together, they are a force for transformation, and if organizations aren’t already implementing both DevOps and hybrid cloud, they should be asking themselves why not.

    It is true that the move to hybrid cloud is a different journey for cloud-enabled organizations than it is for cloud-native ones. The trip is harder for cloud-enabled, particularly for larger enterprises. Increased release frequency requires tighter alignment and collaboration than is traditionally seen between lines of business, development and IT operations, and this, in turn, drives the need for enhanced collaboration, automation and information transparency.

    But although the transition might be harder, it must be seen as inevitable. Organizations could wait another year, maybe a little more, but the transformation of technology and business is going to happen—so why not get started? In the first of two articles, I’m going to take a look at what needs to change so that organizations can start living life in the hybrid cloud and DevOps fast lane.

    A Cultural Phenomenon

    As has been covered in these pages in some detail already, the move to hybrid cloud backed by DevOps is doomed to fail if organizations think all they need to worry about is tooling and hiring. It’s not. Underlying both of these transformations is a sweeping cultural change. DevOps is about agility, trust and autonomy, and so is hybrid cloud.

    Most of all, though, DevOps and hybrid cloud are a commitment to enhancing an organization’s developer experience (DevX), and that’s not something that can be achieved with simply a ticketing tool or by adopting a GitOps approach. DevX means autonomous, unbound movement. It means empowerment, user experience and self-service. These are changes that can only happen with a successful change in business culture, not a tool. And this is an important starting point that many organizations are still struggling to understand.

    The People Problem

    People are another well-worn topic, but one that continues to present a major challenge. The cultural transition required to successfully implement DevOps can, theoretically, start with just one person. But for a successful outcome, it actually requires long-term change as deeply-ingrained beliefs are disbanded and tribal loyalties are broken down.

    For instance, many believe that implementing DevOps requires hiring new people. That belief embraces two fallacies: One, that organizations will be able to hire the teams they need and two, that DevOps is just a job title. As we know, a good DevOps team is not hired, it is developed through the melding of development and operations. The old silos, where devs developed and ops operated, is a relic from less-enlightened times.

    Today, it requires learning how to build automation, often open source, while managing on-premises, private and public cloud infrastructure. DevOps is a philosophy that seeks to help others, and with that comes the need for collaboration, encouragement, persuasion and other soft skills.

    Security and Privacy Are not Straightforward

    Moving to a hybrid cloud means that more care needs to be taken with regard to security and privacy. One of the main problems is that it’s no longer enough for security teams to reign from on high. With control moving from the server room to the cloud and from highly-siloed ops engineers to the whole team, security policies also need to change. Competent developers will make the right decisions, but they need the right bottom-up tooling that takes their decisions from theory to reality and safeguards those who aren’t as aware.

    These must be a catalyst to make organizations sit up and take a long look at what security in the age of cloud, containers and microservices really means. If the simultaneous move to DevOps and hybrid cloud is that catalyst, then so be it. Just as DevOps is revolutionizing the way teams approach their work, DevSecOps is going to revolutionize the way they look at security.

    Security shows its face at various stages of infrastructure: When a cloud organization is created and structured; when a vault is integrated to ensure that key passwords are secured and even when a pipeline is launched that triggers dedicated security software. This isn’t an exhaustive list, but it illustrates how organizations need to start taking a methodical, step-by-step look at security in their hybrid cloud.

    What About GitOps?

    Gartner recently found that the average company uses 28 infrastructure tools. That’s simply too many to be handled and understood by one person. Even specialist DevOps engineers can’t be experts in all the cloud providers, OpenStack and VMware. Other studies showed that a developer generally only uses 5% of their Git repositories or an average of five repositories.

    The mistake lots of companies make is thinking that suddenly shifting to using APIs with a GitOps approach is adequate to handle the change to hybrid cloud. It’s not, and can actually be detrimental to DevX. Why? There’s too big a gap—it’s like just doing a long weekly run the day before a marathon. You might start, but you’ll be severely compromising your ability to meet your goal. Even DevOps engineers struggle to maintain a single source of truth and well-maintained reusable repositories.

    The solution is to plan for the long term. It’s not realistic to believe that one or two DevOps engineers can be the saviors of a hybrid cloud approach. There are far too many tools, best practices and options—between Ansible, Terraform, Kubernetes and Concourse CI/CD to name just a few—to be managed by a handful of devs, no matter how talented they are.

    That’s why the true way to hybrid cloud mastery lies in the ability to get the whole tech team pulling in the same direction, collaborating, upskilling and leveraging their strengths to support the parts that make the whole. This might sound like a pipe dream, but there are companies out there talking the talk and walking the walk.

    Start Your Engines

    It is futile to tell an organization exactly how to get started since many are already taking the first steps and every organization’s situation is unique. There is more to cover; in the next installment, I’ll be taking a look at areas like FinOps, automation and cloud waste. Hopefully, you’ll see the fast lane is clear up ahead.

  • Best Practices for Modernizing App Modernization

    Best Practices for Modernizing App Modernization

    Modernizing legacy systems to embrace a loosely-coupled microservices architecture is the biggest predictor of success for continuous delivery, according to Google Cloud’s 2021 Accelerate State of DevOps report. Studies continue to show that the most elite DevOps performers enjoy more frequent code deployments, faster lead times to deploy, low change failure rates and faster time-to-recovery. 

    Leading enterprises like Netflix, Tesla and Starbucks proved that a microservices architecture minimizes fine-grained dependencies between services, which can then be independently tested, deployed and scaled. Combined with DevOps best practices, this reduces technical debt and allows for modernization based on a factory model approach that incorporates automated analysis and deep observability. 

    That said, application modernization to date has been a manual process requiring multi-year projects that suffer a high failure rate. How can we apply modern tools, known DevOps best practices and desired business benefits to improve and accelerate a company’s modernization efforts? In other words, how do we make modernization more modern? 

    By using automation, AI and data science, building repeatable pipelines and shifting architecture left, architects can get in front of technical debt before it becomes unmanageable. In this article, we’ll explore these practices in more detail.

    Intelligently Automate Everything Possible

    DevOps methodologies have taken manual steps and applied automation to create repeatable processes that scale. Modernization teams today are in dire need of these methodologies, as they are stuck with manual approaches that don’t scale across an entire application estate. Thus, applying intelligent automation, AI and data science to modernization—and creating a repeatable pipeline for refactoring—is a natural extension of DevOps successes over the last decade.

    Continuous Integration, Continuous Deployment, and Continuous Modernization

    CI/CD methodologies are a core best practice for DevOps teams and are already familiar patterns that development organizations are using for their application life cycles. But, there is no continuous delivery without continuous modernization. Elite teams continuously monitor technical debt accumulation and address it at every application release cycle, thereby implementing continuous modernization in their application life cycles.

    Deep Application Observability

    Observability, defined as monitoring, logging and tracing, is a foundation for cloud-native architectures. Modernizing an existing monolith requires deep observability beyond simple static code analysis to include deeper domain-driven behavior analysis and dynamically tracking dependency interactions. This is also the secret to uncovering dead code that is no longer used.

    Ensure Architectural Parity

    You must understand your infrastructure architecture to inform your application architecture and your modernization options. Lift-and-shift causes headaches for many organizations because the traditional three-tier architectures of monolithic applications have a completely different topology than cloud-native applications, which are designed from scratch to leverage the efficiencies of the cloud. 

    Whether it’s a hybrid approach (part on-premises, part cloud), public or private cloud, it’s important to ensure that your modernization strategy ensures architectural parity between the target application and its ultimate destination in the cloud. Also, it’s important to understand your modernization options: Rehost, replatform, refactor, rewrite, etc. What can you lift-and-shift and what needs more attention? 

    To find the answer, incorporating data science-driven analysis, automated service extraction and, more importantly, people, to help you understand the possibilities is critical. 

    Get Executive Support for Your Modernization Project

    This isn’t about simply churning through your backlog; your executive sponsors for a project of this scope need to understand, in business terms, why this is crucial for the organization. There are plenty of metrics showing the financial and opportunity costs of maintaining mission-critical applications that are aging and problematic. 

    To get executive buy-in for your modernization initiatives, you need to formulate a business case that communicates the cost of maintaining the legacy apps, both in time and resources to maintain, but also the negative impact on innovation, customer acquisition and retention and speed to market.

    DevOps practices emerged to improve how IT organizations reliably and efficiently deliver software from development to operations and out to customers. Applying these emerging technologies of automation, pipelines and deep observability to application modernization initiatives will enable teams to accelerate how they deliver application transformation projects. By investing in training application teams in these methods and providing modern tooling to support that training, organizations more reliably and more efficiently move both people and projects forward into the next generation of cloud applications.

  • Overcoming Challenges to Automating DevSecOps

    Overcoming Challenges to Automating DevSecOps

    In the last few years, DevSecOps has been widely adopted among organizations looking to get proactive with their security. Traditionally, development teams would continuously implement and deploy new applications into the enterprise and security was an additional bolt-on at the end. 

    However, as the threat posed by cybercrime has increased, organizations have been ‘shifting left’ with their security and weaving it into the beginning of the development life cycle. 

    This offers significantly increased security benefits and means software vulnerabilities can be identified and remediated before they are exposed to the enterprise. The one drawback is around the additional time this takes. As a result, many organizations are also looking to automate their DevSecOps processes. 

    Automation is a critical feature of DevSecOps as it improves efficiency, cuts costs and can streamline operations. However, to get the most out of DevSecOps automation so it delivers real value to the organization, there are several challenges that must be considered first. But what are these challenges and how can they be overcome?

    How to Approach DevOps Security Automation

    When you first move to security automation, you’ll find some security tasks that can easily be automated and others that are harder to fit in. DevSecOps teams will need to use many tools to cover all their bases, but no one wants teams checking lots of different tool outputs. Making it easier to see what’s going on and where risk lies by consolidating security tools and results in a central platform is the way to go. This makes life easier by giving a single pane of glass. Everyone generally agrees that DevOps teams must adopt cybersecurity best practices, but testing takes time. Development teams don’t have time to learn, use and check lots of security tools on top of their existing workload. Automated solutions get to work without any real need for maintenance or management. These solutions trigger tools to work at the right time depending on the outcomes found without any manual input needed. This gives you and your team valuable time back to focus on other important matters.

    Fitting DevSecOps Into Secure CI/CD Pipelines

    The goal of CI/CD pipelines is fast delivery of build and release steps, typically through automation. A key goal of DevSecOps is to alert someone to a new problem as early in that automated process as possible. You need to develop solutions that don’t overwhelm CI/CD pipelines, yet allow flexibility for differing tech stacks, security tools and environments. What you need to ask is, have the latest changes caused any new and important security issues that should be reported before going live?

    Doing DevSecOps Without Constant CI/CD Changes

    Trying to manually run security tools on your entire application source code each day can be time-consuming and hinder your ability to keep up with daily changes. For security checks to keep pace with code delivery in a CI/CD environment, security automation is a must. Security products need to integrate into the development pipeline and enable both the development and security team to work together instead of just throwing things over the fence to each other. 

    Focusing on Issues Raised for Faster Remediation

    All the artificial intelligence and machine learning (AI/ML) in the world isn’t going to remove non-issues better than a manual triage, so here we recommend being resigned to getting stuck. Treat the first run of a set of security tools as a normal security test. Expect hundreds of issues and be prepared to go through them and mark the false positives, duplicates and issues that just aren’t important right now. But do this with the expectation that you’re creating a baseline against which your future pipeline scans can be measured so you’re only alerted to new important issues. By automatically managing and recording the lists of real issues existing in every DevSecOps pipeline run, we can then concentrate on the differences. These new issues need to be flagged and then made easily visible and actionable for all teams.

    Running Multiple Security Tools in CI/CD

    DevSecOps includes setting up many automated security tools to cover the many types of security issues that need to be checked for. Many organizations run multiple security tools. However, as the number of security tools grows and the DevSecOps processes become more complex, many companies then realize the hardest challenge is to make sense of all of the test results within a short period of time. For some companies, this task of bringing together the results from all of these tools is a full-time job, and one ripe for automation. 

    Triaging Security Issues

    False positives and nonsense issues are consistent problems for using security tools. Removing these gives better results and increases the chances that development teams will have a better relationship with DevSecOps processes. Organizations should build a list of issues that don’t need to be actioned and also use automated security tools to flag new issues and differentiate them from the previous backlog of issues. Automating the ‘best fixes’ across all issues also speeds up fix times, while reducing the workload on security teams. 

    Mapping Security to Development Processes

    Dev and DevOps teams are under pressure to get pipelines running smoothly and don’t want security slowing things down or complicating it. By automating security testing in such a way that it can easily handle changes in repos and containers, organizations can overcome this challenge without compromising security. 

    Risk Prioritization

    DevSecOps will increase the number of issues found as well as the speed with which they should be handled. In reality, only a small number of issues will pose a massive risk to the business. Being able to pinpoint the really big issues in real-time helps security know the big risks are being covered and allows developers to focus on the real issues, not lots of small bugs. You can also intelligently determine the changes in risk for quick and automated decisions in the CI/CD pipeline without slowing down the development team.

  • Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat Brings Ansible Automation to Microsoft Azure Cloud

    Red Hat this week announced that a private preview of the Red Hat Ansible Automation Platform is now available on the Microsoft Azure Cloud.

    Tom Anderson, vice president of Red Hat Ansible automation, said making the Red Hat instance of the open source automation framework available on Azure is the first step toward making it possible for IT teams to use the IT automation framework across multiple clouds.

    The goal is to make it simpler for IT teams to bridge multiple IT environments using a common framework to automatically configure everything from operating systems to security platforms across a hybrid cloud computing environment.

    Ansible is emerging as a de facto standard for automating IT environments largely because it provides an IT team with a declarative approach to automating IT processes. An IT team can write a playbook that describes their desired state for a platform without having to know anything about its current state.

    Interest in IT automation has soared as the number of workloads being deployed in the cloud and on-premises IT environments have steadily increased. The simple truth is that many organizations can’t keep pace with the rate at which applications are built and deployed because they are unable to hire and retain enough IT staff. The challenge is that writing a playbook to automate any IT process requires a fair amount of expertise that many organizations lack. There are, however, now large numbers of existing templates that organizations can reuse.

    Anderson also noted that security concerns will also force the IT automation issue. Many of the application workloads running in cloud computing environments are misconfigured because they were provisioned by developers that have little to no security expertise. A playbook greatly reduces the chances an application workload will be misconfigured in the cloud without having to turn every developer into a security expert, Anderson explained.

    Ultimately, IT automation frameworks reduce the level of friction that often exists between developers and the rest of the IT operations team in a way that actually serves to increase developer productivity, added Anderson.

    Regardless of how IT organizations automate IT processes, it’s now a question of the rate at which that goal will be achieved rather than if. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex, IT organizations are embracing automation more aggressively. Most of those initial efforts are focused on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

    In fact, many organizations may soon discover it’s difficult to retain IT professionals without investing in automation. After all, the most talented IT professionals will not want to work for an organization that requires them to always manually configure IT resources. Many IT teams might also discover that automation frameworks like Ansible are the gateway to embracing additional DevOps best practices. The challenge, of course, is finding the time to get started automating processes when there are so many immediate issues that IT teams can’t ignore.

  • Bridging the Developer Experience (DevX) Gap

    Bridging the Developer Experience (DevX) Gap

    They say our past experiences have an impact on how we view life and our general outlook. Routine behaviours and patterns become a program that we follow day in, day out. We stop using our minds to their fullest potential and become trapped in unquestioning, continual cycles of process and emotion.

    The same could be said of our experiences in the present—our worlds shaped by the environments around us. The people, practices, tools and culture. Only by challenging these accepted patterns can we start to think about changing our mindsets.

    DevOps is a mindset; a way of forming an agile relationship between development and operations teams to speed up delivery of software to support business operations and improve customer experience. By and large, it has been successful. Companies react to change more effectively; software is developed and deployed swiftly. It has become a necessity across most organizations.

    There are challenges, as we all know, however. The State of DevOps Report 2021 found that 83% of organizations are implementing DevOps practices, but most are still failing to scale adoption. It’s a situation that hasn’t changed for four years. Why? Among other things, the report states there are too many silos, not enough skilled people, a saturated market with too many tools—and a culture that prohibits scale.

    Given that the end goal of DevOps is to generate untrammelled innovation across an organization, getting the culture right is critical. Developers need an environment where they have the confidence to innovate and contribute back to their community, help grow the business, improve their skill sets and further their careers without being limited by the people, practices and tools around them.

    Above all, it’s about creating the best possible developer experience (DevX) in which to thrive.

    The Developer Experience Gap

    Stephen O’Grady at Red Monk, the developer-focused analyst firm, originally wrote about a DevX (developer experience) gap in this post back in October 2020.

    Stephen likened the experience you get from an iPhone to the expectations of developers. The iPhone’s closed SDK created an environment that allows all developers to work in a consistent way. Functions are tightly integrated so that, for example, it would be easy to ensure the music volume lowers when you receive a call. A basic function, but one that we expect to work seamlessly with any app we install.

    Since then, developers have been served a vast array of tools and services with more and more software arriving on a daily basis. The challenge is that, where the phone and music player teams were controlled in a way that would make them work well together, modern development infrastructure doesn’t have that capability. In most cases, the toolchain is a “patchwork quilt” of products and services from different suppliers. And it is up to developers to build and maintain that quilt.

    This means that developers are being forced to take time away from writing code—the reason why they are employed in the first place—to dedicate valuable time and resources toward understanding and managing issues associated with highly complex, multi-cloud toolchains that are often being held together by nothing more than sticky tape and string.

    In other words, the very same market that is telling developers they can have anything they want to do their jobs more efficiently is simultaneously telling them that piecing the whole thing together is their problem. This is the gap for developers: It’s a gap between expectations and current reality. And a bridge across that gap needs to be built for organizations to get the most out of DevOps.

    Delivering the DevX Factor

    Attracting the best people is about showing that the experience they will have in your organization is both rewarding and liberating, so expecting developers to spend the bulk of their time not developing is clearly not an optimal experience. Creating better DevX will not only influence your ability to attract new people but enhance your ability to hold on to, empower and upskill the teams you already have.

    Where to start? Well, contrary to popular belief, you don’t need an army of DevOps engineers to reach your goals. Instead, you need to empower your existing teams to reach their full DevOps potential, supporting their progress with the right tools and training for their experience and role.

    As with any work culture (remote or hybrid), the importance of knowing where to find what you need and how to collaborate with other teams has never been so important. Tooling is a good place to start. DevX is affected by the tools they use, so organizing them in a way that helps with the culture is a step forward. In a multi-cloud, multi-vendor environment, there isn’t going to be one tool that does it all so the key is to allow teams to use the tools they love and automate as much as possible to remove the repetitive tasks.

    Automation is also a critical element in the race to reduce time-to-market and improve quality where concepts such as shift left are adding complexity and increasing the responsibilities piled on developers. Having access to testing automation in a consistent way will improve the overall experience for DevOps teams.

    And finally, think about starting your DevX journey by using a self-service platform, where information, tooling and automation can be centralized and made available to developers on demand. For overworked specialists, access to a platform that connects to any tool and creates an on demand environment that automates much of the repetitive work will create more time for them to do what they were originally employed to do: Develop.

  • Plutora Enhances VSM Platform with Release Insights

    Plutora Enhances VSM Platform with Release Insights

    Plutora has enhanced its value stream management (VSM) platform to provide dashboards that enable DevOps teams to better optimize application delivery.

    Jeff Keyes, vice president of product marketing and strategy for Plutora, said dashboards added to the platform will make it possible for application release managers to leverage predictive analytics to manage application delivery in a more progressive way rather than always having to react to an unexpected event.

    To enable that approach, Plutora has revamped its release insights dashboard that surfaces problem areas and hot spots in addition to adding analytics that track both software builds and larger project initiatives.

    That latter capability is especially critical for executives that currently find it challenging to keep track of multiple software development initiatives, especially those that may have fallen behind schedule without senior leaders being aware of the implications, said Keyes.

    While VSM platforms are typically used by senior IT and business leaders to keep track of how software deadlines are impacting key performance indicators (KPIs) for the business, Keyes said it’s become apparent that application release managers need access to more advanced analytics to optimize application deployment schedules. The Progressive Release Management capability surfaces insights via dashboards in the Plutora platform; that makes it simpler for application delivery managers to optimally orchestrate allocation of resources.

    Release managers, of course, already have access to a wide range of platforms for automating the application delivery process. However, Keyes said, those platforms don’t provide enough insights into how to optimize application delivery across a DevOps workflow made up of disparate tools and platforms. Plutora enables release managers to employ value stream flow metrics and more traditional DevOps metrics to reduce cycle times and improve overall DevOps throughput.

    Keyes said once organizations are provided with that insight, they should also be able to reduce the overall fatigue level many DevOps teams currently experience by removing friction within those workflows. In fact, that fatigue level is a major reason why there is so much turnover in many DevOps teams, he noted.

    It’s not clear how many organizations have a dedicated application release team, but optimizing the software delivery process is a major challenge for almost every DevOps team. While many organizations routinely make use of continuous integration (CI) tools to build applications faster, continuous delivery of applications has proven to be a more elusive goal. This is largely because each platform on which applications are deployed tends to be unique. As a result, many DevOps teams still rely on spreadsheets to manually manage application deployments.

    However, as the pace at which applications are being built continues to accelerate, it’s clear that application delivery is becoming a bottleneck. VSM platforms provide a means of applying analytics to optimize a process that can then be used to make better-informed decisions that might convince more organizations to automate application delivery. That assumes, of course, that the organization had the foresight to invest in a VSM platform capable of surfacing those insights in the first place.

  • Are ERP-Centric Enterprises Being Left Behind?

    Are ERP-Centric Enterprises Being Left Behind?

    Many large enterprise companies are rife with departments that depend on customized ERP software applications. These systems accommodate vital business tasks ranging from inventory management to ordering capabilities to accounting programs to CRM platforms—all of which were custom-built to fit the enterprise’s specific needs and meet the KPIs of each unique organization. These applications tend to sustain grades, patches and reworks, sometimes resulting in multiple redesigns over the course of decades, and these often are not properly documented. To make matters worse, these ERP software systems also tend to be written in outdated programming languages such as ABAP for SAP and PL/SQL for Oracle, making them a challenge to update.

    For example, 91% of respondents in a recent ASUG survey of 110 SAP companies said they use custom code, and 41% of those applications were created at least six years ago. The majority of these companies said that the existence of these custom code environments has become a hindrance to digital transformation and is holding back innovation.

    These conditions create the bloated and overly complex legacy environments that are now commonplace in the enterprise market. Widespread, customized core business systems have made digital transformation particularly daunting for enterprise companies. They require significant developer resources, excessive time commitment and ample expense to strip down and redesign these custom systems for the cloud. 

    A Lack of Developers—and of Developer Interest

    U.S. Department of Labor statistics from December 2020 indicated that there will be a shortage of 40 million skilled workers worldwide, amplifying these issues further. That figure is predicted to grow to 85.2 million by 2030. What’s more, new developers entering the marketplace gravitate to more contemporary programming languages such as JavaScript and Python, as opposed to wanting to revamp archaic code used in most ERP solutions, such as ABAP.

    For this reason, large enterprise companies in a range of verticals are lagging behind when it comes to upgrading mission-critical software applications to the cloud or to a more modern architecture. These organizations are well aware they stand to gain significant productivity benefits from digitally transforming their systems so that, for example, inventory data can be accessed via a mobile device or shared from anywhere on a cloud-based platform. Yet these large organizations are stalled in their efforts to modernize. Some companies have gone as far as to scrap their current systems and start reprogramming their software applications from scratch—a hugely expensive, lengthy and laborious endeavor that’s also full of risk. 

    Leveraging Low-Code to Simplify Enterprise IT Environments

    One method that has shown progress in unraveling these overwrought environments is to apply automation through low-code integration. Ideally, an effective low-code development solution will automatically convert existing business processes to modern, cloud-native applications, allowing the organization to maintain the business logic it has built into those applications over the years, while drastically reducing the time commitment, costs and potential disruption associated with traditional, long-form integration. In SAP environments, for example, using a low-code rapid application development solution can separate the application layer from the core SAP system, automating a large portion of the migration while preserving a “clean” SAP core.

    With many organizations under pressure to keep budgets under control in what continues to be an uncertain economy, these large-scale companies are looking for ways to modernize their operations on a more controlled schedule. When enterprises use low-code solutions—and furthermore, don’t have to search for developers of these more archaic languages—they’re free to approach digital transformation in a far more incremental and cost-effective way.

    For instance, the 12 million users of SAP’s solutions are being compelled to upgrade to the modernized version of its product, S/4HANA. Yet the American SAP User Group (ASUG) research shows that only 33% of these organizations have taken on the challenge so far despite the looming end-of-life of the current prevalent version. This is because lacking a low-code development solution, companies are being pressured to convert and rebuild all their business processes in one fell swoop. Few organizations have the resources to absorb such a drastic and risk-prone undertaking. 

    A rapid application development program acts as a bridge for companies that are looking to modernize their businesses, allowing them to upgrade their applications incrementally, according to their own schedules. Low-code can be a catalyst for technical debt-ridden enterprises, allowing them to simplify complicated legacy environments and get down to the business of innovating their systems.

  • 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. 

  • Copado Acquires Qentinel to Gain AI Testing Tools

    Copado Acquires Qentinel to Gain AI Testing Tools

    Copado has acquired Qentinel as part of an effort to incorporate AI-infused application testing within a DevOps platform and build applications using low-code tools across multiple software-as-a-service (SaaS) platforms.

    The Copado continuous integration/continuous delivery (CI/CD) platform was originally created to accelerate the development of low-code applications on top of the Salesforce platform. Now, however, Copado is expanding the scope of its DevOps reach to include other SaaS platforms.

    Andrew Leigh, chief marketing officer for Copado, said as organizations increase the number of SaaS platforms they employ in the wake of the COVID-19 pandemic, it quickly became apparent there would soon be a need to build applications that enable organizations to unify business processes spanning multiple SaaS applications.

    As part of that effort, Copado’s acquisition of Qentinel aims to advance that goal by making it simpler for both developers and end users to participate in the application testing process, Leigh said.

    Qentinel is accessed mainly via the cloud to automate the creation of application tests. Rechristened Copado Robotic Testing, the core of the Qentinel platform is based on the open source Robot Framework that understands scripts, executes them and generates logs and reports. A set of built-in libraries comes packaged with Robot Framework and addresses a wide range of testing scenarios. Qentinel customers include Brunswick, Elisa and Konecranes.

    Copado AI testing

    Gartner is forecasting that, by 2024, 75% of large enterprises will be using AI-enabled test automation tools to advance continuous testing across different stages of the DevOps life cycle. Much of the interest in AI-infused application testing tools is being driven by necessity as the pace of low-code application development exceeds the pace at which manual testing processes can work. As application testing becomes a bottleneck, organizations will naturally look toward automation platforms that employ machine learning algorithms capable of testing applications at scale.

    It’s not clear to what degree those platforms might eliminate the need for humans to test applications. The expectation is humans will be able to test application functionality at a deeper level versus, for example, merely checking to see if compliance mandates have been met. Many smaller organizations building low-code applications don’t have any meaningful application testing capabilities at all. Testing platforms infused with AI will prove to be especially crucial for citizen developers that require guidance to build a secure application that can actually scale, noted Leigh. The more SaaS application environments those applications span, the more critical testing becomes, added Leigh.

    One way or another AI is coming to application testing. After all, machine learning algorithms don’t ever need to take a day off or suddenly leave to take a better offer elsewhere. In fact, soon, most organizations soon won’t even consider a test automation platform that doesn’t have AI capabilities as they attempt to reduce the level of manual, monotonous and repetitive testing tasks. It may take a while for everyone to gain confidence in the algorithms, but it’s now more a question of the degree to which AI will be employed rather than if.