The “Ugly Duckling” API syndrome

As an advisor and a digital strategist, part of my role is to talk to customers about their APIs, IoTs, and their overall digital strategy. After conversations with a lot of them, one thing stands out: Almost everyone thinks their API is awesome. While a good portion of them are very impressive, and some are moderate to good, I do see a bunch of ugly ones too. However, if you are a producer — whether it is a movie, a baby, or an API – it will be hard for you to realize, admit, and come to terms with your “Ugly Ducklings.” Obviously, the amount of sweat and tears that went into your initiative causes you to look at your APIs through beer goggles, which makes them look good in your eyes, even if the APIs are mediocre.

Bringing your ideas to life in digital economy

Bringing your life-changing ideas to fruition needs a different mindset (and toolset) in the digital economy. The need for speed with digital innovation is more important than ever, with every start-up trying to push the envelope with their new ideas.

Remember the good old days, when you had an idea and tried to prove that concept by doing a POC (Proof of Concept)? While the POC technically stands for proving a concept, most times it is done as a proof of technology. We try to figure out a way to incorporate this newer idea into an existing IT infrastructure, often failing, and trying to make it work. I still remember the days in which we used to wait for the security admins to open the appropriate ports and give us the right access before we could even start to “install” our software to try things out. Those days are gone!

In the digital economy, once you get an idea, you cannot afford to sit around and build it for years, not even months, like legacy enterprise software.

Success of Data Insight–Driven Enterprises in Digital Economy

This article originally appeared on IBM Data Magazine.

Connecting everything to the Internet—the Internet of Everything—brings an interesting problem to the forefront: data onslaught. Examples of data onslaught in the new digital economy includes the 2.5 quintillion bytes of new data collected every single day (and it is expected to increase three times by 2017), or the 2.5 PB of data collected by a major retailer every hour or the fact that by 2015, 1 trillion devices are expected to be connected to the Internet and generate data for consumption.

A key point that almost every organization seems to miss in the data economy is that just because they are collecting so much data doesn’t mean they are collecting the right data, or even enough data. They may be either collecting very little of something very important or not collecting the right data at all. Even more appalling are situations in which organizations collect huge amounts of data and do absolutely nothing with it. People often make the mistake of connecting value with voluminous data.

Where are you spending your enterprise IT dollars?

This article originally appeared on LinkedIn Pulse.

In the last few years, the enterprise landscape has changed. While IoT “infestation” is a major reason for this change, there are other important reasons too. The need to provide flexible interface for your partners in a quick manner, the need to mobile enable not only any new application/process that is being built, but also existing applications, and the need for enterprises to connect/synergize with social networks, cloud, etc. all dictate where your shrinking enterprise IT dollars need to be spent.

IBM/SmartBear Webinar – Tomorrow (Jan 8, 2015) 11 am ET

IBM recently announced a two-way plug-in between IBM API Platform and SmartBear Ready!API API testing tool.  You can find more details about this at the following links:

1. Are you ready to liberate your APIs?
2. API Readiness with the IBM API Management Platform
3. SmartBear IBM APIM Plug-in

When your APIs are ready to be liberated, are you ready to free them?

Almost every enterprise that I know takes a very cautious approach to this new API game. They build it, test it, try it, do a limited release, then fix the necessary areas, test it again, and finally, when they are satisfied they are ready, they get it out in the open. Unlike fly-by-night operations, established businesses have a lot at stake when it comes to putting APIs out in the open. Their reputation! This is key before you can declare your APIs as business assets.

Going beyond the mobile app gold rush

Recently, I wrote a blog on “What powers the mobile economy?” which created lot of interesting conversations. A few large enterprise customers reached out to me and suggested they can relate to things I said in my post. In my follow-up conversations with them, a couple of more interesting views came up.

What powers the mobile economy?

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: https://pandawhale.com/]

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?

What are your “undocumented” APIs up to?

Do you know “Snappening”? It is a story about private Snapchat pictures turning from Casper, the friendly ghost, to a scary Halloween ghost. Recently, there was a second incident at Snapchat in which users had about 200,000 private pictures exposed (mostly pictures of under-aged users, aged from 13-17) online. Most had no knowledge of these photos being stored by anyone. Given the nature of some of those pictures (under aged/minor compromising pictures), these can be considered illegal to possess.

[Image courtesy: Casper’s Scare School]

[Snappening is a little different than the Fappening that occurred a few months ago in which female celebrities’ nude pictures were hacked from iCloud. In that case, the attack was targeted at specific celebrity accounts with a combination of brute force and phishing. Hence, the attack was limited to very few accounts and not massive scale like Snapchat.]

Is your API an asset or a liability?

This article was originally published on VentureBeat.

A touchy API topic is data ownership and liability, regardless of whether the APIs are open or protected. Obviously, depending on your business model and needs, you will choose to expose the APIs and the underlying assets to your developers, partners, public developers, your consumers, or others that I am forgetting. While almost everyone talks about the API business relationships, the liability concern brings the legal relationship to the forefront.

[Image courtsey: jasonlove.com]

APIs are considered a contract between the data supplier (or API provider) and the app provider. If you have different API providers that publish APIs from a central place, and multiple third parties use that API catalog to build apps for their consumers (end users), then it becomes complicated. While you can fix some of this by writing detailed contracts and making the app providers and end customers agree to the terms of usability before they use those APIs, as a provider, you are also responsible for implementing controls around your APIs to mitigate most, if not all, of the risks involved.