What is our primary use case?
My use case at the initial startup was very simple. I had a carrier, which was a backbone globally implemented, and I needed a monitoring solution. The type of solution I needed had to capture SNMP traps, poll my equipment, perform traffic analysis, deal with historical data, and things like that. This requirement has remained constant through the entire seven years of implementation with them.
At the end of the month, we're ending our relationship with this vendor for a variety of different reasons. Among the problems is the pricing model that they have, although a lot of it has to do with the fact that their virtualization solution isn't compatible with our Kubernetes environment.
How has it helped my organization?
SevOne has enabled us to integrate network performance management data across ITSM and our business decision-making tools, predominantly through the ServiceNow platform. We also did a Salesforce implementation where SevOne leveraged Salesforce to determine if a circuit was production versus non-production. Essentially, this distinction implies whether we should care about it, or not.
The integration with Salesforce was pretty easy, where most of the work was on the Salesforce side. It was probably one of the simpler integrations that we did for the platform.
The comprehensiveness of SevOne in terms of collecting network performance and flow data, when we started using this in 2013, was very limited. It was developed predominantly for a Cisco network and I'm a hundred percent Juniper. As such, it required a lot of work to get the platform to not only understand it but to speak in terms of Juniper MIB files, and even the nomenclature. For a Cisco network, it would have been a situation where you opened the box, plugged it in, and walked away. With Juniper, it was very much not that.
At this point, our collection capabilities are limited to just Juniper equipment. This is restricted by the tool that we have, which only covers Juniper networks.
With respect to streaming telemetry, we do not have it implemented. We were working with them to try and understand what they could do in this regard, but I do not believe that they supported streaming telemetry at the time.
What is most valuable?
The most valuable feature as of late has been the API integration with ServiceNow. Honestly, the biggest bang for the buck I've got out of SevOne has been this development. The bi-directional integration with ServiceNow has saved me a lot of money in man-hours, over the course of the last few years.
I don't have an exact figure for how much money I have saved, but I can say that it's hundreds of thousands of dollars. What it comes down to is when you're able to automate the console work with the ticketing system, you're saving people from copying and pasting, and other such menial tasks. For example, you are able to auto-populate tickets, update tickets, change the status of tickets, and also do verification to see if something is valid. You can make determinations such as whether there is a ticket currently open or whether there was a ticket previously open. Automating things like that, so a human no longer has to do them, can save hours a day per human per shift.
The out of the box reports and workflows are very sufficient for helping to understand what's normal and abnormal in the network. Out of the box, the reports were certainly there and even though it didn't necessarily understand Juniper, the minute we turned it on, we had a bunch of data. In fact, there was a lot of data that we had never previously seen before on the backbone, made available to us just by virtue of turning it on. It just needed to be cleaned up and polished.
We were aware of the reporting when we decided to implement SevOne, as we had done a lot of pre-sales work with them to make sure we knew what to expect out of the box. Even if we needed to do a lot of customization, it was certainly expected, and that's what we saw. It was important to us because we needed to immediately show some sort of value with all of the work that we'd invested over the course of the implementation. I needed to show almost a day-one value, and that certainly did help.
With respect to customization, the reports themselves didn't take too much effort. We have had a resident SevOne engineer help manage the platform and tend to those apps throughout the entire implementation of SevOne. From my standpoint, it was simply a case of asking the resident engineer for what I needed or what I expected, and whether it was a function of hours or days. Shortly after, I would have exactly what I needed.
An example of how we have customized reporting is the top talking report. It is important because we have a lot of customers that are very bandwidth-intensive. This report is for aggregate bandwidth and it is from a trap-generation standpoint.
I also have a performance metric where we monitor a specific group of circuits that are notorious for having capacity issues with customers. Essentially, it is a top talker traffic graph where I get the top ten circuits for the past 24 hours, and it's a live graph. I get it as a report, but I can also watch it in real-time.
SevOne provides continuous analytics of our network and it's important because if you're in a network where you're polling every three minutes or every five minutes, then you could be missing important events. There's a lot of stuff happening and it can be very damaging in a matter of seconds. If you're not polling or collecting data to absorb that frequency or that duration, then you're not doing anything. You're completely overlooking the important stuff. Being able to see in some form or another, not always in the graph, but being able to see that real-time activity and have it called out to a human is exceptionally important. Again, it doesn't need to be a graph, but that's one of the things we leverage SevOne for.
With respect to giving us a complete view of our network performance, it's been very good. I don't know how many times a week I have a STEM vice president come to me and ask me what's going on with the backbone or how the backbone is performing with a certain world event or corporate event. Whatever it may be, I can get a very good visual summary, very quickly, just by virtue of logging in. It's just a matter of making sure that you have the right graph. You have to tell SevOne what you need and have it presented to you in the right way. Otherwise, it doesn't know. Once you accomplish that, it's immediate.
SevOne has enabled us to detect network performance issues faster, and before they impact end-users. It is very good at capturing those events, documenting them, opening a ticket, and letting a human know about them. There is a definite ability of proactiveness with the tool.
If I consider where we were in 2013, it could take several hours or days to detect events in some cases. I have examples of catastrophic events happening that we never even knew about, that SevOne is able to capture. I estimate that we are 60% faster on average at capturing and actioning events, hopefully proactively.
What needs improvement?
Their virtualization solution is not compatible with our Kubernetes environment, which is one of the reasons we are ending our relationship with them. I didn't spend a lot of time evaluating with them why it was the case. It was simply not a roadmap item for them, so it was a pretty quick conversation.
For how long have I used the solution?
We have been using SevOne for approximately seven years.
What do I think about the scalability of the solution?
This product is very scalable, especially if it's just a matter of growing the network. You add more devices, make sure your licensing is in check, and the system ingests it as that equipment is green-lighted.
If you're changing technology, adding layers upon which you want them to monitor, it is still scalable, although it takes a little bit more work.
We have approximately two dozen users in the organization.
How are customer service and technical support?
Their technical support is very competent. We have had an immediate reaction to our issues, even without the resident engineer involved. Their technical support is 24/7. That said, I've actually had very minimal interaction with them, aside from some hand-holding during software upgrades. Other than that, the platform has been rock solid.
Which solution did I use previously and why did I switch?
Prior to using SevOne, we were using an internal homegrown solution.
After we got done building it, it largely sat idle until we started onboarding customers. As customers grew, a need for a focused operations group, tooling, processes, and procedures arose. That's where SevOne came in. We needed a legit platform to monitor the backbone rather than use existing processes and procedures that just didn't work or didn't apply.
Essentially, with the growth of the backbone and the responsibility of it, we realized that we needed an enterprise-grade solution.
How was the initial setup?
The initial setup was pretty straightforward. We knew that the biggest hurdle we had to overcome was the Juniper compatibility, so that's where we focused the resources in the planning.
The means of actually getting it installed, upgrading the software, and then actually discovering the network worked as expected. It crawled, it discovered, and it did everything we needed it to. It just needed to be tuned for a 100% Juniper network.
Of course, the Juniper tuning took many hours of post-sales engineering support as well as a resident engineer. It took a lot of work on the SevOne side to actually get it to that point.
In total, the deployment took approximately three months.
What about the implementation team?
I and a colleague were responsible for deployment.
Maintenance requires one FTE.
What was our ROI?
In terms of ROI, I don't have a whole lot in terms of metrics. However, I would say that with DI, someone has definitely started to come around from a visualization standpoint. Not only do you get an alert with an indicative color like red, orange, or yellow, but it is well represented for different stakeholders. It is not only useful for the engineer sitting at the desk but also for the tier-three that supports that engineer, all the way up to the vice president, who just wants to know how things are going.
They've come a long way in developing that. Back in the day, all people wanted was something that told them the status; red is bad, green is good, yellow means that you should look into it. That was all the information that they had. These days, people want predictive analysis and they want to be able to trend failure. They want to be able to dig into the numbers a little bit more and graphically represent that. To this end, DI is actually something that they're doing to chase that down and fill that void.
Historically, that hadn't been the case. I think DI came out approximately four years ago, and I think that's something that they're really doing to try and add value to the platform.
What's my experience with pricing, setup cost, and licensing?
The pricing has not evolved with the market, which is one of the reasons we are moving to a new product.
Which other solutions did I evaluate?
When we implemented SevOne, we had been evaluating other options for a couple of years for varying needs, although not necessarily the backbone. During that process, we had noted that SevOne would be the most accommodating and capable for our needs.
At the time, it just wasn't possible for us to implement it.
What other advice do I have?
SevOne is capable of bringing together its analytics reports and workflows in a single dashboard, although I don't actively use that specific dashboard. The stuff that I use with SevOne is very specific to a need at the moment and as such, I don't require the use of a collapsed view. In my world, it's hard to summarize everything in one place. Everything is going to be compartmentalized, so I have multiple dashboards with different data. It isn't that I don't want to use a single pane of glass but it just doesn't serve any purpose for what I need on a daily basis.
Overall, this is a good product and we had a really good relationship with the vendor. When it all started, I had a pretty basic need that I was unable to get any support internally for. We had spoken with them before, and at that initial time, I had some internal obstructions to bringing them onboard. The problems were not financially related and over time, as usual, things changed and the obstructions were gone. Once that happened, I was given the opportunity and the power to develop my own tooling suite for my team, and SevOne was a pretty easy discussion at that point in time.
The relationship continued to be a really good one up until a couple of years ago, when we were growing and of course, they wanted in on that, but their pricing was not adapting to what we were seeing in the market. They were still doing pricing from 2013 when we bought in. Naturally, anytime I expand tool usage, it works in my best interest to make sure that what I'm using is still the best implementation for not only the cost but also, the scalability at the time.
The biggest lesson that I have learned from using SevOne is that leveraging your platforms to do more work in place of a human, isn't always a bad thing. A lot of people think that you're just trying to replace humans with automation and software. What it really boils down to is that you're enabling those humans to do something else that is more important. It's not a function of eliminating jobs. It's letting the humans work on more important, complex items, and let the software and the automation do what they can to contribute to that equation.
It's not that it's necessarily been a challenge or an obstacle for me, but it is important to consider it when explaining the process. When you explain to someone that we're changing this process because SevOne can now do a certain aspect of it, with human involvement starting somewhere further down the line, you have to be able to sell that as an improvement to the process. Ultimately, it's allowing that human to focus on other things that have previously been neglected.
This problem of automating a task that is historically done by a human has been a lesson that I've learned with SevOne. The reality is that you have to let automation do what it can, and let humans do the more important engineering work. Getting away from that stigma and letting the software do its job and really focusing on releasing that, allowing the humans to do the more technical and engineering-level work, is really an act in cost-savings and from a Human Resourcing standpoint, you're getting more bang for your buck out of it. You don't want to pay people a lot of money an hour to sit there and say that red is bad and green is good. If you can get away from that, you're going to be more efficient.
I would rate this solution a seven out of ten.
Which deployment model are you using for this solution?