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

It's really the basis for everything we do for event management, for enterprise management. It's a single pane of glass and it has the ability that when you select a particular event that you can see all information required in a single pane versus having to launch four or five applications.

You don't waste time launching multiple applications. You can actually have information right there in front of you. Again, it quickens the mean time to recover.

It's not mature enough. Like I said, we're being forced to go from OM to OMi even though OM overall, or OMi, as part of Ops Bridge, has many, many more features. Ops Bridge is a suite of tools. Most of the suite of tools in there are less than two years old. There are a lot of growing pains. They're forcing people to go from OM to OMi where OMi, even though on some parts it has many more features, the functionality that is really utilized by a lot of the industry is only about 70% of what OM could do, imported into OMi. Then the developers tend to be in an Ivory Tower development area instead of a real world area, so there's people that say, well why would OM people do that? I used to be a consultant prior to working here. I can tell you 150 companies that do it this way because these are all your Fortune 100 companies.

Their documentation points have spaces that don't exist. They will change their command lines without anybody telling you what it is. Like I said, it's a new product. I've been working with HP on this stuff and everything for over 30 years and I haven't opened up 50 tickets in those 30 years. I have already opened close to 60 just on Ops Bridge and had already seven enhancement requests. I should never have to do that. HP used to do very top quality testing before they would release a product.

We've been using OM for years, and it is at the end of life, so we had to migrate or we've been forced to migrate. Ops Bridge still has a lot of tweaks that has to occur, but we're working with HP to try to help resolve most of those issues.

Well, the whole installation was a nightmare. They have the evolution guide and the evolution guide is very incomplete. Like I said, that's the biggest thing. It says, well go do this, but it doesn't tell you how to go find the documentation on how to do that or it doesn't exist at all. It's amazing, one of the biggest answers that you get from the supports folks of that is that, boy I wish the developers would document it. Thanks for letting us know how it works. That's not a mature product. They also don't have training from an administrator perspective, only from an operator perspective. How can you release a product and there's no training for administrators?

The potential of what the product can do is amazing once you figure out how to do it. The latest release, I guess it's 10/11, of those 57 tickets I've opened up, I would say probably 50 of them have already been corrected in that version. It's becoming a much more stable version.

Hold off on it a little while. Wait for the next major release and hopefully all of the issues that have created a nightmare for me will be resolved. Even though they said it was out for over a year, it was not a product ready for release.

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.

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.

As a total offering, Ops Bridge is a strong offering in the market. It adds value; it's competitive in its entirety, from network scanning to enrichment, up into event information. The implementation is challenging with customers, so we see added value, but there are diminished returns due to the complexity of the implementation and also the maintainability in general. There are some challenges, but overall there is added value.

For its fundamental proposition and as far as the way it works, it works well. It's a strong product; it has a wide capability - especially if you integrate it with more application performance-related solutions - and if you have infrastructure scanning, those two work together well. The data model and the data flow is pretty good, so overall it's a product that definitely adds value in a complex organization; complex in terms of infrastructure and application infrastructure. It's definitely a good product.

The application is stable; it's about when environmental changes impact what you do and how you look at it. Increasing the reach of the application adds additional work.

When you look at it - for instance, in event detection – that’s when you want to understand how an application relates to the infrastructure, and how that works. There's some modelling involved; you need an understanding of how that application relates to the infrastructure. There's automation for that, but not everything can be captured. There's overlap between what different applications see in an infrastructure and how they report that back. To merge that information correctly, to make sure that you have the entire stack - the technology stack and application stack - properly configured, that requires attention, that requires configuration.

We worked with customers who want to manage critical applications. They have to map out the applications into the different infrastructure components; if it's mainframe related, for instance, which is still a big part of the picture, especially in the financial sector. They need to map the individual jobs and the alerting to an application, so that's a lot of manual work.

Depending on where you land, if you get stuck in generic level-two support, then it’s quite uninspiring – that’s probably the best description. There's a high return of returning tickets back to the pending customer; getting tickets closed without adding value to the solution. Every step has one question. A ticket goes to a pending customer, you send a response immediately, and 24 hours later you receive the next update, which says something like, "Thanks, now we need this piece of information." The ticket then goes back to the pending customer, so you can easily lose a week just trying to get to a point where they're looking at your issue. Even if you set up a WebEx in which they look at what you're doing and understand the issue, we still go through the same process; there's additional information we request.

It's really tedious to get through that. When you switch to level-three or more of the ACE-type support, that goes away. In a discussion with HP, they typically say something like, "You should upgrade your support levels."; buy better support instead of actually maybe fixing their L1, L2 support. If you have the product and support is part of the license you buy, then I would expect to have a certain level of quality in that support, without having to upgrade to some kind of premium plan. It's not about having a dedicated comm tech, or someone who understands your environment, or all these additional things. It's actually about getting a proper response to a well-formulated question.

For greenfield implementation, which still happens, fundamentally I think Ops Bridge provides a deeper level of understanding of what's going on in the infrastructure. If it's a complex environment, it's difficult to find toolsets that will address it correctly. If you look at the entire offering of Ops Bridge, it's one component in the suite that is relevant for monitoring your environment; detection of what's going in that environment.

If you look at Live and more holistically, all those components that include a BSM, OMi, and other products that I forget, that by itself offers multiple layers in the different technical areas of infrastructure. They work well together for some data modelling challenges, I guess, but overall it works well together and it provides a many-layered insight into what's going on in the infrastructure. You have different levels of how you can see what's going and analyze what you should be doing to address that.

In a complex environment, I don't think there are many good alternatives that offer it more or less end to end. You'd be cobbling different vendors, maybe with the exception of BMC, which probably could do it. The overall offering is consistent and as wide a technology as you can find, so there's strong benefits because you can do it all with a HP stack with augmentation of some of the specific domains with other vendors, which you have to do anyway.

I don't know if there’s any alternative. I think the main driver there would be how comfortable they are with the existing product suite. I think IBM is probably the strongest alternative in the field. I think they're behind, from a technology perspective. The only thing that they seem to be stronger with is related to the visualization.

At the Ops Bridge level – basically, at the highest level - how do I view my environment? What do I see going on? And, can I use that information in an aggregated way to prevent or limit the impact of occurrences of events in my environment? That's what Ops Bridge, or the OMi component, doesn't have to that level. You can't go from all the way to the top to all the way at the bottom to drill down, you have to use different environments for that. IBM does have that.

If that's important to have on there, then that's one of the things the people that manage the infrastructure need to be able to do. Especially if it's over multiple sites - a strong geographically dispersed environment - then they would be an alternative, but for all other situations, there isn't much else out there.

As with anything, it's not just a tool and switching it on. They need to realize that it's a journey with a lot of challenges. Especially organizationally, it's not only about putting something in to existing systems; it’s also the desire to be compliant in organizational departments; it's invisibility of infrastructure because of security reasons or appliances that don't allow access. There's a lot of challenges organizationally that, even though you have the best software, you're still going to have to put a lot of effort in.

Overall advice is that if you do this, you need to commit and to be ready to put in a lot of effort in getting your organization to basically comply and help out. I think these products are really strong in terms of UI, but there's room for improvement in some of the usability and some of the integration components could be stronger.

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

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.