Author: Mike Vizard

  • Survey Sees Pace of IT Investments Continuing

    Survey Sees Pace of IT Investments Continuing

    A survey based on responses from 230 IT operations and DevOps executives in the U.S. and UK with at least 500 employees and $5 million in annual IT budgets published this week indicates large enterprises are continuing to make IT investments despite the downturn in the economy brought on by the COVID-19 pandemic.

    In the second and third quarters of 2020, 60% of IT leaders significantly or moderately increased their annual technology budgets, according to the survey results. In contrast, 22% reported their organizations significantly or moderately reduced their IT spending during the same period.

    Conducted by OpsRamp, a provider of a software-as-a-service (SaaS) platform for managing IT operations, the survey also finds nearly two-thirds of respondents (63%) have accelerated or maintained digital transformation initiatives in response to the economic downturn brought on by the COVID-19 pandemic.

    Cost optimization, however, remains a major focus. IT leaders report they are using self-service tools (60%), open source software (51%) and rationalizing IT vendors (51%) to contain costs.

    Financial managers who can help IT teams present a compelling business case for technology investments are the highest hiring priority (54%), followed by senior IT leaders who can execute digital transformation programs (47%) and cloud operators (44%).

    From a technology perspective, top priorities are information security and compliance (59%), remote work and collaboration (55%), public and multi-cloud infrastructure (50%) and monitoring and management (42%).

    More than half of respondents (57%) said they are also employing artificial intelligence for IT operations, while 50% have adopted both digital experience monitoring (50%) and network performance monitoring and diagnostics (50%) tools.

    Bhanu Singh, senior vice president of engineering and DevOps for OpsRamp, said the survey makes it clear that IT spending in large enterprises is rebounding from last spring when the pandemic first hit. Overall, IT spending for the year will still be down from its historic highs, but larger organizations are prioritizing technology projects that enable the business to adjust to fundamentally different market conditions, he said. Most of those projects involve applications being deployed on cloud computing platforms using best DevOps practices, noted Singh.

    Less clear is what the level of investments will be following the U.S. presidential election. Many business leaders are waiting to see what the stimulus spending might be approved by the new administration and Congress. That may not be known until a runoff in December for two Senate seats in Georgia, which will determine which political party controls the U.S. Senate.

    In the meantime, it does appear that larger organizations are investing in IT projects they expect will either enable them to remain competitive or pick up market share at the expense of smaller rivals that may not have as many resources to invest in IT. Historically, smaller organizations have tended to be more nimble when it comes to leveraging IT to gain a strategic advantage. However, in an era when cash flow is constrained many smaller organizations may have to be more judicious when it comes to spending on IT.

    Regardless of the outcome, the one thing that is certain is IT has never played a more crucial role in determining not only which organizations survive but ultimately thrive.

  • Linux Foundation Adds Professional DevOps Certificate Program

    Linux Foundation Adds Professional DevOps Certificate Program

    The Linux Foundation this week made an addition to its professional certificate program that trains IT professionals on the fundamentals of best DevOps practices.

    Clyde Seepersad, senior vice president and general manager for training and certification at The Linux Foundation, said the goal is to increase the number of IT professionals that have been exposed to DevOps fundamentals at a time when demand for DevOps expertise is surging. A survey published by The Linux Foundation finds 65% of organizations are currently looking for more IT personnel with open source DevOps skills.

    The Introduction to DevOps: Practices and Tools program combines three existing online training courses into a more structured program. Those existing courses are Introduction to DevOps and Site Reliability Engineering; Introduction to Jenkins and Introduction to Serverless on Kubernetes. Each course will continue to be available to audit at no cost.

    However, the $547 certificate fee provides unlimited access to the courses for one year, including all content and labs, as well as a verifiable certificate upon completion of all three courses.

    Longer-term, Seepersad said The Linux Foundation hopes to work with vendors that offer more advanced DevOps certifications. Ideally, recipients of a Linux Foundation certificate would receive some credit toward achieving other DevOps certifications or digital badges, he noted.

    Seepersad said DevOps training for IT professionals is now as much about staying relevant as it is about potentially commanding a higher salary. As IT organizations accelerate digital business transformation initiatives in response to the economic downturn brought on by the COVID-19 pandemic, there is a renewed sense of DevOps urgency, he noted.

    Regardless of experience levels, human resources professionals have always preferred job candidates who have attained professional certificates. The Linux Foundation survey found more than half of hiring managers (52%) said they are more likely to hire someone with a certification.

    IT professionals who have demonstrated DevOps experience can, of course, still land jobs, but the job interviews they get tend to be the result of personal contacts. Obviously, professional certificates don’t guarantee a job will be offered but they do tend increase the number of interviews extended. Naturally, there is, of course, no guarantee that anyone who can pass a certificate exam is going to ultimately have a successful career. Nevertheless, every DevOps journey needs to start with the fundamentals.

    In the meantime, there are plenty of IT professionals that previously worked in vertical industry segments that were hit especially hard by the COVID 19 pandemic. As many of those IT professionals look to migrate to vertical industry segments that are more vibrant, the need for a DevOps certificate becomes more apparent as competition for open positions during the worst economic slumps of modern times intensifies.

    The most important thing to remember is the certificate itself is only the first step toward achieving the hands-on DevOps experience that really matters.

  • JFrog CEO Sees Slight Slowdown in New DevOps Projects

    JFrog CEO Sees Slight Slowdown in New DevOps Projects

    Following the company’s filing of its first quarterly report as a public company, JFrog CEO Shlomi Ben Haim said this week the rate at which new application development projects being launched since the onset of the COVID-19 pandemic in the spring has declined.

    While most existing application development initiatives launched prior to the pandemic are continuing apace, Ben Haim said it might not be until next year that the velocity of new projects increases.

    JFrog revenue for the third quarter was $38.9 million, an increase of 40% from $27.8 million for the third quarter of 2019. Revenue for the first nine months of 2020 was $108.1 million, an increase of 46% from $74.0 million for the first nine months of 2019. In the current fourth quarter, JFrog is projecting revenue between $40.9 million and $41.9 million, with full-year results falling between $149 and $150 million.

    Ben Haim said most of the new activity on the JFrog platform stems from a free tier the company launched last month. Much of that individual developer activity hopefully will lead to more formal projects being launched next year, he added.

    The biggest challenge DevOps teams have encountered is keeping existing projects on track as most members began to work remotely almost overnight. While application development was often distributed across teams prior to the pandemic, many organizations are still working through how to optimize workflows now that most, if not all, their DevOps teams will be working from home well into the next year.

    The economic impact of the COVID-19 pandemic has varied widely by industry. Some industries have been adversely impacted to the point where there is not enough revenue to fund new IT projects. Other vertical industries are accelerating investments in digital business transformation initiatives that research firm IDC projects will grow at a 15.5% compound annual growth rate (CAGR) to reach $6.8 trillion by 2023. Many of those initiatives are becoming the core business continuity strategy around which entire companies are being reorganized.

    In fact, Ben Haim noted most of those digital business transformation projects are being driven by cloud-native microservices that require a DevOps platform, which is why the total addressable market for DevOps platforms still remains north of $22 billion, he said.

    It’s not clear whether DevOps teams will return to an office once a COVID-19 vaccine has been approved and distributed. In the short term, however, the number of lockdowns around the globe is again on the rise.

    In the meantime, whether DevOps teams are more productive working from home than in the office has yet to be proven. The one thing that is certain is managing DevOps teams has never been more challenging. As such, Ben Haim said the most important thing for any DevOps team to make sure they are prioritizing their efforts around the projects that will have the most immediate positive impact on the business.

  • Mattermost Offers DevOps Command Center in the Cloud

    Mattermost Offers DevOps Command Center in the Cloud

    Mattermost today launched Mattermost Cloud, a software-as-a-service (SaaS) platform for managing DevOps workflows using pre-built playbooks that comes integrated with a wide variety of third-party developer tools.

    Chandar Venkataraman, executive vice president and chief product officer for Mattermost, said Mattermost Cloud enables IT teams to take advantage of a single-tenant DevOps platform that they don’t have to maintain in a way that forces developers to give up their preferred tools.

    In contrast, other DevOps platforms that are managed as a service require developers to make use of a narrow range of tools provided by the platform vendor, he said.

    Built on top of an instance of Kubernetes, the single-tenant capability also ensures that any data or artifacts stored on the platform remain private. The Mattermost Cloud Professional edition, available today, provides a full set of collaboration and DevOps features, while the Mattermost Cloud Enterprise edition, currently in beta, adds dedicated single-tenant cloud infrastructure, enterprise-grade secure network topology and strict data residency options.

    By building the platform on Kubernetes, he noted, it becomes much easier to scale the Mattermost Cloud platform up and down as required.

    Mattermost Cloud is essentially a DevOps command center that provides single pane-of-glass pre-built workflows that address most common DevOps processes. IT teams can add their own custom workflows as their DevOps processes mature, Venkataraman said, noting plugins for Jira, Opsgenie, PagerDuty, GitLab, GitHub and Jenkins are already available.

    The cloud platform also includes a pre-built best-practices incident management playbook to enable DevOps teams to address issues as they arise rather than trying to resolve them using a legacy ticket-based approach to IT service management (ITSM), he added.

    Venkataraman noted Mattermost doesn’t expect DevOps processes to supplant existing ITSM platforms based on ITIL-frameworks. However, many DevOps teams are looking for ways to resolve incidents within their existing workflows using, for example, a messaging platform versus a workflow designed for IT support staff.

    In general, Venkataraman said, many organizations that are relatively new to DevOps don’t want to manage the underlying platform. At the same time, he noted there are also many IT organizations that want to allocate more resources to writing code versus managing a DevOps platform.

    Each IT organization will need to decide when it makes sense to stand up their own platform for managing DevOps workflows and playbooks instead of building and maintaining their own control plane. Many of those IT teams are already making use of artifact repositories and continuous integration/continuous delivery (CI/CD) platforms that are accessed via the cloud, so a DevOps command center is only one more logical extension.

    Just as importantly, isolating the DevOps command center from the rest of the underlying DevOps platforms ultimately makes it easier for IT teams to switch out tools and platforms over time as they best see fit. The challenge now may be in finding a way to decouple workflows that are deeply intertwined with a specific platform.

  • CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    An annual State of Software Delivery report published today by CircleCI suggests that after a spike in developer activity last spring at the beginning of the COVID-19 pandemic, the pace at which code is moving through a continuous integration/continuous delivery (CI/CD) platform has returned to normal levels even as developers continue to work from home.

    CircleCI CEO Jim Rose said after any initial rush last spring, it appears maintaining that level of productivity is simply unsustainable for most organizations. If heroic measures are continuously required, Rose noted it’s only a matter of time before DevOps teams start to burn out.

    Based on an analysis of 55 million data points gathered from 160,000 projects spanning more than 44,000 organizations, the CircleCI report finds that despite the ability of a handful of organizations that can deploy code multiple times per day, most organizations on average run workflows less than once (0.7 times) per day.

    However, Rose noted, there is too much focus on the number of times per day code is being deployed. The more important metric is duration. Half of the 11 million workflows measured by CircleCI finished in less than four minutes. Three-quarters finished in less than 11 minutes, with 95% of all workflows measured finishing in less than 35 minutes.

    Rose said durations are longer than in previous years, which suggests more testing is being included in workflows. In an ideal world, Rose said workflow durations should be in the range of five to 10 minutes.

    The report also finds 50% of the workflows went from failing to being successfully deployed in 55 minutes on average, with the median success rate 61% of workflows. Splitting the workflows by the ones run on default branches versus the ones run on non-default provides more insight, and the median rates are 80% for the default branch and 58% for the non-default branch. Failure rates for the non-default branch are higher because that’s the branch most developers employ to experiment in a way that doesn’t impact the primary workflow.

    Rose said the report also suggests there is a correlation between larger team size and better overall engineering performance. In times of uncertainty, IT leaders should consider increasing the size of teams to reduce burnout and maximize flexibility. Depending on the scope of the project, Rose said the CircleCI data shows that somewhere between five and 20 code contributors is the optimal number of team members. IT organizations would also be well-advised to consider how those team members are geographically distributed to maximize the number of hours in a day any project is being worked on without having to overwhelm a small number of developers working in the same time zone.

    As has always been the case, DevOps success over the long term requires organizations to balance multiple factors and metrics. After all, the primary goal for most organizations is not so much to increase the amount of code being deployed as much as it is to increase the quality of the code that ultimately gets deployed in a production environment.

  • Logz.io Embraces Jaeger for Distributed Tracing

    Logz.io Embraces Jaeger for Distributed Tracing

    Logz.io announced at its online ScaleUp! 2020 conference announced today it has added support for open source Jaeger distributed tracing software to its observability platform based on a curated instance of open source Elasticsearch, Logstash and Kibana (ELK) software.

    Logz.io CTO Jonah Kowall said support for Jaeger extends the reach of the open source platform by enabling the platform to consume data generated by Jaeger agent software, which is now being deployed more widely to instrument complex distributed computing applications.

    Jaeger, which is being developed under the auspices of the Cloud Native Computing Foundation (CNCF), is finding traction among DevOps teams who are deploying microservices-based applications based on containers, which tend to have a lot of dependencies that are challenging to monitor and troubleshoot.

    A survey of more than 1,000 DevOps and software development engineers conducted by Logz.io finds 50% of respondents have half their applications or more running in containers, with 38% using service meshes and 33% employing serverless computing frameworks. The survey also finds 87% of respondents view their main observability challenges to be Kubernetes, microservices and serverless frameworks. The most common Kubernetes difficulties cited are monitoring and troubleshooting (44%), followed by security (35%), networking (34%) and cluster management (30%).

    More than a quarter of respondents (26%) said they already make use of distributed tracing, with 68% reporting they expect distributed tracing to play an important role in their observability strategy. Nearly two-thirds said they expect to implement distributed tracing in the next two years, with 91% of respondents reporting they already employ two or more observability tools. The most commonly used tools are log management and analysis (90%) and infrastructure monitoring (78%).

    Just over half of respondents (56%) also noted that more than half their infrastructure now resides in the cloud, with 42% noting that cloud now accounts for more than 75% of their infrastructure. Amazon Web Services (AWS) is the most widely used cloud (66%), followed by Microsoft Azure (12%) and Google Cloud Platform (11%).

    Kowall said that while interest in employing ELK along with visualization tools such as Grafana is rising to reduce the overall cost of observability, IT organizations are also making it clear they don’t want to integrate an ELK stack themselves. Most IT organizations would prefer to focus their efforts on building and deploying applications rather than maintaining an observability platform.

    The rise of microservices clearly is forcing the observability hand of more organizations. Most application performance management (APM) tools use has been limited to mission-critical monolithic applications because of the cost of deploying proprietary agents and platforms. Open source platforms now present an opportunity to observe both microservice and monolithic applications at a time when the overall IT environment has become much more difficult to manage.

    There is, of course, no shortage of options when it comes to achieving the observability of IT environments. The challenge now is determining how much observability is actually required and at what level of acceptable cost.

  • ZeroNorth Adds Security Defect Density Dashboard

    ZeroNorth Adds Security Defect Density Dashboard

    ZeroNorth today announced it has added a Defect Density Dashboard to its software-as-a-service (SaaS) platform for managing and orchestrating application security scans.

    Company CEO John Worrall said Defect Density Dashboard borrows a concept employed to measure software quality and applies it specifically to application security. The dashboard surfaces the number of application security defects per thousand lines of code discovered during scans of code made using software composition analysis (SCA) and software application security testing (SAST) tools.

    That metric will create a key performance indicator that application security champions within DevOps teams and chief information security officers (CISO) can use to quantitatively measure the progress being made toward improving overall application security, he said.

    As organizations begin to adopt best DevSecOps practices Worral said one of the challenges IT leaders face is showing the board of directors that the level of investment being made is delivering measurable results. The Defect Density metric applies a concept that is already widely employed by quality assurance teams in manufacturing and other vertical industries to software development, he noted.

    As a provider of a SaaS platform for orchestrating security scans across multiple third-party tools, Worral said ZeroNorth is in the unique position of being able to normalize all the data generated by the tools.

    The Defect Density Dashboard also makes it easier to identify specific areas of weakness such as larger numbers of SQL injection vulnerabilities that would indicate a need to make additional training available to software development teams, he added, noting that approach allows the application security advocate to be viewed as an ally versus someone who merely criticizes the efforts of a software development team.

    Encouraging developers to scan their code before they make a commit is, of course, at the heart of any effort to shift more responsibility for application security to the left. ZeroNorth has been making a case for a platform that makes it easier to implement multiple scans across a DevOps workflow using different tools. That approach makes it more likely that a vulnerability that isn’t discovered by one tool is uncovered by another.

    The challenge, of course, is making sure developers scan their code often. There is a natural tendency to delay a scan in the name of productivity. However, the larger the base of code that needs to be scanned, the longer it takes to complete those scans. Most developers would be well-advised to scan smaller amounts of code more often.

    Regardless of the approach to scanning, developers should expect to be evaluated based on the number of vulnerabilities that are inadvertently introduced into their code. Cybersecurity teams can no longer keep pace with the rate at which application code is being deployed and updated. As such, many organizations have launched a concerted effort to eliminate as many vulnerabilities as possible before code gets deployed in a production environment. It may never be possible to eliminate 100% of vulnerabilities, but at the very least the most common exploits that cybercriminals actively scan for when looking to compromise an application can be greatly reduced.

  • Atlassian Launches ITSM Platform

    Atlassian Launches ITSM Platform

    Atlassian today extended its footprint in IT service management (ITSM) with the launch of Jira Service Management, a cloud-based platform designed to bridge the divide between DevOps and ticket-based approaches to managing IT.

    Edwin Wong, head of product for IT at Atlassian, said Jira Service Management builds on Opsgenie, an IT incident management platform. The goal is to provide an ITSM platform to better manage IT at a higher velocity by enabling developers to address IT support processes more easily, he said.

    Going forward, Jira Service Management will add asset and configuration management and conversational ticketing capabilities that Atlassian gained via the recent acquisitions of Mindville Insight and Halp, he added.

    Jira Service Management currently provides support for on-call scheduling, alerting, incident swarming from Opsgenie along with deeper integration with Jira Software for project management, the Bitbucket repository and Confluence collaboration software.

    IT team cans also leverage capabilities such as bulk ticket actions along with machine learning algorithms to intelligently categorize similar tickets, noted Wong.

    Jira Service Management replaces the Jira Service Desk platform that many development teams already use to manage incidents. The goal now is to provide a platform that makes it easier for developers and IT administrators to collaborate more easily to resolve issues, he said. There are currently more than 25,000 organizations that employ Jira Service Desk, which Wong said provides the base of customers from which Atlassian intends to drive convergence of DevOps and ITSM workflows.

    Most legacy ITSM platforms were designed for IT administrators. However, as IT continues to evolve developers are assuming responsibility for applications end-to-end. That transition requires a different approach to ITSM that provides deeper integration with DevOps tools that enable developers to resolve issues without requiring IT organizations to convene a “war room” meeting for each incident, said Wong.

    The launch of Jira Service Management comes at a time when more organizations are starting to transition ITSM to the cloud. With most IT staff working from home either full- or part-time to help combat the spread of the COVID-19 pandemic, organizations need ITSM platforms that are easily accessible from anywhere.

    Each IT organization will need to decide to what degree they need to converge DevOps and ITSM workflows. The goal should be to enable developers to resolve issues efficiently when required. There is still a need for ticket-based approaches to managing IT that are based on the ITIL framework. However, organizations are discovering that ITIL-based frameworks don’t enable the level of agility required to quickly resolve incidents involving custom application software.

    Regardless of the path forward, ITSM is entering a new phase as organizations start to appreciate how dependent they are on software. The days are coming to an end when end users log into an ITSM platform to create a job ticket that is addressed by an IT administrator who would contact a developer if necessary. What’s required is a more proactive approach that immediately alerts developers whenever there is an issue. The challenge is enabling that level of support in a way that creates the least amount of friction possible.

  • Survey Sees Long DevSecOps Ahead

    Survey Sees Long DevSecOps Ahead

    A survey of 250 developers working at leading technology companies paints a bleak picture of the current state of application security with 85% admitting applications on average have 10 or more vulnerabilities, with nearly half saying they have on average more than 20 per application.

    Conducted by Contrast Security, a provider of an observability platform for security, the survey also finds nearly 50% of application security tools are not integrated into the continuous integration/continuous delivery (CI/CD) pipelines.

    Contrast Security CTO Jeff Williams said it’s clear most organizations have a long way to go before best DevSecOps practices become commonplace. In the meantime, the level of disruption being caused by the need to remediate vulnerabilities remains high. The survey finds 88% of respondents need to stop development work to remediate vulnerabilities at least once a week, with nearly 80% spending too much time triaging and diagnosing application security alerts.

    Nearly three-quarters of respondents also noted their organizations cannot find highly specialized application security experts.

    On the plus side, more than one-third of respondents (36%) said at least one application security metric is among their top four performance measurements. Most (63%) have also deployed an interactive application security testing (IAST) solution.

    Most importantly, 77% of respondents said they want more application security training.

    Williams said ultimately DevSecOps will require an observability platform capable of capturing metrics that are meaningful to developers. Contrast has launched an observability platform for IT security teams that borrows DevOps principles to streamline the management of cybersecurity.

    Achieving and maintaining security is complex because application data flows in and out of disparate systems running in the cloud and on-premises IT environments. IT security teams are forced to navigate a multitude of application programming interfaces (APIs) that have varying degrees of dependencies to ascertain what’s actually occurring in their extended IT environments.

    Contrast enables DevOps teams to instrument their applications with security sensors, which Williams said enables the Contrast Application Security Platform to aggregate data flows spanning multiple applications. That approach also eliminates silos spanning application security testing (AST), software composition analysis (SCA) and runtime application self-protection (RASP) tools installed across an enterprise, said Williams.

    It’s not clear to what degree DevOps teams will add agents specifically to instrument applications to gather security data. However, as more responsibility for application security is shifted left toward developers, it’s apparent legacy approaches to securing applications are being found wanting.

    In the meantime, it’s still early days as far as DevSecOps is concerned even for technology companies, much less the average enterprise. Most IT organizations are just getting started down this path. The issue most of them are coming to terms with is the degree to which they need their DevOps and cybersecurity teams to collaborate. While there may be a need for a lot of interaction between these two teams early on, there may come a day soon when DevOps teams eventually reach a level of proficiency that makes security a natural extension of any quality assurance process.

  • LogDNA Extends Log Management Reach

    LogDNA Extends Log Management Reach

    LogDNA has extended the reach of its log management platform to add support for a Node.js platform from Vercel and a feature flagging tool from LaunchDarkly.

    In addition, LogDNA has expanded an existing alliance to IBM to add support for instance of Red Hat OpenShift running on VMware platforms hosted on the IBM Cloud, which enables IT teams to centralize log management using LogDNA and IBM Log Analysis.

    Chris Nguyen, chief strategy officer for LogDNA, said the goal is to continue to establish partnerships that will enable DevOps teams to manage larger swaths of the IT environment via a single pane of glass.

    Vercel has been gaining  traction as a provider of an open source reactive programming framework that is being employed to build more interactive front ends for web and mobile applications.

    LaunchDarkly is a feature management platform that serves more than 6 trillion feature flags a day spanning 14 million mobile devices and 3 million servers. The integration between LogDNA and LaunchDarkly enables developers to rapidly iterate on feature flags using logging data surfaced by LogDNA.

    Nguyen said that as IT environments continue to become more complex, more organizations are relying on log analytics to reduce the noise level being created by all the tools and platforms that make up a modern IT environment. The challenge IT organizations face is most of them can’t find or retain a site reliability engineer (SRE), so they need tools that enable developers to make better-informed decisions.

    LogDNA is making the case for a log management platform deployable in the cloud or on-premises, designed for DevOps teams as an alternative to existing log management platforms that were designed for IT administrators who rely on graphical tools. LogDNA instead provides developers access to log analytics that are accessed via command-line interface (CLI) or a user interface.

    It’s not clear whether or how much IT organizations may be willing to replace legacy log management platforms. However, as more organizations embrace best DevOps practices that include observability as a core tenet, LogDNA is betting those organizations will prefer an approach to log management aimed at developers rather than IT operations staff.

    As DevOps teams assume more responsibility for the management of IT on an end-to-end basis, a seismic shift in IT tooling is underway. Providers of legacy IT tools are quickly shifting toward making APIs and CLIs available in response to a range of startups that are making available tools designed from the ground up to appeal more to DevOps teams. It’s too early to say how this battle for control over observability will play out, but the number of providers of tools for DevOps teams has never been greater.

    In the meantime, many DevOps teams are still sorting out when best to employ log analytics, metrics and distributed tracing to optimize IT environments. The challenge these days isn’t so much being able to discover what’s occurring in an IT environment as much as it is making sense of it all.