What we have been trying to do is reveal APIs for some businesses that we're trying to create that still use some of our legacy platforms and incorporate the newer technologies that we're trying to bring on.
What we have been trying to do is reveal APIs for some businesses that we're trying to create that still use some of our legacy platforms and incorporate the newer technologies that we're trying to bring on.
It really has not improved our organization as the product was never fully implemented in production. The intent was to have the product help us to transform our platform offerings to better serve the broad differences in need of our customer base.
The most valuable features in Tyk Management are some of the API features. This includes the API versioning, the API catalog, and the API dashboard.
It is a little bit difficult to evaluate what needs to be improved at this point because we were evaluating the product. It is not the first name that comes to mind when you think of API management, so I guess from a standpoint of evaluation we are at a disadvantage.
That said, maybe the automation of processes could possibly be improved but I'm not really sure how it would be different and better than IBM's API Connect. One of the reasons why we tended to favor IBM is because they offer several products that we already use.
It's like IBM can connect and can easily be integrated into our existing landscape whereas Tyk is really an entirely new product. They need to come up with products that can help to more easily integrate APIs and provide a standard set of APIs for particular products. Sort of like product integration packs that would simplify deployment.
I can't answer about stability in a production environment because we were trying to explore the features and how to work with them and we never really got to that stage of deployment where we would test it under load.
I cannot say for sure about how scalable the solution was because we actually never used it in production. We took the technology as it came out of the box and just evaluated it as it was without modifications to see if it would fit easily into our model.
We never had the opportunity or need to engage with Tyk technical support.
We did not switch products from what we were using after evaluation. We had hoped it would help us scale our options for deployment and reduce costs.
The initial setup of the product was very straightforward.
The installation was done by us and generally just for ourselves and the purposes of evaluation. We did a POC (Proof of Concept) in Mozambique before deciding to further evaluate the product. We were just trying to evaluate it and the test did not last more than a week.
Tyk has a whole lot of features. You could actually break them up into separate products, maybe like an ESB, the actual API, the security component with a security manager and so on. This would allow for delivering partial packages that were cheaper. Not everyone will need or even want all the features.
We were using a few other products including WSO2 and IBM API Connect.
Tyk looked like a good product. I think the only reason we didn't go with it was because, from a group perspective, we were mandated to go with IBM. The reason we were looking at it was because of cost. Some of the customers cannot afford the IBM solution.
It looked like a lightweight product that we could use, that was reasonably priced and helps to reduce costs for clients who preferred that advantage. In the end, we ended up not using it because we managed to negotiate a deal with IBM to help lower the cost of the solutions we were already using.
In rating the product overall, I'll give it a seven out of ten.
They could really improve on recognition of their brand name, their marketing and their overall appearance in the market.