What is our primary use case?
We do business with a lot of other vendors and customers. Our main core business is to lend loans and lease furniture. In this context, we have to create partners and we have to do multiple transactions with multiple vendors and multiple facilitators. In this venture, we consider APIs the best, and our most sophisticated medium to communicate with other partners and other lenders at home and elsewhere.
We want APIs to be the most sophisticated and more robust. REST APIs are the core in this area. We have been using Mulesoft specifically to create our REST APIs, enlarge them, and also expose the endpoints to our vendors so that they can use them. Internally, we have been using the APIs extensively for all of our internal application communication. Raw ping and workflow and all those things. We use this Mulesoft extensively for API management, REST API stack, and also for the workflow.
How has it helped my organization?
We're going to have a task with another bank who will be lending us the loan or they will be giving us some money for us so that we can lend this to double customers and expand into different industries. We're doing the business directly with those banks who we're really trying to work with, and doing joint collaboration so that we can lend loans to the customers, the retail customers.
In this context, we have to collaborate with those banks in a sophisticated way. Few banks are very, very advanced in the necessary technology. We propose of them usage of the APIs. The advanced banks already have the APIs. That kind is a very smooth transition, but the banks whom we're working with, a couple of small banks, don't have the API stack. Whatever the legal systems they have, we enforce them to convert those existing legacy systems as the APIs, and also those other REST APIs, and we can have a smooth transition.
The initiative went very well, and they're very happy with a lot of the tasks we have been doing. Now, they have extended the business. They want to censor their existing systems. They want to expand their system. This is one of the examples of how the solution has improved our organization. In this juncture, we place Mulesoft as one of the core solutions in our organization API stack. Communicating with one application and other application, or the validation of the loan ID or the validation of a customer or generating the customer base, whatever it is. For the day to day tasks, we use API systems only. API is one of the most crucial parts of the IT initiatives which are going down in our office on a day to day business.
What is most valuable?
The ESB, the enterprise service bus is what we primarily use. In addition to that, the API management. These are the two tools which we have been using extensively. The enterprise platform.
What needs improvement?
I don't think that it's a negative, but one of the biggest things is this: when they were merging with Salesforce they never said anything about that, they did not give any positive or negative news. They were just silent about that. I think there's something clandestine has been happening over there. I'd like to know what is the future roadmap of Mulesoft is after it got merged with Salesforce.
Nobody is giving proper information because I called a couple of Mulesofters and they're not giving information. I don't know whether they're naïve, or they don't want to disclose about whatever it is. That is the first thing they have to address. If they don't address probably they'll lose a lot of their customer base, so they must have to address that.
Also, in regards to near future resellers - they have to increase the capabilities for the Kubernetes, for continuous integration. Mostly you can call the DevOps. Still, now there are some gaps out there they have to address for the DevOps capability like continuous integration exclusively for the Kubernetes and Docker. They say that they have complained, but I asked for realistic examples and concerns, and still very few things have to be addressed. That is the first thing that they're going to have to address probably. I had some discussions with those people there.
The second thing is they're mostly focusing on the security. I think security plays a vital role in going forward in regards to API stack. Not only for the API stack, but also for the enterprise service capabilities in which security plays a vital role. They're adding a lot of security capabilities over there. That is also one other thing I hope they continue to work on in the future.
In addition to that, they're going to add a lot of additional plugins. Plugins in the sense they compiled from Salesforce and a couple of other applications, but they have to address a few more applications. They should take a cue from Webex Desk. If everybody is using Webex Desk, every third-party application, and they want to communicate with Mulesoft, they don't have any plugins. They have worked a lot on the plugins.
Lastly, regarding the streaming of data. In terms of streaming of data, I don't rely on Mulesoft. Whenever they do new data streaming or any streaming, the conceptual architecture connects to us, like data streaming and also for video streaming. Because the streaming capabilities are very minimal they don't stream. The capability was not there.
I heard that they're addressing this issue, probably in the next couple of months. They're going to address this issue. If they are, then I think this will be one of their biggest achievements. I think it will impact their business and also their challenge. It will impact the whole pipeline also, so they can accumulate more customers.
For how long have I used the solution?
I've been using the solution for two years.
What do I think about the stability of the solution?
The solution is a stable one. But as the API stack has been increasing, whenever the new stack is saving, at the end of the day we have got our own Kubernetes to connect the APIs completely. The capacity has been increasing day by day, so we have to increase the capacity. We have to do so regularly. At least quarterly, we have to do some capacity planning for that. It's not cost-effective and it's got a cost impact too. We have to invest something around a few thousand dollars to enhance this capability.
Their method is not cost-effective. It's some costly, but for the performance and the overall customers who are using our APIs and what we're doing internally, we're happy with that. The organization is ready to bear that cost, but our only concern is they have to address our tasks. Whenever we seek their assistance they should address our task quickly. They should not insist to us that somebody from there will show up and do some due diligence. I think that is not required for all the customers because we feel that we're mature enough to tackle our own Mulesoft, whatever the day to day usage is concerned. We don't need their assistance anymore.
If we need them we will definitely put in some clear understanding that we need their assistance. But in future, we might only need assistance for Docker and Kubernetes because we're having some challenges over here. Or, in relation to security, we might need their assistance.
What do I think about the scalability of the solution?
It's highly scalable. It's a good technology. We have to increase and plan the capacity in advance. We have to execute our IP partly with other business because our business is very aggressive and very highly patent-oriented. To meet our business expectations, our IT stack has to be more efficient and more robust. We have to scale our business acumen in a very aggressive way. At this juncture, what we have to do is make our technologies or our applications more scalable and more persistent and continuously integrated. At this point of time, the features are being generously added. But there should give some flashpoints or something like that because the capacity has been missing.
I'm not sure whether we don't know how to configure those features or not. We're naïve about those features or maybe Mulesoft does not have them, but whenever we end up with this capacity, it has been going down, then we have to do a lot of due diligence and we have to do some capacity planning, which means we have to do some fibering, which has happened three to four times over a period of the last two years. We want to reduce that because it might impact our business. Because we have aggressive targets and loan book should be more, or I'll say we're expecting more from the customers.
At this point in time, our API stacks have been more supportive and more resilient. Mulesoft never gave any problem, but to scale up to this kind of capability, yes, we have to do some fibering but everything is going well, fortunately.
In terms of usage, I can say 1,000 to 2,000 users on day to day basis, because we have got a very big call center. They're not aware that they're using these APIs, but previously the APIs randomly show. I can say around 2,000 users are there. I'm talking about business users, not technical enrollment.
We want to scale up the user count, and want to increase our loan book on a regular basis. We're enhancing and emphasizing most on our digital capability so that a lot of customers who are entitled to and get to enroll as our customers, will be rendered loans. They will get paid online. Lots of things are new here. Innovations are being added and getting added in the near future. The customer base will also be increasing, so to make this happen, we have to scale our capabilities, and we have to meet our increasing customer base.
How are customer service and technical support?
I don't oversee the Mulesoft activities on a day-by-day because I work on the enterprise architecture security. We rarely go and focus on Mulesoft but whenever we ask them any questions, rather than addressing the question, they completely answer in such a way that they will do some due diligence. Somebody will show up at our premises, and they'll send some statement of work or something like that.
They want to turn every question into a business. I understand business is not a charity. But at least, being customer service, something you have to understand through the customer perspective, is that customers are expecting to do some due diligence and that you understand the customer complaint correctly, and then address their concerns. If there really is any business potential there, then you can address that.
Rather than jumping into the business wagon initially, they should understand the concern. They should understand the issue, and they try to address that, then if they really feel that there's business, or they have a business opportunity out there, they can capitalize that. Nobody is refusing that.
Rather than focusing on numbers, they should focus more on the customer support service.
Which solution did I use previously and why did I switch?
I don't think the company had a prior solution. Our IT stack has been matured from 2015 onwards. Gradually it's getting scaling up. In 2015 our company used to work on spreadsheets. IT stack was being set up in 2015. In 2016, we censored all our spreadsheets and all those things, and we brought Salesforce into our company so that all the call centers on the branch associates who disperse the loans, who grant and pursue the loans have been using that. Once the Salesforce has been established, gradually we found that API as one of the most innovative thing.
We brought APIs. First, initially we did some Java-enabled APIs, but we found that it was going to be consuming a lot of time and energy, so thought rather an API management product may be viable. We brought Mulesoft. I think somewhere around the beginning of 2017 we brought Mulesoft.
How was the initial setup?
Before joining the team, most of Mulesoft had already been initiated. But what I realized was that most of my colleagues and supervisors don't have the API experience. Secondly, even though they have the experience, Mulesoft gives a lot of tutorials on their website, but most of them are not self-explanatory. They insist that customers find a Mulesoft expert, mostly because they seek the assistance from the Mulesoft consulting group to come on board and do some due diligence, and then you will hear, "Somebody will come and install it." That is what they have been doing over a period of time. I think that this process is still continuing. I don't think that's been stopped.
So, we had a challenge with configuring initially when we installed Mulesoft, but you really have to understand the concepts of Mulesoft, and if you follow the regulatory and follow the manual if you have a little bit of experience, I think it's not a big deal. You can configure Mulesoft very efficiently.
In terms of the implementation strategy, initially, we were blindly following whatever the Mulesoft consultants said. They had been talking about creating your architecture, and this is what was involved in the deployment methodology. For almost one and one and a half year, we have been following them. Lately, we've changed the strategy, and we've customized our deployment strategy. We merged with Kubernetes, Jenkins, and we have JIRA inside our organization.
To make our customization comply with Docker and Kubernetes, it took some amount of time, but it consumes a bit amount of time to configure all these items within the Mulesoft and run it. It took around three to four months of time to complete this exercise because we struggled with the documents. They're not as explanatory as they should be. Also, whenever we tried to reach out the Mulesoft, they said that they would come out and they would do it, and they would do some consulting. But they would charge more. To avoid extra cost, we did our own exercise, and frankly speaking, the tutorials are not self-explanatory. The majority of this Docker and Kubernetes is not as mature as it should be when compared with Apigee. Apigee is very fast.
Going forward, we're going to migrate all of our applications to Azure. That has also hasn't been addressed yet. But the concern has already been raised. I don't know when they're going to address it. Yeah, these are the challenges. The tutorials, whatever they give, is not self-explanatory. It takes a lot of time to build any new initiative as far as Mulesoft is concerned.
We already have our full development center. The email team is there who've been supporting us. We have an internal workforce in there we've been doing. Along with me, there are two more architects who report to me. They do their job, and one dedicated Mulesoft integration architect, I can say the solution architect, but she supports the Mulesoft activities. The Mulesoft delivery manager is there. They're checking this challenge. They're accepting this challenge, and we're looking all those things.
What about the implementation team?
We had help with implementation by Mulesoft.
What was our ROI?
I cannot give you any figures because frankly speaking we never measured anything, but I can say that it has made a significant contribution.
What's my experience with pricing, setup cost, and licensing?
I'm unsure about licensing costs because I'm not the person who handles this. But, ballpark, it's probably somewhere around $300,000-$400,000 or something like that.
What other advice do I have?
There are a lot of products available on the market. Mulesoft is very good. It's an amazing product, no doubt about it. There's quality in the standard version, and the acumen and the technology are very good. What I want to tell them is before going for Mulesoft to consider Apigee. There are a couple of open-sources out there. What I would suggest is to not go blindly with the product stack. If you want to use the APIs, understanding of APIs are must because no company is independent. They have to do business with other companies. API is one of the most standard and robust methodologies to communicate with other business and do the business for the day to day transactions. And API is one of the most friendly approaches.
In this juncture, before going with an API management solution, understand whether you can create your own in-house APIs and see if you can leverage on that based on for the timelines and the costs. Then you can examine your goals because not every company is the same. Product due diligence is must especially when you do business with huge numbers of customers. For those kinds of numbers, you have to do an aggressive and some scale due diligence before going for the product.
My suggestion is to do due diligence and find the registered products, which are capable, and customizable for your requirements. Then you go with that product. As far as Mulesoft is concerned, yes, most of the small-scale and medium-scale customers, yes, it is one of the best tools. But when you scale up for large-scale customers, it has got those capabilities, but the Mulesoft team is not addressing those capabilities.
With Apigee, they address the concern and they go after a solution, and have a different approach, whereas, with Mulesoft, they insist the customers follow their methodology, which may or may not be suitable for all the lines of businesses. But when you come to the Apigee, they tailor to vendors, they customize themselves and act as the business owner, and they make for the business one of the best solutions. That's the difference.
However, I'm sure that what Apigee can do, Mulesoft can do better. But they have to address these concerns. To address these concerns, they should publish more articles, and the tutorials should be updated. The tutorials and the knowledge base should be updated thoroughly, and it should be made available for all the customers, as well as new learners.
Generally, they can make their product more sellable. It should not be hidden. I feel that is one of the challenges they have been facing, and they're not addressing that over a period of time.
I would rate this solution at 8 or 8.5 out of 10.
Which deployment model are you using for this solution?
Private Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Disclosure: I am a real user, and this review is based on my own experience and opinions.
