OpenText Operations Bridge Reviews

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

My primary use is the consolidation of monitoring tools and dashboards.

The most valuable feature is that everything can be consolidated into one dashboard.

The service takes a very long time to start and it requires a lot of resources. A huge amount of memory is required.

The setup process should be simplified and faster to complete.

I have been using Micro Focus Operations Manager for 15 years.

I have experienced no issues with stability.

I have not needed to scale this solution. We have fewer than 100 users and we do not plan on increasing our usage right now.

I have not needed to contact technical support within the past year.

My team has been in contact with the local Micro Focus partner and my understanding is that the local partner's skills could use some improvement.

We are using another similar tool in the company, but it is not in my department.

It took approximately one week to complete the installation and setup. I would say that the setup process is painful.

I implemented and deployed this solution myself.

I don't remember exactly how much it costs but I know that it's affordable.

I would rate this solution a seven out of ten.

The most valuable feature of Operations Bridge is the centralization of all the alerts, events, and topology-based statistics that you can see in a centralized view for different customers internally. It could be your support groups, your management, or your governance. That's what we feel like it's giving us. It is the ability to look at it holistically, even though it's pure statistics from events and notifications. Your key performance indicators can be validated very easily and centrally.

From our monitoring perspective or from a visibility perspective, HPE UCMDB is a must have. It's an amazing piece of software. Regardless what other systems you have in your environment, you should have UCMDB in place because it performs a very good classification and discovery of your CIs. This tends to build up that service model that can be utilized between any piece of software. This is a great value we are getting out of UCMDB.

Operations Bridge, as is the OMI 10, is a great piece of software. It has a lot of potential that needs more exploration and we'll be doing that. We will be engaging my competent team, because we are working with HPE very closely, even for the developmental aspects. We are providing our inputs and we are bringing that change which is required for the tool. I must say that OMI 10 has great potential. This is where our core focus is, to improve on that potential aspect.

Reporting has to be tackled a bit more. Conceptually, it is there and conceptually it is amazing, but somehow the module itself is suffering. This is one of the issues with stability. The reporting module from HPE is not a very stable module, which is OBR to be very specific.

I'm going to have a round of meetings with the product development and the management to talk about that and to have more design plans and roadmap on this.

Not all the modules are very stable, but definitely we know from our practices and operations which ones are stable. Regarding the ones that are not stable, we are constantly having engagements with HPE support, as well as HPE development, to make it more stable. There are a few unstable modules, but most of them are very stable and long running. As our environment is changing, the requirements are changing and we are adapting based on our plans.

Initially, we started with the normal support. We had a lot of hiccups. Then we had a lot of discussion with the product teams, as well as the HPE account managers. Then we went for the FlexCare support, and that actually changed the way support works with us. We were able to receive Level-2 support directly instead of going to the log procedures and wasting time over the initial assessment of the cases. Then we were able to get guys directly involved in our support issues or the cases and incidents, which actually helped us a lot.

Transparency is one of the big features. We reduced our attempt to repair by forty percent. That was one of the big benefits. The other one is transparency between the departments, as well as for the executive members, the board of directors. They look actually at that data on a daily basis.

The transparency shows us where we still have to add things, monitor things that we don't have under our control yet.

Stability could be improved. Also, it could be easier to upgrade and patch.

Stability could have been better. We were running into problems sometimes where the whole system was not performing as we expected. We ran into strange phenomenon like data not being presented as it's supposed to be or overall system instabilities, such as when a database breaks away and it just doesn't recover gracefully.

For what we use it for it works just fine. We used a larger size already and we don't have a need for increasing it right now.

I was involved in the initial setup. The initial version, that was still BSM 9, was more difficult to deploy than it is nowadays. It has definitely improved in that department. With containerization it would definitely further improve the deployment of the solution.

We looked at BMC. I was not part of the decision making process in that area.
But we choose to stay with HPE. We don't switch that kind of software for every two years out. That's not feasible budget-wise. But the initial reason for choosing HPE was that graphing and alerting were easier to implement than it was with BMC.

The most valuable feature is its ability to integrate with everything.

It identifies parse issues pretty quickly. Instead of logging multiple tickets, we actually deduplicate those and just create one ticket, which makes our operations a lot easier to manage during the incident.

When the systems talk to each other, it becomes sort of a drop and go. And I'm talking purely in our instance, because, from what I see, it seems like none of the other countries have that issue. But it goes back to not having enough skills within the African region, with HPE and with all their suppliers. Once they sort that out, we won't have to get all the people from other countries to come and do it. It should make it a lot easier to manage.

Our issues are largely support related due to where we are and the knowledge base that we have here. This issue relates both HPE in general and to the technical products.

We have worked with other vendors, but the difference is that the knowledge or the course and certifications are made available in our country, whereas with HPE you have to actually go to a different country. So our challenges are more pronounced with HPE because people are less certified.

The functionality of OMi itself is actually cool, but if you can't use it, or if you can't get your teams to set it up properly, then I have to rate it lower. If we could implement it fully, I would rate it probably to be about a nine or a 10.

The product itself is a nine or a 10, but because of the limitations within South Africa, it's more of a seven.

It's pretty stable. The only real issue we've had is knowledge of the solution in Africa. I have discussed this with the team at a recent conference as well. Knowledge and skills are not really something that is sold in South Africa.

There are no issues with scaling. We are looking at adding new sites, which it pretty much copes with easily.

We use VMware, Fortinet, and Cisco. We are staying with HPE because we use HPE for all our server and storage. Cisco for the networks, Fortinet firewalls does load balancing now as well; we've actually moved that to them. We don't want to be a single vendor shop. That's why we stick with HPE for this solution.

What's most valuable for us is the ability to see all events that occur on our network.

It gives us the ability to monitor the entire infrastructure proactively and reactively. We can build incident event management and problem management processes in case of a problem so that an event is registered. We can then change the event to an incident and resolve it in the least amount of time as possible. If we can't resolve it, it enters our problem process where we can determine the source, possible fixes, and prevent the same problem from occurring in the future.

There are a couple of areas of improvement:

• Performance needs to increase; and
• Better correlation from the box rules.

We've used it for four years.

We haven't had any issues with deployment.

Stability is pretty OK. We previously had issues with a large amount of correlation rules, but OM has mostly eliminated these problems. We've thrown 1000 different correlation rules at it and it's working just fine.

Scalability is not relevant because it's a standard solution that's built for a particular purpose, which it accomplishes.

3-4/5

We performed the initial setup, which I'd rate as 3/5.

We did evaluate other options, but the suite of HP solutions -- Operations Manager, SiteMinder, Essentials, Service Manager -- is better than anything else out there.

Plan and then integrate. Planning requires a good assessment of your needs. Be prepared also make some in-production investments because you'll likely need to make changes on-the-go as you determine how to correct mistakes.

Operations Bridge is a solution that will bring together a lot of various operation data sources from the network server's applications and help the customer to focus in one area, one place, so they can escalate and route the issue to the proper resource for particular incidents. I've applied that type of software for various customers.

It optimizes their operations efficiency, and makes people more focused on the issue at hand instead of trying to figure out what's going on. It gives them an up-to-date status. If there's an issue in the IT system - whether it's a server, network, application, or resource issue – the product emphasizes it and gives you tools to troubleshoot and resolve it.

I think they are moving toward the whole platform format. They need to move away from Java, Flash, and plug-ins to streamline the integration with third-party products. This will make it easier for customers to use and deploy; using wizards and those type of things. I believe these are in the lifecycle and will be in v12.

It's been a pretty stable product. In its earlier years, it had typical lifecycle and maturity issues, but now it's at version 10 or 11 and seems to be running fairly well.

It's been very scalable; as a platform, it handles various data sources, both from HP products and third-party products.

The support team has had its struggles; it is getting better. I think the split of HP into two companies has helped, but that on-going process has created some issues. However, they seem to be working through it and getting better. I think it could be improved with regard to response time, and getting the proper resources.

I'm a senior consultant, so I've extensive experience with the products, so my issues probably should be escalated to a higher-level person from first-level support, rather than have them going through the routine scripts, because I've already done that. No reason to repeat it.

For various customers, I deployed it and helped them run it. It has its complexities because IT has its complexities. When you're monitoring IT, you're going to inherit those complexities, but HPE did make pretty good strides to pull in the data sources and make out-of-the-box integrations, both for their products and for third-party products. Making it the most seamless product possible.

We do work with other solutions. I would say HP is probably one of our largest partners but we do work with other software vendors. We do some integrations with IBM's NetCool, and with legacy products. HPE make their products modular, even at the data cluster level. We can integrate into another Ops Bridge, but we have also done some other conversions of customers’ ideas and IBM's, and converted them over to HP's products. Sometimes it's a toss-up. Sometimes it is politics in the customer's technology.

You have to have an IT operations background, be familiar with the processes of IT operations, have that type of mind-set. A lot of technologies are based on previous HPE technologies, so some history with HP's legacy products helps. Even though this is a new product, that's always helpful.

I think it's ability to bring in obviously the HP products into one place, gives you a meaningful lens, meaningful correlations, and the ability to process and to take on third-party data, event streams, and metrics. Bringing it all together and it being not as complex as building your own integrations from scratch - they give you a nice, good jump start to bring the third-party data in - is where I give it strengths.

I recommend it and obviously I do make a living deploying it, but I also like to see whether it has value at a customer's site. Can I solve some of their problems, some of their use cases? Because even if they deploy it initially, if they can't use it and get value out of it, it won't last very long. You have to make it fit in their environment and solve some of their use cases and scenarios, and then they'll continue to use it and grow with it.

First case of installation of the tool with the business branch of a French telecom provider.
We installed the tool with SiteScope, Network Node Manager and Network automation.
I don't remember the exact environment but we had more than 2000 network nodes and a number of servers.

Installation of a preprod and prod environment. Not much customization. Some rules for enriching and installing the different connectors. Some business view was created too

Great experience but I moved to network automation for a new project.

the implementation of Operation Manager made it possible to centralize the events of several supervision tools such as sitescope, Network node manager or Nagios.

This is one of the big advantages of the product, the connectors developed by microfocus.

All the enrichment part allowed to reduce the processing time of support tickets. All the information was already present in the alarm.

We could have gone further with the connectors to the ticketing tools.

Translated with www.DeepL.com/Translator (free version)

the most important aspects in Operation Managers are:

* The total environment provided by microfocus. All the tools can be implemented together with a certain ease.

*A lot of documentation provided by Microfocus and a fairly large community. The forum is provided in response from members.

* Enrichment is also a strong point but also found among competitors

level 1 technical support is incompetent. I'm almost afraid to open tickets because I know I'll be asked the same thing 8 times.

The price is very expensive for a tool that doesn't evolve very quickly compared to competitors.

I've been working with the solution for five years.

We haven't faced any stability issues. There hasn't been any crashes or glitches.

We haven't faced any issues with scaling the solution.

lot of bug with queue

We've been in contact with technical support, and we find it to be unreliable. They always ask the same questions and they don't fix the problems. We're very unhappy with the level of support they provide.

We're currently looking at switching to Canopsis, which is an open-source product. It has all the modules we need and it's absolutely free. It's very similar to Operations Bridge, for the most part.

I didn't participate in the original setup, so I'm unsure as to if it was straightforward or not.

The solution itself is quite expensive. We did have to pay extra for technical support when we purchased the solution, however. It was included in the price.

We don't have a relationship with the solution; we're just a customer.

It's a good solution overall. On the market, there aren't many other solutions, other than maybe BMC or a few more. It's expensive, but it's very good.

I'd rate the solution eight out of ten.