Magic Quadrant for Full Life Cycle API Management (2018)

The latest magic quadrant for Full Life Cycle API Management has been released a month ago. I just received a mailer from CA. 

Well done, CA Technologies remains in the Leaders quadrant. Not sure why Google (Apigee) is so high up, as we don't see much competition from them in this region. As long as you are totally cloud-based in this region, especially Singapore, you're basically out of the game. I'm saying if you are looking for large customers. The game is still very much on-premise.

Interestingly, Tyk has made it to the Niche Players quadrant. That's real hard work for a new player who has been in this market for less than 5 years. Really impressive! Kudo to the Tyk team!


.

What API is not about and about?

My team has been covering a potential customer for a while with regard to a API Gateway deployment. POC done. Presentation done. Then a competitor came in to disrupt ... it's common. Singapore is a saturated market. There are finite number of customers to chase after. If customers don't come to you and you hear that they are looking at a product from your competitor, you quickly go in to disrupt the market. 

If you are the product principal and you have the time and energy and you have a willing partner, then you will do this sort of things. I'm someone that is not too keen to do this. The pie is always big enough for everyone, that's my view. If you go in to disrupt the market, you're usually going into a price war. It's not about product superiority anymore. More importantly, the quality of the consultants are not considered.  

This is a vicious cycle. Nothing good will come out of it. Customers think they are getting a good deal. I say they are mostly blind. Partners/Vendors are not stupid either. If a partner bids with a superbly low price, you think the partner will give you his best consultants? You pay peanuts, you get monkeys. As simple as that. 

Anyway, I went in to make my last presentation. I only showed 2 slides. 

API is really not about Secure File Transfer, Security, Throttling and Message Queues. These are given. If a gateway has no such features, they will never get a chance into the board room in customers' place. 

Honestly, 80-90% of the API products out there in the market have similar features. All are equally good. Why? For most customers (80%), they only use a subset of features (20%). I can confidently say most API products meet the requirements of most customers. 

API is really about People - Customer & Vendor. 

I know that the competitor is partnering with a SI that does mostly systems related work - PAM, Secured File Transfer. 

In our experience, these type of people are only used 20% of the total time spent in a typical API projects. They are utilized during the Build phase and the Maintenance/Patching phase. In Build phase especially, my own experience told me that my API Consultants are of no use here. They simply do not understand networking, firewall, zoning, routing, high-availability, scaling, hardening, vulnerability assessment, security scanning. This is where a trained Systems Consultant is useful. They will be able to work with the Network Security team from the Customers' sides effectively. 

But as soon as the Build phase is over, the Systems Consultants become totally "useless". This is where API Consultants come in. They are there to help Customers with "Discover, Simplify, Transform, Add Values". In short, to provide API Design services. This usually takes up 80% of the total time spent in typical API projects.

API is all about proper thought process. It's not a simple "Oh, let's create a new API and map it 1-to-1 with your backend service". An intern will do! Why spend so much money?

.

APIs Design, Development & Management

I have forgotten where I have captured this diagram, but it really reflects the truth on the ground.

90% of APIs rely on developers to code! Of which, 60% rely on developers to create and manage their own APIs. Only a tiny 23% did developers use a proper API Management tool to create and manage their APIs.

There is still a big market for API Management tools.  :)


.

API Slug

 I was playing with Tyk since they are offering 50.000 API calls / day FOC. What can you ask for?


While creating a test API, I came across a term "API Slug". What's that?

API IDs are internally unique but hard to remember. These are not useful for users, so you can replace them with a slug.

I find this developer friendly, as opposed to GUID as shown below.

Tyk was built because other open source API Gateways in the market come with dependencies and bloat, attempting to be too many things to too many people. Tyk is focused, simple and does one thing well - protecting your API from unauthorised access.

Another open source product ... let's see how long they will stay being open source.

These days, I make it a habit to fork frequently. You never know when the source will be closed.

When $ comes and put on your table, let's see whether or not you'll stay true to yourself - the original dream of building a whole-class open source product for the open source community.

We are all human beings.



.

Should we allow modification of EULA?

In CA API Developer Portal, when an API consumer wants to subscribe to a published API, he/she has to accept the EULA (End-User License Agreement). I believe this is the same for all other products out there.

So a customer of mine asked me the other day why he is not able to edit the default EULA that comes with the portal installation. Note: these are random texts (as shown below) and customer wants to go-live, thus he needs to modify the EULA proper.

He also created a new EULA and tried to change the default EULA to this new one. But he was not allowed to do so.

Bug with the product? No.

We found out that he has already created applications and assigned some APIs to these applications. Now, when a consumer adds an API to his/her application, he will be prompted to accept the Terms and Conditions as stipulated in the EULA.

Once accepted, from an audit point of view, this particular EULA shall not be changed by another party. As such, CA API Developer Portal implements this "disabled" function.

I think this is a great feature. It covers the benefits of both parties - API Publishers and API Consumers.

I have seen other software vendor asking customers to sign a paper-form EULA. But within the EULA, it points to a hyperlink with more terms and conditions. In one case, a contract was signed in year 2016. In Sep 2017, customer went to the site and realized the terms and conditions had been updated (latest modified date was May 2017) without notice.

This is bad practice!


.

API Design & Implementation Tips

I was attending CA Partner Momentum held in Singapore this week. We had John flying in from Australia to conduct the event for us.

Some tips from John which I think are useful for field staff like us.

1. Recommend agile approach 
2. Collaborate with customer - get 1 dedicated person from customer's side to work 
3. Minimum viable product 
4. Select a simple API 
5. Generate test case first (POSTman) 
6. Use Gateway to emulate backend 
7. Share test cases with client as early as possible 
8. Show progress against test cases 
9. It's ok for customer to change their mind (embrace change - but ask for something in return) 
10. Leverage API Academy for questions around strategy

.

What is Serverless APIs?

Yet another buzz word - Serverless, when it actually means Cloud Platform / PaSS. 

- No servers to provision or manage

- Scales with usage

- Never pay for idle

- Availability and fault tolerance built in

With it, comes yet another term ... Serveless APIs.


.

APIs vs Microservices

I talked about the new trend in API - Microgateway and the often used buzzword "Microservices".

This slide says it all ... courtesy of Matt McLarty from API Academy. #APIWorld17

.

2FA API

One Identity recently launched Starling Two Factor Authentication, a SaaS-based solution.

It solves the password problem without the capital costs or increased infrastructure management that you might incur with traditional on-premises solutions. With an easy to use dashboard for administrators and flexible authentication options for end users, Starling Two-Factor Authentication enables organizations to quickly and easily verify a user’s identity.

Starling Two Factor Authentication is actually based on Authy.

The nice thing about Authy is that it provides REST APIs which is useful for application integration which requires 2-Factor authentication. e.g OneTouch API, Phone Verification API. 

Cool stuff!

.

More APIs integration with IRAS (Singapore Taxman)

I blogged about More and more APIs exposed by Ministries. Yesterday, I read about Taxman calls on Grab, Uber drivers from Straits Times.

Dodging the taxman will become more difficult in the gig economy, as going cashless allows for better electronic tracking of payments. And the taxman has his sights next on Uber and Grab drivers.

An Iras spokesman said: "To simplify tax filing and ease compliance for our taxpayers, Iras continually seeks ways to explore initiatives with third parties and platform providers to automate the transmission of income information directly into our tax systems."

What's the end state?

Definitely a gateway (Grab/Uber) with gateway (IRAS) integration with Grab/Uber automatically submitting drivers' earnings directly to IRAS - same as the one we are implementing right now for an Insurance agency in Singapore.

.

Client Credential Grant Type and Refresh Token

I was in a discussion with a customer today and we talked about how to reduce the number of calls to Kong API Gateway.

This particular API Gateway is only for internal applications communication, thus Client Credential Grant is configured on each endpoint.

The main concern was that prior to each endpoint call, the internal applications have to make a call to request for a OAuth2 access token. This will be 2 calls to the Kong API Gateway per endpoint.

But, hey, if this is a setup of internal applications communication, we can increase the access token timeout. And it is programming best practice to reuse established access token, rather than to get a new access token prior to each endpoint call.

There's a choice.

The APIs are not exposed to the public. If the application teams within the same company cannot cooperate with one another, there's nothing we can do about it.


The customer continued to probe further: "Can't we ask the application team to use the OAuth2 refresh token to exchange for a new OAuth2 access token?"

But... this is Client Credential Grant type. There's no refresh token generated.

Refresh tokens are only provided when retrieving a token using the Authorization Code or User Credentials grant types.


.

Stock Trading RESTfully

IG Group is a UK-based company providing trading in financial derivatives such as contracts for difference and financial spread betting and, as of 2014, stockbroking to retail traders.

I just came across their trading platform and discovered that they have "API-exposed" their trading system via IG Labs.

This is cool for experienced traders who want to apply their own trading algorithm before they make a trade (either open or close) for automated trading. 

I am seeing this as a trend moving forward...

I searched the local trading securities in Singapore. I think most have just poured their champagne by delivering their Mobile trading platform. 

None has exposed their trading platform as APIs yet. But surely the day will come... just a matter of time!

.

API Development - Not Engaging Early Enough

I was reading a blog from Nordic APIs - 5 Frequent Developer Community Mistakes (And How to Fix Them).

I could relate quite closely to one of the mistakes - Not Engaging Early Enough.

Many of us make this mistake frequently. We thought we have a great API to launch, but we actually do not really know what the market is looking for!

A new development process is suggested:

• Idea : Generate initial tech design documents. 
• Think: Add some context to those documents, make them more digestible, explain motivation, come up with NDAs. 
• Explore: Send to a small subset of developers for feedback. 

THEN

• Build
• Launch
• Tweak

Great reminder!

.

More and more APIs exposed by Ministries

The trend is pretty clear these days - ministries in Singapore are encouraged to expose more and more APIs for external entities to consume, in particular organizations/companies.

This will save huge amount of human hours if manual tasks like Form Submissions can be automated. Yes, we have a labour crunch here in Singapore. We do not have enough local people in our workforce. Thus automation is key going forward!


My team is currently designing APIs for one of the financial institutions in Singapore. This week, we have a new request to integrate with Inland Revenue Authority of Singapore (IRAS) for Commission Income Information Submission.

The current process of submission is very manual.

It requires a person to download a program (Offline Validation Program - OVP) from IRAS to validate a XML/Excel file. Once validated, one has to log in via SingPass (Singapore Personal Access) and then manually upload the XML/Excel file to IRAS portal.

The new API service allows applications to directly submit Commission Income Information to IRAS , thus eliminating the need to download and validate using OVP and login to IRAS portal for submission.


.

Exposing APIs in the Financial Services

I met up with a number of financial institutions over the past few months. You know these are established companies with long history and their IT infrastructure is strong and big.

Out of 10, 9 of them will have SOA (Service Oriented Architecture) in place. Then they'll have ESB (Enterprise Service Bus) solution to support their SOA initiatives. Web services are everywhere. Integration with internal and external parties are also common.

Why would they need a API Management then? Below are some of my slides:

Security, Sandboxing and Scalability is my most-used tagline.

Yes, they could have deployed their own DIY solutions, as the concept of API Management is not something new. Honestly, if your team is highly technical and security-conscious, there is really no need to buy a ready-built APIM product out there.

It's a matter of time to market and where you want to spend your time in.

Do you want to spend most of your time in your core business? Or do you want to split your precious time in managing the security risks and scalability issues when your APIs are exposed?

It's a choice - $ vs Time.


Below is a statistics showing the target audience of exposed APIs in the Financial Services:

The goals of deploying a APIM solution in the Financial Services section as illustrated below:

Interesting.