Operations Bridge Review

A practical solution that takes different inputs from our operations and transforms them into unified, actionable events that can be automated.


What is most valuable?

I think it's a practical solution for taking a lot of different inputs from our operations and transforming them into sort of unified, actionable events that you can automate and make sense of automatically. We get a lot of different inputs in a lot of different formats which usually, once a person looks at it, it comes down to something very simple, like an event type.

Operations Bridge works with the idea that these events are mapped, sometimes manually, sometimes from pre-existing templates, into event-type indicators and then you can build automation logic on those indicators. That's valuable because it means we can do automation on events that come from different sources without going through each source every time to do the same automation, over and over again.

How has it helped my organization?

Actually, we're going to see measurable results maybe next year. We haven't had it in wide production use for that long yet, so I can't mention percentages, really. But so far, the experience has been that it enables automation from sources that usually don't support automation.

Also, it's just a very nice place to do some basic correlation and things like that. We've been using fairly old technology user interface-wise before this, so it's a nice upgrade for operators to operate in.

What needs improvement?

I'd like more integration between the separate systems that make up the Ops Bridge part of the thing. There's a separate reporting component, which is very separate at the moment. There's the operations analytics, which is also a separate product and has a very different stack from OMi and the other Ops Bridge core components. Mainly, I just want more harmony between those things.

That is a huge thing. There are a lot of different components you need to understand before you can get proficient at the product.

Also, the less Flash we can get in the UI, the better. That would be great.

What do I think about the stability of the solution?

We haven't put that much load on it, so it's difficult to know from that point of view. It's OK. The UI is web-based, but it requires both Java and Flash and these days, that's not really the cutting edge by any means.

We haven't had that many issues with it, but Java replaces native operating system and web components with Java components. Sometimes the functionality or the stability isn't what a native component would be, so we've had some issues there, but it's never been really that serious. It's just like, some scrolling thing doesn't work or you have to refresh the page; that kind of thing.

What do I think about the scalability of the solution?

There are pretty heavy limits on what the system can do. It hasn't been an issue for us, really, but the philosophy of the system is not a big data product. You can't just push thousands and thousands of events to it per second. It's not meant for that.
The idea is that you filter events below Ops Bridge and then just the ones that the element managers think might be actionable are thrown forward. For that, it's fine, but there is the risk that you lose a lot of visibility into events that you don't beforehand know that you should be pushing forward to Ops Bridge.

How is customer service and technical support?

We’ve used technical support for a few small things. It's been fine so far. We've gotten some pretty good patches and things for specific issues, so it’s been mostly positive so far.

Which solutions did we use previously?

We switched because it was beginning to be mainly in-house built software. We didn't want to take on the burden of developing it much further. It lacks these features and it was just essentially scripts running other scripts. We wanted something that had actual enterprise-level support, had a concrete development plan, and that integrated well in the systems that we already have.

How was the initial setup?

We did the initial implementation of the environments together with HPE; we built the production environment, they built the test and development environments as references. It was OK. In hindsight, there were more things that we should have taken into account before we started building, some of which we understood, some of which we didn't. All in all, there are a lot of components.

I think the changes they're proposing now to the product in the next year or two, those might help. We'll see. Or, at least we'll have new problems. But there are a lot of components to install on a lot of virtual machines, if that's your architecture.

Which other solutions did I evaluate?

We did a few proofs of concept with CA. We did proof of concept installations and went through some of the licenses that we already have elsewhere in the company, with both CA and HPE. We ended up with HPE because there we saw how we would develop this level automation that we're heading for, without the amount of work getting just ridiculous. I think CA might even had better monitoring components, but the event management wasn't as strong, at least for our use case.

What other advice do I have?

If you're researching this solution or something very close to it, before you begin implementation and the careful planning, look into your CMDB and data structures. Figure out what CIs and what information in your configuration management database you actually need to orchestrate monitoring and to orchestrate the views from the events that you get. Having too much information makes it impossible to test the solution, and not having enough doesn't give you the functionality you need.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
1 Comment
Mukesh-PatelReal UserTOP 10LEADERBOARD

I agree that reporting tool and analytics tool is separate but they are well integrated. I dont think there is any tool out there that has everuthing into one tool.

04 January 18
Guest
Sign Up with Email