Akana Platform Free Trial

Get Started Today »

Roberto Medrano

With the massive migration to the mobile platform, increasingly widening net of social media, and the blooming use of the cloud by most businesses, it can be tempting to think that enterprise API development and management will herald a whole new set of rules for the companies of today and tomorrow. The potentially dynamic universes they are capable of creating for your business to span, although much more capable than the programming code lock-and-key days of yesteryear, still have many of the same – or similar – considerations that you will have to mull over and decide upon for their potential effectiveness (or detriment!). Will you be like tech giant Sony, and keep the API for your uber-popular gaming console under wraps; or will you opt for the generous transparency of Apple; a position that has both benefits and potential detriments.

The ubiquity of Internet-based applications such as games and other interactive platforms makes it an ideal forum for enterprise API management, if you so desire. Certainly, market forces are conspiring to drive more and more businesses to use this to their advantage, and expectations are such that this will continue and become standard. It could be hard to compete, for example, with another company’s robust social media presence, where the people in their network (LinkedIn, Facebook, etc.) can not only access company games and conference photos, but can modify them and add relevant stuff of their own, creating a community in the truest sense. There is little doubt that APIs that allow this have a net effect of extending the reach of the business in question, even though the proper designation for them would be consumer APIs and not enterprise APIs.

If net-wide sharing is just a little too liberal for your enterprise API management plans, then a more restrictive approach could be making the code available to a tighter community of developers. Indeed; enterprise APIs are usually inherently inaccessible to non-programmers in general anyway, given the specialized object-oriented programming used. Even if locked away in the cloud, and made available selectively to other programmers, security must still be at the forefront of any concerns; outside developers shouldn’t have access to APIs that might expose confidential information, for instance. Not being selective enough could spell future lawsuits if permitted developers accidentally or knowingly violate compliance mandates, or enable breaches in the programming architecture.

Given all these possibilities and avenues for extending the reach of your enterprise API management; the foremost concern after establishing the route you’d like to take, is security. It is the only good reason that any capable company isn’t employing web-based APIs to take advantage of the social media revolution and the burgeoning mobile marketing platform. You’ve got to have in place security measures to catch system breaches, noncompliant use, and other compromises that have a negative financial effect. While throttling is a standard measure taken to slow down and regulate traffic, it can also be used effectively by and enterprise API to fend off attacks on its architecture, since many of them could be Denial-of-Service or other, more currently popular tactics. More pertinently, security throttling will help make sure your servers don’t crash due to traffic congestion.

In short, the type of enterprise API management you will undertake depends entirely on your goals and your recognition of the steps it takes to reach them. You can “keep it close to the chest” by situating it onsite in a physical location, or put it out there on the cloud for all – or almost all – to see.

Share Button

Add a comment