Recently, my colleague Claus wrote a blog on whether you need API management if you already have a decent mobile initiative. The topic was so good that I thought I would pile on and provide my opinion on it as well.

One of the points he established was that if you are deploying very few mobile apps on a few selected devices, for one or two LOBs (Line of Business or Business Units), then it is a wash. You might do better without having an API initiative. I completely agree. Problems begin to pile up when you have multiple mobile apps and want to have a common baseline across them.

[Image Courtesy:]

Multiple silos of Mobile initiatives

A major issue that I keep hearing from many executives is the proliferation of mobile initiatives with or without IT approval and/or oversight. Unfortunately, given the excitement, need and necessity to produce mobile apps quickly, the IT departments can’t cope with the demand from LOBs. There are times mobile initiatives are run by LOBs, in parallel, without the knowledge and oversight of IT. Unfortunately, most of these haphazardly-built apps access your enterprise data without proper controls. This is when your mobile apps (and APIs) become liabilities instead of assets. Read my article on this topic here: Is your API an asset or a liability?

If you continue to let these multiple, stealth initiatives access your enterprise data directly, the transactions may not be recorded in any of your enterprise controls – your security, SIEM, logs, analytics, Insight dashboards, etc. will all be bypassed. Unfortunately, not only will you not be aware of any vulnerabilities, but also you will not be able to respond quickly to any incidents. If you waste too much time for an incident response, the issue will get bigger and eventually will become uncontrollable.

By providing an API for those initiatives to use, you not only enabled them to access the backend systems/ data through your APIs, but also you can control the traffic via those APIs. If in case there is an incident you will be able to get an alert instantly and be able to respond to it quickly.

Mobile App rejection

Let us face it. In spite of our thinking that we can build cool, jazzy, snappy mobile applications the reality is that it is the users who decide if your app is good enough. Given the proliferation of mobile application in any given subject, it is a high possibility that your user base may not like your app. When such rejection happens, you probably will be tasked to build a newer app to replace the old failed one. If you don’t have a baseline (or a reference point) then you need to build the entire application from end-to-end. This means you will take the same amount of time you took earlier, or longer, to build the new app. In the mobile app market, time to market is very critical. Your users are not going to wait another 6 months to a year for you to build a new app and deploy. They would have moved on.

If you have a well-defined API on which you have to build the newer app(s), then the time to market is much quicker as there is a baseline from where you will start. In other words, your application is already half-finished and waiting for you to finish the rest. Not only will the mobile app readiness time is cut short, but your newer apps that are being built will have the same exact enterprise level controls around it, as it is consistently enforced at the API level for all mobile apps across the board. When the foundation is strong, so will be the house that is built on it 🙂

Controlled Innovation

Almost every enterprise I speak to is starving for innovation. They are eager to understand what others are doing, but they are afraid to open up the kimonos, especially given the sensitive nature of their data and the liability issues that are associated with it. When I tell them by exposing APIs they can have innovative developers go at it to come up with creative apps yet they can control the entry point into their enterprise, they all love it.

This concept of “Controlled Innovation” is gaining adoption in almost every industry, especially in the highly regulated industries such as healthcare, energy, banking, etc. There are solutions out there to create virtual APIs (such as Ready!API by SmartBear), which can be handed over to the third party developers, instead of them building something on real APIs. This will allow you to continuously innovate, yet completely control the innovation process.

We at IBM provide tools to build a solid API foundation for your mobile apps. Reach out to me on Twitter @AndyThurai or to find out more.