What is our primary use case?
I use CA Live API Creator to integrate data from a variety of sources, and then to provide an API response to calls from my client applications.
There are a couple aspects of performance. One is just speed and uptime, and it's stellar in that regard. The other is, how much effort is it to put it in place in the first place, and then how much effort is it to keep it operational. That's where its real strength is. I'm able to do things quickly and easily that I couldn't do before.
How has it helped my organization?
The benefits are rapid development and deployment of APIs, which means that your information, your ability to handle information, to receive it and to send it, to visualize it, to report on it, to get intelligence out of it, happens fast and happens with accuracy. Faster is better.
It really allows us to do things that we just weren't doing before, things that we always talked about doing. Some things that we talked about doing for decades.
One of the things that we talked about doing for decades was the ability to bring data together from different sources, sources that maybe wouldn't otherwise be available. Maybe they were not ours to own. Maybe they were in a place where we just couldn't connect securely to them and enforce our security policies. What we can do is, as those things have developed APIs, we can consume APIs so we're building an API to consume an API to deliver an API. People can keep their roles and responsibilities, they can be responsible for their data integrity, and yet we can use that information to do what we need to do.
What is most valuable?
The most valuable feature is that it enables me to present data in the format that the client wants to consume it. That client might be a visualization tool, that client might be a report, that client might be a customer's API requirements.
The challenge is, how do you get the data structured in the way they want it, as opposed to how do you get them to change. My job isn't to make them change, my job is to give them what they want. Honestly, when you give people what they want, it's easy. When you try to get people to change what they're doing, it's hard.
What needs improvement?
The latest version that just came out at the first of October really was a powerful move in the right direction. I was very, very pleased with that because it allows now beginning to use information of things. We've got this IOT infrastructure that we can plug into, and for my use cases there are a lot of outdoor sensors that provide valuable information to my customers.
As we've brought on MQQT, and other ways of talking to those sensors, that just makes my life easier. I'd to continue to see them expand the scope of the product. But I can say that I've been extremely pleased with the work they're doing. They're not sitting around, every six months we get a release with major improvements.
Larger organizations have a real challenge. They have to control all the people that touch their data, and when it goes wrong - you've seen it on the news recently - it ends up being major headline news story. "Equifax exposes data to 150 million customers." That's intolerable to these customers.
What happens is that the companies that are working with that type of data have extremely rigid policies for who can get access to what. As we continue to develop the product in that regard, we would like to see continued integration with other CA products that accomplish that goal. I'm not saying that it doesn't do it now, I'm just saying that scenario where there can be continuous improvement.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
I've used it for four years and I have not had any issues with downtime or with performance. That's partly because it's leveraging networks; modern networks are stable. Ultimately, people want their Netflix and their movies over the networks. There is a lot of money going into uptime, and performance, and speed of mobile networks, of physical networks, that we just leverage.
We benefit because of the performance of those networks. All we're doing is leveraging public networks to move data securely.
What do I think about the scalability of the solution?
In my use case, I've not dealt with the type of data that usually responds to the scalability issue. Generally, when people ask that question, they're talking about scalability of hits, scalability of users. Where, all of a sudden now, you have tens of thousands of records happening within a very short period of time - will this scale? I don't have tens of thousands of records happening in split seconds. However, I do know that the product's been tested to that and has demonstrated outstanding scalability results in that regard.
There are other aspects of scalability. You might consider how well can I bring on new customers, how well can I scale my development team, how well can I handle additional API integration. Because of the efficiency of the product actually doing that, pulling data from disparate sources, and integrating it into the response format that I want, that my customer demands, that's so easy. It's 10 times, 40 times, 100 times faster than the way we used to do it, and that makes it very scalable.
How are customer service and technical support?
I use the technical support extensively. I actually read the documentation. I know that's not something that people normally do, but I actually read the documents. One of the guys said, "If so and so, whoever writes it, knew that, she'd kiss you." And I said, "Well, maybe we shouldn't go there, but... "
I actually call them, and they've been wonderful because I have their cell phones, I can text, I can call. They probably don't want everybody to do that, but they want their products to succeed, they want me to succeed, and I want to work with a vendor that wants me to succeed.
Which solution did I use previously and why did I switch?
You look where your pain is. If you can perceive pain, you know what you need to do. Where does it hurt? That's what you need to work on.
A different solution didn't exist. You developed things in code. You used C++, you used Java, because that was the only way to do it, to build it yourself. Now, much of the lifting is done, but the extensibility is still in the product. What you're forced into, or what you have the opportunity to take advantage of, is a system that has done a lot of the hard and mind-numbing, repetitive tasks; simplified so many of the things that you would have to do. Incidentally, that creates an opportunity for a mistake. Those things are automated, but the extensibility is still there on the product, so you can still do the things that are specific to your business's needs.
How was the initial setup?
I'm going to assume that this question is asking, "Was I involved when we got on board with this product?" Yes, because I bought it. They were there for support but the question is not relevant because it's so easy. It's deploying a WAR file. If you can deploy a WAR file, you're done.
Which other solutions did I evaluate?
Where I got involved with CA on this product, there were not really competitive products. Since that time, there probably are some companies that have come out, but honestly, I am busy enough, I don't really look because there's no reason to divorce myself from CA on this product.
What other advice do I have?
When selecting a vendor, there are a couple of things that you have to look at. One is: Are they going to be around? That's always a concern because if you've committed to something and the rug gets pulled out from under you, then you're scrambling. Depending on the time that happens, you might not have the time or the money to scramble. What if you're in the middle of a big implementation? CA has been around since the beginning. They're a four billion dollar a year company, something like 13,000 employees, I'm not worried about that. Yet they're easy to work with.
There are a couple of products that I work with that have not let me down, and there are a lot of products that have. I always use Microsoft Excel of an example of this. Excel is a wonderful product, you can do so much with Excel, it's an incredibly powerful product. But there are many times where Excel just leaves me short. I just can't do what I need to do with it. It has limitations, fundamentally.
There are a couple of products that I've worked with in my life that I haven't run into that. Maybe I still will someday, I don't want to be delusional, but this product, when I've had a need, I've been able to get it to work and that's nice, I like that.
It's hard for me to give tens, but I would give it a 10 out of 10.
My advice would be: Focus on its extensibility because of that exact issue we just discussed. There are so many times when you look at a product that is a tool to make something easier. Maybe you're building a web-based application. There are a number of tools on the market that make that a drag-and-drop opportunity or a drag-and-drop process. Those tools are great for the weekend warrior, you can get something done quickly. Maybe you're a high school kid and you want to build an app for something. (Access database would be like that too. You can get a database and it's not that hard, and you can make a form, but they're not enterprise class).
This product, at first blush, looks something like it's one of those weekend warrior tools, but it's not. It's an enterprise-class tool with the kind of usability that you wouldn't expect. And with that usability - how do you have your cake and eat it too? Well, it's because of the product's extensibility. It's very well-integrated with your existing Java library of processes and procedures, as well as your ability to write new extensions to it. You get so much of the base functionality but you don't give up the ability customize.