OpenText Operations Bridge Reviews

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.

I think what I'm really looking for is being able to get a faster root cause analysis for events and incidents that happen, including correlation of events across networks, servers, and applications across our infrastructure. We have a real hybrid landscape where we are on premises, as well as in the public cloud, across AWS, and in the Azure cloud. We want to make sure that we have our operations running brilliantly with fantastic up-times. We think that getting our resiliency right is possible, because we get faster root causes and event correlations that can actually come from the solution itself.

When we first transformed from being on premises to going significantly into the cloud, we had to go ahead and change a lot of our enterprise architecture and landscape. We needed to be networking very differently and to be leveraging virtual machines on the cloud very differently and in a cost-optimal way. This clearly meant that our internal IT had to operate very differently from what they were used to in the past. We needed to get them to change themselves and work differently so they could provide these kinds of services. IT needed to be able to give me the kind of resiliency, simplification, standardization, agility and the promise of the cloud with optimal cost. This was something which was important, and that's what it did to transform our IT.

I would like to see a lot more ease-of-use, as well as easier deployment of the product itself. Considering that the people who end up using these tools are much more cloud native for everything else, they would want to see something which is cloud native and as brilliant as some of the other products which are out there. That's something that I believe can be much better. I think HPE has this on their roadmap to actually get there.

Our level of implementation is not so deep as yet to be able to go ahead and say whether it's stable or unstable, but whatever I have seen it has been fairly stable.

We are a very large organization with 170,000 employees. This product completely scales to meet our needs. We have 4,000-plus network devices, about 2,000-plus on-premises servers and about 1,000 cloud-based virtual machines, all of which are managed through the HPE solution.

I think we need to get a lot more depth to be able to see how much technical support we'd actually require. So far it's been okay, but I would think that when we get much deeper entrenched into HPE Operations Bridge and use it significantly, that's when we'll really need technical support and that's when we'll figure out how good or not so good it might actually be.

Initial setup and deployment has been fairly complex. There are specialized skills and expertise required to run deployments. Once deployed, I think the solution is fairly robust for us to go ahead and use.

I was not involved in the actual buy decision when that was made some time ago, but I do know that there are competitors out there. But I think some of them would be more collaborators rather than competitors.

As an example, at a recent conference, Scott Guthrie from Microsoft talked about the OMS suite of products, and that’s amazing because we are on Azure. I know that OMS has a set of capabilities that the HPE suite doesn't. On the other hand, the HPE suite has some capabilities that are not there on OMS.

We really like the synergies between both of these products, HPE Operations Bridge and Microsoft OMS, going forward. That got me thinking that maybe I should get OMS as well so that we can do some of the things that I want to be able to go ahead and do on Azure. We're heavy on Azure anyway and we would then be able to get the best of both of product lines.

Remember that Operations Bridge can do a lot, but it's fairly complex to get started with. It means getting people to adopt the product significantly for them to be able to maximize that kind of investment. Once it is in there, it's extremely robust. The kind of value it can provide to the business would be significant. It should be maximized by all businesses, so go ahead and invest in the suite itself for the enterprise.

I think HPE has a fairly good roadmap. They're taking advantage of the kind of movements that are happening in the cloud. Going hybrid IT means being able to bring the best of legacy services that you've always had, with the strength of the solution that you've always had, over to the newer technologies which are really disrupting.

It helps us to take into account all of our infrastructure. It's monitoring all our infrastructure and is one single point of truth. It's also quite flexible for configuration. You can correlate certain systems with each other along with applications. Thus, we like the HPE product very much as it keeps our systems under control and in-check. You can also filter out the different alarms from your systems.

It has improved the working of our company, especially the working of our operation team. They have much more view on the servers and what is happening with them. They know when to act and on what to act. The alarms are very clear. There is only one central database for all the alarms; before we had to look on different systems.

It has not only the servers but also our network is in there. It's an all-in-one dashboard for our operations team so that is very helpful.

There is need to have more out-of-the-box support for HPE products itself.

For monitoring of HPE 3PAR, it doesn't come out-of-the-box with OpsBridge; we still need to install third-party stuff to it. At a recent conference, HPE announced that they will have their own software material, so that's improving. But we would like to see much faster support on the HP products themselves (including this product).

We've had some issues in the past with the previous version. Currently, we are using version 10 and with this version all the stability issues are all fixed. We still have some issues with certain connectors but they are also getting fixed by HPE as of now. The issues are within the third-party connectors for Nagios and NNMi. But that is now being handled by HPE; hence we are very happy with the product.

It's quite okay. You need a few backend servers to run it on but it scales very easily. If we run into performance issues, we just add some vCPUs because we can virtualize the installation. It scales very well with that.

I'm not involved in the technical support that much.

We were previously using something else but it was not fulfilling our needs. I think they were using a BMC product before I joined the company.

I took over once the product was already running. It's now handled by my team, but I have only recent joined the team.

We wanted the manager of managers so that we have one single point of truth for all our alarming activities, cross server applications and so on.

We also checked with BMC but decided to select HPE as it is the most flexible solution.

I would advise them to check this product out and to have a good look at it because we think it is a valuable system.

It is important to keep in mind the amount of work involved in setting it up. It is a lot of work because you need to have your agents installed on your machines, so it takes some time before everything is running like you want it to. For example, we have a license for 4,000 agents now. We use about a 3/4th of that number at the moment. Hence, its installation is intensive but once it is installed, it's fine.

There is no out-of-the-box support for HPE products. We have the feeling that it's going a little bit too slow. If they launch a new product, it's always taking some time before we get the connectors for the OpsBridge.

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.

It is mostly used for event management. We use it to consolidate events from different data collectors.

The correlation feature is the most used feature. It allows you to correlate events from different sources and have more meaningful events.

The deployment of agents on new CI should be improved. There should be some kind of automation to directly deploy them from the console.

It can maybe have some more AI functions because most of the other tools are going in that direction.

I have been using this solution for around two years.

It is stable. It has got high availability.

I haven't done that yet, but its scalability must be good. It must be easy to add new servers.

In terms of usage, mostly the operations teams work on these events. We have a team of around ten members.

Their support is good. The community is also helpful.

It was pretty straightforward.

It was actually management's call, so I didn't get a chance to look at other tools.

I would rate Operations Bridge an eight out of ten. It is a very good solution for event management and agent-based monitoring.

It's helped us to increase transparency of our line of business, as well as both transparency and visibility of the IT department within the company.

Currently the BVD, it's not living. We would like to see more sensors in the dashboard. If you go over 60 miles on the screen, nothing happens. Part of our BVD is a map of Switzerland with some highlighted agencies where there is something specific happening. If it moves over 60 miles over this location, nothing happens. But there are 160 locations and it's not always very easy to find out if there is a yellow light there and which location it is exactly.

The first implementation of the Business Value Dashboard went live early this year, so we have now 11 months of experience with it.

It is very stable. We don't have any vulnerability or issues like that.

The BVD does not have a problem with scalability. You can add additional sources and increased uptake frequency. We don't see any problems going forward.

It's a very new product so support is not very mature. You have to find the right people in HPE to support it correctly. Then it works great.

Well, implementation is straightforward. It's a reason to implement the dashboard. The more complex things are the numbers that will be produced, but that's not a problem of the product. That's a problem of how to consolidate these numbers.

The initial trigger was that we had a new head of communications and she has been working for a newspaper before where they had a very large newsroom. So we had to have a newsroom too and we had to fill it with content and the BVD was the best thing for it. At the time, we were approached by HPE to be the first user of this product and then we started the work with them. That was the way we went.

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.”

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.