This is the third of a three-part AIOps discussion with ScienceLogic’s Public Sector Principal Architect, Lee Koepping, and Swish’s CTO, Sean Applegate. The three parts are:
In this blog we discuss getting started with AIOps with Lee Koepping, Public Sector Principal Architect, from ScienceLogic. We’re going to guide organizations through exploring and understanding requirements or needs, where they can learn more, and how to access demos. Lee, our first question is, from your perspective, what type of AIOps platform should federal agencies that are running enterprise operations centers or an IT service management team, consider?
Start by looking for a platform. AIOps is a bit of a generic term. A lot of platforms claim to be AIOps or have AIOps. But I really think you must ask yourself, what can handle my organization’s security requirements, is the American citizen supported, implemented, et cetera. Often this is a factor in public sector.
Next would be scale. Look to somebody with a solution that can scale to wherever the organization is, and they know where they are. There’s a huge difference between tools that are very effective at a very small scale, but tend to fall down with size, scope and multi-tenancy or geography challenges. Look for a platform that has the robustness to handle scale and scale in different ways across different areas.
Lastly is the openness of that platform. Can it integrate with other tools that you’ve made a substantial investment in? Can it make those tools better? It’s not just a matter of integration for integration’s sake. Can it genuinely move the ball? Can it further my AIOps journey by bringing various disparate sources together and provide contextual AIOps value (or actions) so one plus one equals three?
Absolutely makes a ton of sense. You mentioned tools and a lot of our federal agencies are very large enterprises which have grown over time and might have a mixture of tools or tool types, and often many different teams. From an investment perspective, how can they leverage their investments in this ecosystem with tools along their AIOps journey? Furthermore, let’s touch on two things. You mentioned integration earlier. It might be good to dive into things like tool consolidation or rationalization in this discussion.
That’s a tricky one for us at ScienceLogic. We tend not to lead the conversation with ‘we’re going to replace this tool and that tool.’ There are several reasons why. We never want to assume the customer’s perception of value for those tools. They may be incredibly valued by that customer. A specific team may not let the project stakeholder make that decision. So, from a manufacturer perspective, we try and present the capabilities we have and let clients draw the conclusion. However, a foundational element of the platform is direct data acquisition. There are a lot of element managers out there that SL1 could replace, or if kept, would be redundant.
Long-term it’s usually an obvious thing. Tool consolidation is one hundred percent a by-product of our involvement in a lot of accounts. However, it’s not something we tend to dictate or lead with because everybody perceives value differently. We can certainly help and be good honest brokers in that. There are some tools that have overlap, while others are complexly complimentary. For example, when you talk log management, something like Splunk or LogRhythm, that’s their currency. That’s what they’re good at. They can find a needle in a haystack. But they can’t do a lot of automation around that. They may or may not be able to share a lot of that data contextually, but they’re a better solution to mine the data, so this becomes a “better together” story.
From an integration target perspective ITSM systems and SIEMs are great areas for AIOps integration. However, your element management tools, those things that are strictly monitoring up and down, doing performance monitoring and some configuration, are candidates that SL1 often replaces.
Makes a lot of sense. In the network monitoring space, for example, solutions are lagging from an AIOps perspective. That’s one of the areas where we feel ScienceLogic delivers significant value; the ability to pull tens of thousands of devices at massive scale, pull in SNMP metrics and make very intelligent AIOps driven decisions around the network infrastructure and all the different complexities relevant to the users, applications and business systems that rely on them. Often that’s a massive time savings for network teams. Many have more traditional static SLA driven tools monitoring their networks today. We find ScienceLogic does an exceptionally good job from a tools consolidation perspective on the network side of things.
Often that is the case. It is not because they don’t want to get there. It’s because they’re incredibly comfortable where they are. However, as an organization begins to transition from traditional networking to SD-WAN all those paradigms get challenged. It’s not just SNP anymore. They need APIs. They have lots of different types of data they now must evaluate. In many cases lots of data which must be correlated and not a lot of existing legacy tools do that. This is definitely a big area for us.
Going back to where we started the conversation about what you should look at. Look at scale, security, and future proofing. Can I get a platform today that is going to support my current needs, my needs during a transition phase and ultimately into the future? That’s one of the things ScienceLogic has been exceptionally good at over its 20-year lifespan. We know how to evolve. We have a methodology within the platform that allows for evolution. ScienceLogic SL1 can support mainframes and Kubernetes containers in the cloud – all out of the same platform using what we call Power Packs. Future Proofing is a huge differentiator for us
You mentioned supporting all those different platforms and we touched on future proofing. How can a federal agency initially scope their AIOps needs?
Figure out who’s who in the zoo and narrow down your research focus. Check vendor’s YouTube channels and their websites. I like to see a product in action, like in ScienceLogic’s SL1 Intro by Nick Hassell. I like to hear from the people behind the product. Eventually read some of the resources and ebooks that are available from vendors, like ScienceLogic’s ebooks and whitepapers. Certainly, they’re going to be biased towards each manufacturer, but a lot of them are very informative. ScienceLogic certainly has our fair share of different guides to getting started as well as product technical publications. Then somewhere in the middle between your independent research and reaching out directly to the manufacturers, I think it’s important to talk to a trusted advisor such as an integrator or value-added reseller. A trusted advisor like Swish, where there are experts on a lot of the infrastructure that an agency uses, the contracts an agency uses, and the tools an agency has implemented over the years. Take time to ask, how would this benefit me? How would this fit in and help narrow down my agency’s options?
Ultimately, ask for a demo or a Proof of Value (POV). These are software solutions, so they’re easy to demonstrate. It’s helpful to conduct a POV within a customer’s environment. That often helps solidify the value during the research phase.
One of the things we find interesting and fun with our clients is getting different stakeholders together to discuss the art of the possible. That’s a bit of an observability and automation discussion, but often the various stakeholders have the same operational practices or processes but applied in different context. Getting them to consolidate and work together on what their needs are across several departments is powerful. Let’s say it’s an end user device management team, a networking team, a cloud infrastructure team, an application team, or maybe even a business owner. You’ll find that they all need to understand utilization, saturation, queues, as well as errors. They all have SLAs to measure and manage. Those things collectively come together to represent a service level indicator to a user, an employee, or business service. When we bring those folks together and then put the art of the possible in front of them, there’s a lot of good things that happen. Next, we consolidate those requirements across an organization and look for areas to optimize their budget and investments. This helps agencies scope the requirements for their AIOps solution in a more strategic manner than as individual departments.
That’s almost table stakes for an AIOps solution. Unless you can get value recognized by multiple entities within an organization, they will compete against each other. Any one of them can buy their own element solution. They’ve already done that. Yet they’re looking for more. If you really want AIOps an agency must embark on a journey. The volume, variety, and velocity of IT data requires it. The artificial intelligence and machine-driven analytics to drive automation involve data from all the teams. That’s the only way the value is going to be recognized. It’s a very different kind of tool set and mindset. How you present the AIOps strategy and tactics within an organization is key to adoption. You can’t just talk to the network manager. You can’t just talk to the server manager. Can’t just talk to the DevOps team. Can’t just talk to the executives. You must have a dialogue with all of them to figure out how AIOps drives an end-to-end vision within an organization. It takes participation from all to get the results that most CIOs desire.
It reminds me of some of the buzzwordy stuff we hear in the space, like we need to be doing BizDevSecOps. In federal agencies, we often have different contractors and stakeholders that own business and development and eventually hand things off to operations. Often those include things like security checks, both during development processes and while in production. And that’s not just the application security. It includes network and device security checks and configuration analysis or “STIG’ing” of network devices and checking those things over time for compliance. When you think of your AIOps requirements, think holistically across the enterprise. Think broadly!
There’s massive value when you look at what is possible at the enterprise level for lots of different teams. We encourage enterprises to step back and think holistically. This is the time to also consider the services needed to properly implement and adopt an AIOps solution. AIOps isn’t something you buy and turn on and magically it works out of the box. There’s change, teamwork, and collaboration. Then configuring those things continuously over time to improve. Agencies get better at it every month of every quarter. When they look back two and three years later, they’ve come a long way and made amazing progress. To accomplish this, agencies need to have experts to guide the journey and collaboration. AIOps also requires strong government leadership along the journey. It doesn’t just happen overnight.
It’s certainly an evolution. ScienceLogic created this platform based on evolving. That’s how we got to where we are. As a customer I bought the platform twice long before I was an employee. Adapting to my needs was a key aspect of it. It was being able to have something that can evolve with my operations, because my operations were continually evolving. The hard work is getting consensus. It’s getting teams to work together. It’s coming up with the 1 + 1 = 3 scenarios. That is the challenge. It shouldn’t be hard to implement that into a system. ScienceLogic SL1 is a platform that does that.
Clients spend a lot less time on the care and feeding of the platform itself, and instead more time on considering how they achieve operational objectives, get consensus, eliminate war rooms, and drive automation within SL1. It’s relatively straightforward since it’s mostly GUI driven and well documented. Training is readily accessible, and certifications can be accomplished in days. It’s not a complex tool, but it allows you to do very complex operations and that’s where agencies should focus their time.
Sean:
Let’s say I’m a federal agency and I’ve figured out my requirements and roughly know what I want to do, but I want to go kick the tires on something like ScienceLogic to further my AIOps market research. How does an agency get started with that?
Lee:
I think the best way is to reach out to a partner because they often will play a role in determining best fit and supporting the Proof of Value. It’s heavy on a sales cycle, to be honest. It is resource intensive to get the software in a customer’s environment and let them kick the tires. AIOps isn’t the kind of solution that you just go download a trial copy and see a lot of functionality. Customers need to be led through it and use case driven scenarios to determine value. We work very closely with our partners to support client demos. We take a lot of pride in being able to do that because agencies can do all the research in the world, but until they see their own data in their own environment, in a dashboard, or experience an automation in their own environment they don’t appreciate it.
Agencies really want to test drive solutions You don’t go to a car dealership, kick the tires, and buy the car. You test drive it. You get in and take it for a spin. Sometimes you need to have features explained
to you by the dealership, in this case, it might be the partner. Where are we going to take this on the drive? A bumpy road, a smooth road, a fast road, a slow road. Getting a feel for an evaluation or test plan up front results in a much better experience during the process.
Sean:
Yes. Plan your drive. In our case, we try to define a success criterion up front and understand the drive we’re going to take the car on. Then when you take the car out on that drive it’s useful to have an expert driver with you. One that’s driven it before and knows how to turn the advanced features on or how to enable sports mode versus cruising mode or the economical gas mode. Swish is happy to help customers do those things and make sure they get expert support through the proof of value process, as well as make sure we help them understand how to lock it down for federal security requirements.
Often during the eval process our clients need to learn a lot, get up to speed, and dive deep. Lee, where can agencies access more technical documentation and white papers?
Lee:
Our public website (https://sciencelogic.com/) provides a lot of those details. Our technical documentation is publicly accessible on our Support site. We go through that as part of setting up a Proof of Value (POV). We also introduce them to integrations and expansion capabilities through Power Packs. Power Packs come in three main types which include monitoring, synchronization, and automation. Clients can also build their own custom Power Packs. Our REST Easy webinar provides a good overview.
Sean:
Outstanding Lee. You’ve been very gracious with your time today. You’ve supported our federal clients amazingly over the years. We look forward to working with you and our federal clients in the future to help them achieve their AIOps objectives and streamline their operations. Thank you again for your time.