What is our primary use case?
We have an open banking initiative in Indonesia. We are mandated by a regulator's bank in Indonesia to open up our services to other institutions, not only banks, but also financial technology (FinTech) companies and startups as well as eCommerce or other industries.
Thereby, they can consume banking services through an API, such as our funds transfers, mobile banking services, or a bill payment, like electricity, water bills, college, and so on, through an API to their applications. It is not obligatory that you need to download our mobile banking in order to do these transactions, but you can do the transaction using other applications, such as the FinTech or eCommerce application that the customer currently has. Those use cases, for the open banking readiness for Indonesia, utilize webMethods API Gateway and standardized services of API for fund transfer, debit credit transfer, bill payments, and opening up a savings account using online applications. Those are pretty much the use cases for webMethods API Gateway in order for us to connect it with FinTech startups, eCommerce, and other institutions who would like to consume banking transactions through Mandiri.
Since we are a very highly regulated industry, which is a bank in Indonesia, we are not allowed to host any financial transaction outside of the Indonesian region. So, the solution must be deployed on-premise inside of our data center.
Are you using multiple products from this vendor?
We are using multiple products to build the end state of our service-oriented architecture (SOA). This is all orchestrated as a big building house. Those SOAs have many capabilities inside of them on the integration side, such as webMethods Integration Server. (Read my webMethods Integration Server review here.) There is also webMethods API Gateway and Software AG Apama. Those modules inside of Software AG complement the building blocks of SOA.
We also use it to complement other products in the markets outside Software AG, such as Kafka as well as all event processing and streaming. This is in combination with the capabilities (and beyond) of what Software AG stacks can do.
I find the native integrations between Software AG products to be very useful from a plain vanilla standpoint. Though, when we implement native integrations, there needs to be slight customizations to fit them into our core legacy system, and that needs to be integrated with other systems. For plain vanilla capabilities, it is sufficient enough.
The native integrations between Software AG products also have good performance in terms of transactions per second (TPS). These are acceptable in terms of the volume and speediness of a transaction that we can produce as well as being combined with the efficiency of using the hardware, memory, and CPUs.
If you combine the commodity hardware and performance as well as the plain vanilla capabilities of internal products that Software AG has, then there is a good price per value.
It gives you a one-stop service for your integrations area. You can really rely on one vendor, then you don't have to worry about sustainability or support. This is all guaranteed by Software AG as a single stop service from them. Whereas, when you need to combine other vendors, then you need to monitor each of their solutions, sustainability, product roadmaps, etc. Then, this becomes your technology liabilities, which is something that we consider. From the integration, we are selecting a good strategic partnership with one vendor in order to maximize our productivity. Thus, we don't have to worry how we can monitor each respective vendor if we do a best of breed combination of many vendors, just to do an integration.
By selecting Software AG and using multiple products, this saved us about 72 percent, which has definitely given us more agility.
Because we were already accustomed with webMethods Integration Server way before the webMethods API Gateway, they were almost the same. We just converted our knowledge from the prior WSDL into RESTful JSON standard messages. Therefore, the learning curve was very smooth because the environment that the developers use was still the same: My webMethods Console. It uses the IDEs coming from that, saving us a lot of time with the learning curve on new technologies.
How has it helped my organization?
Within the new version, webMethods API Gateway gives us an end-to-end lifecycle from the creation of the API up into the development, deployment, and promotion into production/live. The current end-to-end lifecycle of the API gives us enough authority and governance of the API. We know what are currently live services, what is in the testing stage of development, and what version that has been commissioned. So, the full life cycle itself gives us full authority and governance of the API.
You can carefully select what services can be consumed by the outside and what services can only be consumed internally. Also, you can see what the fallback scenario is, if some services are customized and what is the impact analysis, e.g., what is the impact to other services that depends on certain services that we are currently automizing. These are very critical capabilities for API implementation in any organization. You do need to have good API governance for it, not only tools, but also all the procedurals. You will need all the standard operating procedures for starting a development of API up to deployment into production.
webMethods API Gateway provides an engagement platform for managing hackathons. Our last hackathon was in 2019. We developed several services in the cloud using a sandbox environment, so it does not connect with our real life production environment. We created some accumulated transaction behavior, so hackathon developers could connect it with our box services within the sandbox environments. It does provide good freedom to host competition in an isolated environment.
At Mandiri, we divided webMethods API Gateway into two layers, the external API gateway and the internal API gateway. The external API gateway is for Mandiri channels and our core partner channel for feedback, eCommerce, and other institutions. With their channel, they like to connect and consume services. webMethods API Gateway gives you a sense of security and quite adequate minimum security to secure services, e.g., DDoS attacks, man-in-the-middle attacks, and queries for SQL injection. These are already built inside of webMethods API Gateway.
It has a good role definition and scope for its services. Expected channels can only access what type of services, and we can define those as per our contract with prospective partners. So, it boils down to the architecture: How do you like to architect the integration and partnering with other institutions? It depends on that. However, the system itself gives you that flexibility.
What is most valuable?
webMethods API Gateway gives us a set of rules and good security for securing outside work to connect with our services. It has good minimum security measurements built-in. However, webMethods API Gateway itself has very minimum API governance. You need to have a central site in place to have full-fledged governance, which is one of their modules.
The solution provides a fully customizable portal that has built-in testing and collaboration capabilities. Because it is similar with other well-known products in the market, the process doesn't have specific requirements. We do have a good adoption rate. We only have two weeks of learning and customizing the behavior to developers. By the third week, every developer can actually develop by themselves.
What needs improvement?
Previously, we had some difficulties with end-to-end lifecycle management of APIs because the product was not yet mature enough. Two years ago, it was not yet mature in terms of the capabilities, which were still separated and not yet consolidated. There were several modules of webMethods API Gateway which needed to be consolidated into one webMethods API Gateway. Previously, they had two separate modules for API management as well as others.
One of the improvements that need to be added into future releases is the ability to support other third-party monitoring tools. I know that they already support Jenkins, but in Mandiri. We use Bamboo for the deployment as well as part of Jenkins. We also install other monitoring tools, such as AppDynamics, for collecting information on performance and the problems of API Gateway hosting services.
With performance, there is room for improvement in regards to if we would like to put another extra layer of security on it, such as SSL. This is affecting their performance quite significantly. They need to improve the process of managing the SSL and other things inside their solutions, so there will not be quite such a significant impact to the performance.
With their API-Portal, you need to have flexibility when changing the layout and teams, giving more flexibility to rearrange and do some type of UX/UI that fits into your organization. The API-Portal that comes from Software AG has some of those limitations, with only certain parts that can be fully customized.
For how long have I used the solution?
We have used it for almost three years, since 2017.
What's my experience with pricing, setup cost, and licensing?
How do you get money from selling or offering your financial services to the other partners or institutions? It comes down to monetization. How do you monitor usage of certain particular protection or usage of services? I do see a lack of capabilities inside of the monetization area for them. They have a cloud infrastructure that is pay per use type of a thing. If you already use 1,000 transactions per se, then you can be charged and billed. I see room for improvement there for their side on that particular capability of the monetization.
Which other solutions did I evaluate?
We have evaluated other solutions, such as Apigee and MuleSoft, back in 2016. but since we already have Enterprise Service Bus that is using the integration server, which is collecting and managing all the integration services inside, we wanted to see the end-to-end picture of the service itself. It was very logical that you need to have end-to-end monitoring and trend deployment from the service deployment, up into exposing the external world using webMethods API Gateway. We see those advantages from using webMethods compared with other solutions, such as Apigee or MuleSoft, because of the continuation of the architecture. We would also like to expand those into our separating stacks.
What other advice do I have?
In every implementation of webMethods API Gateway, I strongly suggest that you need good API governance. webMethods has their API governance all built inside of your license. It is a continuation between the services using the webMethods Integration Server and webMethods API Gateway, exposing those services into the outside world. You need to have good governance for that.
I would rate this solution an eight (out of 10).
Which version of this solution are you currently using?
10.2 or 10.3