Der OpenAdvice Blog

Montag, 10. August 2020

Mini Series IBM Agile Service Manager – part two: benefits from a business partner’s perspective

If you read my first post on ASM, you should already know what #IBM Agile Service Manager is. In this post, I’m gonna highlight some of its benefits from a long-term #IBM Businesspartner’s perspective.

But let me start with a throwback to 2017: From my previous post, you know that Think was still held at Vegas, but I’d like to focus on an online finding I recently made: There is this blog post from September 2017 at, titled “Why IBM Netcool Operations Insight (NOI) Doesn’t Work” [], written by Mike Silvey. I found it while googling for an #AWS integration with Netcool (CloudWatch alarms to MessageBus probe, topology to ASM).

The article’s first paragraph basically sums up its view on IBM Netcool Operations Insight and explains to the reader why NOI doesn’t work: “It’s outdated, expensive to maintain, and it can’t integrate with your newest data sources.” Further down the text it gives some reasons for this mindset. As I first read this, I didn’t look at the date it got published and thought for myself: Wait a minute, what is this guy talking about? After checking the date, I understood, but due to the work I recently did with ASM, I couldn’t understand Mike’s reasons on why IBM NOI ain’t working: ASM disproves all three of his arguments: It is using state of the art technology, it’s easy to maintain and it can basically integrate with anything.

Now let me explain why: For the past ten years I’ve been working heavily with IBM Netcool software (OMNIbus, WebGUI, Impact, ITNM, you name it) and whatever project we were in, it had a tiny lack of visibility: Let alone that there are the standard EventLists, dashboarding/reporting tools or a Network view from ITNM, but all of these components had to be integrated and maintained. With ASM, this got much easier: It perfectly integrates with OMNIbus and any third-party system that provides some sort of topological data. Either using out-of-the-box integrations or building a custom ReST Observer. With these observers, it is easy to visualize elements, and especially their relations. On top of that, status can be derived from OMNIbus.

But the killer feature is the historical timeline view: Imagine you got a very dynamic infrastructure, where pods can spin up anywhere at any given time. Once an outage occurs, knowing on which environment this pod was, or even “is”, running on at a given time is key. In addition to that, you can use templates to define constellations of topologies and only see what you’re interested in. To top it all off, it is very easy to customize the UI’s appearance using custom images, shapes or colors. Even right click tools can be written in modern #JavaScript, making it easy to leverage existing tools. If you now wonder how all of this looks like, watch out for our next post, where we’ll show some real use cases.