IBM API Connect Reviews

The most valuable feature for me is the ability to distribute work among our API developers, so we don't have to do all the work as IBM API Connect administrators and IBM DataPower administrators. This simplifies the way our partners can access our API's.

Overall, it brings us closer to better API management in our organization. The next step for us would be to improve the whole solution by going to the cloud. That's what I'm looking at.

It simplifies development and allows us to do more for less money.

Based on my meetings at this conference, I'm satisfied with their roadmap, where they're going. Possible improvement is mainly around having more of the cloud oriented architecture bringing stability in adding new capabilities around security.

Stability has improved greatly with the latest releases. There were some struggles in the beginning. There were some components that were not stable. They weren't behaving consistently through environments when we moved stuff from development to demo to prime. I think core functionality is pretty stable but there are things on the outskirts that weren't so stable.

IBM DataPower is at the core and we can easily add stuff as we need or as our licensing allows. So I think that it's pretty scalable.

The technical support is good. We got some help from their experts.

We were using IBM DataPower without any additional layer. By adding this new obstruction layer with IBM API Connect, we're simplifying development and improving our interactions with our partners. It becomes more compatible to the industry standard having the API management system in place.

The setup is complex but we didn't expect any simple things at such a large scale. It's just too many moving parts - IBM API Connect consists of three main components and they all have to be synced up. There's a lot of setup and networking and then you have to adapt it to your own environment.

Microsoft, IBM and CA Layer 7. IBM had the most capabilities that were based on IBM DataPower and could fulfill all of our requirements, even though the timescale was longer than we expected it to be.

When considering a vendor we just go for an industry leader, making sure that their technology stack aligns with our technology stack. We look at their reputation and how good the support is with the other products and what kind of relationship we have with account managers from that organization.

You should consider how much value you can derive specifically from the solution with all the features that are available. For instance, the main value for us was in organizing the API's and splitting work among several development teams.

Most of the business value that we are getting out of this solution, is that it provides DevOps integration and a catalog for microservices. We are able to share those APIs instantly within the organization; even if we want to share it outside publicly, then we can have those capabilities.

There is a trend to move towards microservice-based solutions, where we have to decouple all our legacy SOA-based services, when sometimes it takes an iterative approach to come out with what you need. Instead of that, we have this microservices solution, where you can just enable the required part in quick delivery using DevOps. These are the main benefits of this product.

Mostly, I would like to see more tools that are DevOps-friendly. We would have more capability to interact with the catalog and inventories, so a more DevOps-friendly solution is needed.

Stability has still not matured. We are still growing with the industry. We will find out after some time how it is going. But, as of now, it's stable.

Right now, in terms of scalability, everything we have is on-premise. However, we have this Bluemix capability, with which we can scale as and when we need.

We have used IBM professional support/premium support. We use them for any of the solutions, such as if we need some guidance on the future roadmap as to how it's going, etc; we engage them. They are excellent. They are always not only there to help us resolve the problem, but also to be able to guide us as to how the trend is going and what we should start thinking in regards to those changes.

We have this monthly inter-tech meeting, where we go through as to what is going on in the market, how the industry is going, and how we can utilize that in order to start serving the business, with an expedited return on the investment. So, this API, DevOps, and microservices are the things which are happening right now.

The most important criteria while selecting a vendor are that they should be able to help us not just with solving problems, but they also need to advise us in terms of how the trends are moving and how we can be strategic partners, instead of it just being a one-time solution.

Advice depends; if you have a preferred technology and IBM has a solution for that technology, then I'd definitely advise you to use more microservices with the API Connect and the DevOps, to provide quick returns for your business. It will be more valuable to you.

It provides a few features such as security and discoveries.

What we look for most is security. API Connect can provide that. On top of that we use it to replace the old version. The current WSR was for discovery, the web service.

Additional features probably will be easier to develop. Right now the UI is using quadruples. On the policy, they are using SSLT, but I would like them to convert that SSLT to use scripting language instead.

We just started. We are converting from the old infrastructure to the new API Connect. We started maybe a year ago, but we'll see the results maybe in six months.

I think the scalability is pretty good. The API Connect divides by different zones, different domains. So how we can scale depends on organizations. If it is big, we make it big and if it is small, we make it small. It's pretty easy to use.

We used the support quite a bit, because we have to transfer the old WSR into API Connect without rewriting everything. With that transfer or migration, it takes a lot of work, so we talk with technical support. They are pretty knowledgeable, but we still have to go through many iterations, many cycles to get all the technical information out.

Beforehand there was the older generation of API Connect. API Connect came out maybe two years ago, before that was WSR combined with data power. They are going to retire WSR. WSR is also for my VN. That became AP Connect so we had to move.

I wasn't involved in the initial setup process.

I would think customer service and trust are important when deciding which vendor to choose. IBM, Oracle, and Microsoft were on our evaluation list. We've been with IBM for many years now, so we'll stay with IBM. We work very closely with IBM on their product and they're very good support, so when we run into issues, they are there to help.

I think IBM is very innovative and maybe that will give them an edge into their industry.

I think the most valuable feature is the fact that it sort of combines IBM DataPower being a security gateway with some of the features that are in IIB and IBM App Connect, to kind of build a complete integration. Also, IBM API Connect being the API gateway is extremely valuable both for internal and external consumers of APIs. Off the top of my mind, those are the big points that I would add.

For full transparency, at this point, we brought the solution in and we've used it for a couple of internal hackathons, but we haven't actually used it for any production work yet. Like any bank, it's really forcing a transformation in the sense of the whole industry related to cloud and related to connections to the outside. We're really trying to figure out, internally, how we want to define that.

Some of the other growing pains we've had is, how do we operationalize the technology in the sense of ownership internally; to say, which different groups should actually own which component and how we control the security across that. Personally, my side of the house, which is being responsible for delivering solutions on behalf of the businesses, I'm ready and anxious to get going on it. I'm very excited about the possibilities that the technology brings.

I think that some features that would be kind of cool are around the whole idea of a subscriber being able to subscribe to a plan. Not only should that plan include the number of calls per month or per week or whatever but also, I want to subscribe to a plan with an SLA, which gets into response time of an API call. If the response time in the plan that you subscribe is like 200 milliseconds with a 99.9% guaranteed delivery, then I should be able to subscribe to that plan and then be able to go into it and actually see how close I am to adhering to that.

Internally, this makes for some very interesting conversations right around going from application to application, issuing a connection and they're saying, "Hey, well, we're going to make this many calls a month and this is what we need the response time to be." You could literally say, "Well, we're hitting the SLA." Or, "We're not hitting the SLA." Externally, I think you have the same sort of commitments and when you're negotiating contracts, especially on the larger business partner connection, with the business-to-business connection conversation as well.

Given the fact that it's not operationalized, I cannot really comment too well on the stability because we haven't really had to worry about the stability yet. I'm not really in a place to know. I've heard rumors that there are occasionally some issues related to how it maintains connections with its other pair, but I don't know enough to know.

Based on the architecture, from what I've heard, it's quite scalable. It's just, bring in more nodes and away you go. My understanding is it’s very scalable.

Personally, I have not used technical support.

We did not previously use a different solution. Let's face it: This is a relatively new space and we’re a bank. Of course, we knew that the solution was going on.

I was not involved in the initial setup.

I do believe that there was an RFP process that we went through as part of the selection for this tool. I do not know which other vendors were on the short list.
Usually, our vendor selection process is quite rigid around that. Everything comes into play. Of course, there's cost but then there's, how well it's going to be supported. What does the product roadmap look like? How well does it conform to our internal technology standards? How well will it play within our environment? There's a lot of stuff there.

I think if you're working with IBM and you're looking at possibly using Bluemix now or in the future, the other thing is, if you're using IIB or you're looking at Salesforce, there are a lot of synergies related to these platforms and this tool set, so it sort of makes sense to head down this road.

Personally, if you're a small startup, you might need to evaluate the entire landscape a little bit differently, but if you're a large enterprise and you already have a pretty big relationship with IBM, I think that it makes a lot of sense.

My rating reflects the fact that it's not operationalized at this point, and that's not entirely the product’s fault. I see a lot of potential, but there are still some things that need to be there.

As far as API Connect, I think it offers us more flexibility with our application and potentially would allow third parties to come in and develop for us. It also enables us to streamline our microservices journey.

The main thing is that it just makes app development a lot easier.

Stability.

It was a fairly new product so there was, so it took a year or so to really stabilize. But now I'm happy with the performance.

No problems.

It wasn't me that did it personally, but I would say good. We have a good relationship with IBM.

We were using a different solution, but we knew that this was the future, so we knew we needed to switch.

Fairly straightforward.

Yeah, I can't recall the name, but we are an IBM facility, so we just figured it made more sense for us to go with this package.

When selecting a vendor, trust is important, as well as that they deliver. Just someone you can be comfortable with.

I rated it an 8/10 because it's not fully mature yet.

It provides a good, simplified user interface to design and secure your APIs.

First of all, it gels well with the other IBM products that we have. It resolves some of those integration problems that we earlier used to have. It provides OAuth2 authentication, which is like what we use in our APIs. So, these are the two main benefits of this product, as compared to what we were using earlier.

A lot of the features require improvement, such as better integration with the other suites of the product and a more secured way to put it on the cloud. Another useful feature needed is to make API development more easier and simpler for development, especially on the management of other artifacts, like the client IDs and other stuff.

I would rate the stability a seven to eight out of ten; it's still evolving. There are features which are missing, that are there in the other similar product from another vendor. Overall, it's good.

The scalability is good, it's at par.

We have used a lot of the technical support! We work with IBM on a lot of custom enhancements, that suits our needs. They are really proactive in regards to listening to the customers. So, they also provide a few fix packs to us sometimes.

We have a relationship with IBM. They approached us with this product and as I mentioned earlier, it integrates pretty well with our other IBM products that we use in-house. So that made us to go toward this product.

IBM are the market leaders, when it comes to integration technology. So, their proven ability and experience is why we chose this vendor.

Experience is the number one criteria while selecting a vendor. The second factor is the brand and the relationship, of course, it matters.

We do have other vendors that we use. However, the majority of our integration is on IBM.

It's good. They have really good use cases. So, it's worth investing time in these products, and if it suits your needs, then you can really go for it. It does support a wide variety of use cases.

We've yet to realize real value in the solution. The goals that we were trying to achieve from it were to implement microservices and a lot of the features and functionality that were part of the documentation, but we haven't achieved success with it yet.

The benefits would be that we'd have a great platform for our microservices and API management. But since we haven't had a lot of success with it yet, it's been frustrating.

I would like greater stability and greater ability to actually administer the product without needing to go to technical support. It's very proprietary and support has secret passwords that they use to get into certain functions.

IBM has limited the capability for executing typical admin commands and only provide a small list of proprietary commands. Without a secret command line password, clients are limited to what they can view and administer – even in a read-only mode.

Stability is not good.

Scalability is good.

I would rate technical support fair, at best.

We weren't using a different solution. This is a new approach. We do have alternatives that we are using, including other IBM products. But we did this one more from a sales relationship, technical sales team pitch.

When selecting a vendor, reliability and experience are most important; the fact that we had experience with them. We have a lot of IBM products and we had a lot of good relationships.

I was involved in the initial setup and it was somewhat complex; medium complexity.

We didn’t look at other vendors.

Certainly look at other options that are out there and absolutely go with the latest and greatest version of the product, because there have been a lot of issues and it's going through growing pains. It's not completely mature.

I like how it runs within DataPower, and adds the extra OAuth security. It gives me a common place to do security for all my API services.

The biggest benefit is the availability provided to the people that will use my services. They can go to a portal and look for services to identify which ones they'll use.

We use it for existing IIB services. We call on multiple back ends from the same service where the record layouts are different. It's difficult to describe and use them in the product.

Actually, we're in production for demo purposes, so I really can't speak to this. So far, we've had no issues.

We have used technical support and we have a good response.

The decision to switch was made before I had left IBM and went to this company four months ago.

When selecting vendor, support and longevity are the most important criteria.

I was involved in portions of the initial setup. It was complex from the standpoint that there were a lot of components, but it wasn't difficult.

Make sure to understand its purpose and what it's used for and not used for.