It works well for visibility into the internet and cloud environments. AppNeta works from a source probe, and it sends a low bandwidth stream of traffic to a target. If the target is not another probe, it has to use ICMP. One slight difficulty is that a lot of the cloud vendors don't allow ICMP into their cloud infrastructure. The way around that is to install a software probe in the cloud. So, AppNeta has installed software probes in nearly every Microsoft Azure location, and those probes are publicly accessible, which means we can reach them by using a different protocol. If we need to test somewhere that's not Azure, such as Amazon Web Services or Google, then we would need to install a software probe in the cloud. So, it's one more step than we've had to use in the past, but that's because of what cloud providers will allow and will not allow into their data centers. In terms of active and passive monitoring for alerting us to the deterioration of digital experiences before users are impacted, the delivery side is always active because that's the way it works. The passive side is used to monitor the operational traffic that's on the network. It works fine, but we don't use it very much because there are always security implications. So, we only use the active side of the tool. The passive side looks at the operational traffic that's already on the network, which can become tricky security-wise because when you do that, you are able to see all of the traffic unless it's encrypted. We don't tend to use that. We have used it, and it's useful to work out notifications and alerting. From the active side, we can see if the utilization is high, but we can't tell what's causing the high utilization. If we can get security authorization, we can use the passive side to find out which applications are using all the bandwidth. Typically, we're mostly focused on the active side of the testing, and the alerting and the notifications are very useful. We use the Automatic User Geo-Location feature. It happens automatically. It's not something that you can turn on or off. We do use it, but I'm always a little concerned about how accurate it might be. That has nothing to do with AppNeta. For example, if I try to find out where my home broadband is, quite often, it'll show me in London, whereas actually, I live 80 miles away from London. It's just where the IP address is logged. We do use it, but we use it cautiously. It's good for the remote workforce. We've done a lot of troubleshooting work for people working from home. Over the last couple of years, so many people have started working from home, and they've had to rely on commercial broadband rather than business broadband. Often, people have no experience in networking or troubleshooting. We're able to get them a software agent that can be installed on their machine, and then once it's on, we just remotely manage it from a central location. So, once a user has installed the probe, which is no more difficult than any other Windows or Mac application, they don't have to do anything else. We take it over from there. When AppNeta first brought the licensing out for working-from-home pros, it included 25 agents, and recently, they pulled that up to 50 agents. It's pretty useful. For the price of one standard license, you get 50 agents that you can either put in for people working from home, or you can put them in a branch office as if it was a hardware probe. We found it to be very flexible for that purpose. In terms of ease of using the Automatic User Geo-Location feature to determine if a problem is user-specific or region-specific, it depends on how many agents are around. We do know what the ISP is because it automatically tells us the ISP, as well as the geolocation. If we see people in similar locations and they're having problems with the same ISP, we can pin that down to an ISP problem. It's a question of comparing and contrasting what all the users are doing, but the end-to-end thing is, AppNeta already has a system to work out where a problem might be, whether it's at the local end with the user, or at the remote destination end, or somewhere in between. It always has that ability. There's a combination of ways to find out where a problem might be getting caused and who's causing it and why. It's very good for our Mean Time to Identify (MTTI) for performance issues across business-critical apps, locations, and users. Obviously, when you're dealing with an end-to-end path, the devices and the connections are not all owned by the same people. The local part of the network is owned by the customer or a third party. There may be one or more ISPs, and there might be an ISP at the local end and a different ISP at the remote end because we work globally. So, we may be testing between the US and the Far East, or with the UK and South Africa. There's always at least one telco, and normally, more than one telco. Although we can pinpoint the problem and find out who owns it, it doesn't mean we can fix it fast because it all depends on other third parties accepting what we say and getting on and fixing it for themselves. However, normally, if there's a problem that lasts more than, for example, 10 minutes, we pretty much know exactly where the problem is. It hasn't had much effect on our mean time to resolve (MTTR) because we're not normally in a position to resolve it. We're all pretty much external consultants. We can explain to people where the problem is, but we don't have direct relationships with telcos, where we can instruct them to go and do this. The MTTR for a problem is a bit unpredictable, but that doesn't have anything to do with AppNeta. That has to do with convincing the person or the organization that owns the problem area to get on and fix it. We have seen a reduction in open tickets using AppNeta. Before people used AppNeta, they didn't have a reliable method to find out where the problem was. Sometimes, when we work for a particular client, a problem ticket has been open for a month because the problem is periodic, and it is unpredictable when it happens. When it does happen, they don't have the right tool in place to monitor it, and then we come in and install AppNeta, and generally, we can get that ticket closed within a few days of us becoming involved. So, we often find that problem tickets have been open and unresolved for quite some time, and then we come in and put AppNeta in, and typically, we can get that ticket closed within a few days. It's just a matter of how quickly the people involve us in the problem. If we were involved right from the beginning, I'm pretty confident that it would definitely result in tickets getting closed earlier. Sometimes, tickets are getting closed within minutes because we've done our bit and we've said what the problem is and where the problem is. There's not really any point in holding the ticket open any longer because the resolution is up to some other third party like ISP or telco.
