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.

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.

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.

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.