OpenText AI Operations Management Reviews

Purely, its flexibility is the most valuable aspect. It is hugely configurable. We have a huge amount of different kinds of technologies, different kinds of operating systems and management packs that effectively are run and managed by Operations Bridge.

The latest versions of the service reporting dashboards need improvement, such as service modeling. A lot of our customers want to be able to understand and look at their solution end-to-end, including all the components, all the management elements of the operations, and the system's databases. I think that's the way the market is going anyway. People want to see an end-to-end service and they want to have that visualization of it as well.

We first started to install the components that make up Operations Bridge in 2005.

It is hugely stable. Actually, I would have to say that was one of the main reasons why we have kept it. We run it on what is probably an ancient platform now, but it is rock solid. Fingers crossed, it never fails.

We were an HPE Gold partner at the time of the initial setup. That's primarily why it was brought into the organization. It has shown itself to be worth its weight and not very much was paid for it. Our business has quadrupled in size since 2005 and we are a much larger organization than we once were. It has scaled and grown with the business.

It's supported pretty well. We've got some really good in-house guys who know their stuff. We haven’t raised a call about Operations Bridge for a good few years now. This is primarily because we install our own installations. We manage them, we develop them, and we understand how they work.

When choosing a vendor, I look at the solution. My directors look at cost.

The setup takes a lot of planning and preparation, like any upgrade. You just have to make sure you have a basic plan. I think it goes like the old adage, “If you fail to plan, then plan to fail.”

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.

It's difficult to assess the valuable features. We are living in a small country while HP is more focused on larger companies, so for us it's quite expensive. It's very powerful, but it's quite expensive.

The broad integration possibilities, I'd say, with any kind of product, are probably the most valuable feature.

We are waiting for quicker release cycles. Also containerized upgrade, so that you don't have to bring a system entirely down to make a minor upgrade, in fact, or a minor patch.

With support, you have to apply some changes which require a restart. That is in fact unacceptable. It's a good product, but there's still too much development to do on the customer's side to have it really working.

We have been using the solution, all through the versions, about 15 years.

It's quite stable.

In the latest versions, it is quite scalable. The problem is, when you want to extend, it takes a lot of work. It has a lot of consequences. I hope this will be improving very soon.

Technical support is improving. I'd say they're rather reactive in most cases. I'd say that on the later versions of Operations Bridge, for instance, responses are quite good. Looking into all their systems, which are still supported, we're missing some information.

I have the impression that the engineers are not skilled enough anymore because they evolve. All the older products tend to be forgotten. But we're still dealing with them. It's a bit of a challenge.

Setups are complex, not straightforward. First of all, there are all the checks that you have to do. You have to see if it does not interfere with other integrated products. There are some parameters that might get lost.

There's a whole bunch of eventual hot fixes and patches that should be installed first. This requires down time, so you bring down the entire system. That's a very bad situation.

We consider mostly the solution itself when assessing vendors.

The ability to integrate directly with the RIPM on top of DSM. We're looking to use the event feed into OMI, the metrics feed, and using things like SHA. There might be opportunities later to try for a faster root cause analysis.

At the moment, we're still building the system, so I can't say.

When installing against IIS, you need to expect a fully locked-down IIS, rather than expecting a fully out-of-the-box. It is sold to enterprise customers and I can't believe any enterprise customers would be happy to leave IIS out-of-the-box. I would think that everybody would have locked it down. You add what you want to include in a white list, rather than blacklist out what you want to exclude. So, the IIS configuration definitely needs to be improved.

The installation instructions need to be improved, as well.

We had a designated person with FlexCare. He was fair enough with the installation in general. I think we worked out what the problems were with the filters ourselves, because we've seen that on other HPE products. We were kind of expecting it.

We are combining it with other monitoring tools. They did a huge proof of concept to determine what the right fit was. I wasn’t involved in that. It was all vendor engagement, and so on. It wasn't just HPE, we had other vendors as well, such as IBM and Compuware.

The installation instructions are a mess to the point where the advice given to us by other HPE people has been to not follow the instructions, but to follow the VMEs instead.

The installation for an enterprise IIS solution, rather than just an out-of-the-box one, doesn't work very well. We ended up needing to troubleshoot the installation to get it to work. Installing the IIS filters was a big headache. We installed them, but we couldn’t do anything until we went in and adjusted them. When I left, there was still a problem creating users. We couldn't do any of that, so I don't know if they fixed that yet.

For people doing this for the first time, if you have support from HPE, use it. Milk it. Use your FlexCare points and grab somebody. You might sail straight through. If it works, and you do not have any problems with that, then maybe you're fine.

The most valuable feature is the integration with other HPE products because it enables us to feed all the information into same area; whereas before it was in different sites.

It is very adaptable and relatively easy to install.

I can't think of any areas for improvement at the moment, but we haven't had it for long enough for me to say. We're still in the process of assessing it. It's been pretty impressive so far.

The stability has been very good so far. We've only had it a short time.

It is very good on scalability.

The technical support is normally very good, but occasionally patchy.

We were coming to the end of life with the hardware and software we were running, which are also HPE products. We've moved into this new area, so it was a combination of the hardware and software.

The initial setup had some challenges; but since it was completed, it has been very stable.

The initial installation document didn't have some of the prerequisites we needed to install the software; but we looked at the installation document again recently and they added all that information. So, in our particular case, it was good.

We're with HPE anyway, but the other vendors would have been Microsoft or IBM. But, really, it's generally going to be HPE because we're already using them.

I would recommend this product to colleagues given our current assessment, but we haven’t fully utilized it yet.

The most important criteria to us when we choose a vendor are stability and support.

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.

This is a mature product. There is good support from HPE and it involves constant updates. There is a path to move on to the next product.

It's our monitor of managers. It's our monitoring tool and it looks after all our servers.

At the moment, I don't know what the roadmap is for this solution. There's a product that's been out for two or three years now, called Operations Bridge. There is a migration path to that, but it's not an obvious one. HPE has not made that obvious to us, so I'm trying to find out how we move on.

The product and the UI need updating. Everything about the user experience needs updating. I work at the other end, which is the more technical end, and I like what it does. But when a user sees a GUI that looks like it was written in the 1970s, it doesn't fill them with any confidence. It needs more dashboards, more graphs, and more everything that management wants to see.

We've had this solution for 12-13 years.

It's fairly complex deployment, even though it's supposed to work out-of-the-box. It's a product that can be tailored. It probably will work straightaway, but if you want to get the best out of it, you've got to change it to suit your environments.

It's a mature product and has good stability.

The product has good scalability. We've gone from 100 to 700 servers without any hiccups. It's a very scalable product.

I have used technical support. They are good; perfect. We don't raise many cases, but when we do raise cases, it's good. They are the same as any other company. It's just support at the end of the day.

There is an issue at the moment with HPE, in that their support for this product has moved over to Sofia, Bulgaria. That can pose its own problems, but it's like anything that's off-shored. It's going to take a little bit longer, and you have to accept a few more difficulties when you're trying to explain problems or reject solutions.

I've looked at Moogsoft and Nagios as alternative products. There are lots and lots of other ones out there. I’m not sure if we will stay with HPE.

We've got a very mature product that would be awful to try and replace. However, if we don't get what we want out of it, and we can't go forward with it, then the new kid on the block will just come in and slot straight in.

When selecting a vendor, I look for attention to the customer and the support you're going to get when you're going through this. If we do move, it will be a fairly fraught experience. We want to be confident that either HPE or another vendor will be behind us and helping us down that path.

I've been working with it for 15 years, and I know how powerful it is. If you spoke to some of our end-users, they probably wouldn't even mark it, because they don't even use it. They don't use the interface, because they don't like it. There are so many other things on the market now.