The role of the business developer has traditionally been to initiate partnerships and follow through by ensuring some sort of integration is implemented.  As enterprises become more software-driven, integration itself increasingly comes through APIs.  This may mean that the implementation of API-driven “partner portals” is replacing traditional business development practices.  A recent article from Wired claimed that 70% of all jobs will be replaced by robots by the end of this century. Are APIs and partner portals the robots that will replace manual business development processes?

Here’s an example of how a business partnership might come about these days. Interaction with an online API partner portal will act as the initial “conversation” that leads to the partnership. If you want to integrate with Salesforce.com, you go to the Salesforce partner portal, figure out the relevant SDK/API, build an app and then submit it to the Salesforce AppExchange.  You don’t ever need to actually talk with anyone at Salesforce to become a business partner with the company.

Another example is the way many companies now enable access to their Web sites via Facebook Connect, Google+ Login or Twitter Login. This represents the first step towards establishing a business partnership with Facebook, Google or Twitter. It’s not new in the Web world and has been discussed for years. What makes it relevant to this discussion is the way it’s being applied to out-dated business processes and practices.

Great platform companies have realized this, “robotized” their business development processes and rationalized their business development teams. As robots are to manufacturing, APIs are to business development. Better technology means that we can focus our human resources on more valuable activities, since handshakes are now being made over OAuth instead of costly dinners and drinks.

In case you haven’t heard, we are living in the age of mobile applications and the APIs that power them. Sometimes it’s called the API economy.

Smart phones are ubiquitous, social networks are the norm and we are connected to applications on our devices all the time. We love applications like Instagram, Twitter, Evertnote and Snapchat. But we don’t like signing in and out of each of these applications across networks or devices. It’s awkward and cumbersome and we’re often doing it while on the go or commuting, with only one hand to use while tapping in our passwords. Besides, who wants to remember all those passwords anyway? And it’s not safe to use the same one for every application.

This is the major downside of using all these great new mobile applications. Most of us would gladly invite a scenario where we’d only need to log in once to access multiple applications. There’s social login – but is it safe and is our privacy secure? Remember what happened to Burger King’s Twitter account? Enter Single-Sign-On & OAuth for Mobile Applications.

On Tuesday Feb 26, we’ll be hosting a live interactive Tech Talk on security and Single Sign-On (SSO) for mobile applications. And I’m excited to welcome back Layer 7′s Chief Architect and resident OAuth expert Francois Lascelles. He’ll discuss how to provide SSO for mobile applications, without compromising the security of the apps or the APIs that power them. Francois will also be taking your questions throughout the Tech Talk. So, this will be a great opportunity to get answers to your questions about your own applications and the security that surrounds them.

Click here to get the event details and a reminder in your calendar.

On the day of the event, click here to join:

•   layer7.com/live

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com
• Post a message on Facebook

Today’s lead article on Ars Technica talks about the importance of protecting backend resources in the context of mobile applications. The article rightly stresses the importance of this security, talks about the uptake in OAuth and cites API Gateway solutions as a popular option in this space.

However, the article clearly misstates the capabilities of an API Management solution founded on an API Gateway. I am going to assume that the author only had exposure to API Gateways second hand or through a competitor of Layer 7. Here are the misconceptions propagated by the article, along with some corrections:

“These API gateway services can be prohibitively expensive for small-scale applications…  ‘You can replicate the API gateway by creating a set of proxy services in their data center in an application container in their DMZ.’”

Trying to create your own homegrown set of proxy services is expensive and risky. The Layer 7 API Management Suite’s Gateway technology includes 10 years of functional enrichment and optimization. Such robustness cannot be hacked together on the fly.

“An API gateway still runs on the notion that you have to be careful not to block what might be legitimate traffic. So that could cause some openness – some attacks might slip through using Web application firewall evasion techniques.”

An API Gateway is not a typical web application firewall. Layer 7’s Gateway (evident in the company’s name) has full access to all layers of the data stream and can apply protections at any of these layers.

“Of course, if they can retrieve a developer key, attackers can slip past API gateways until their activity is noticed…  That’s why it’s important to encrypt any data stored on the device, including developer keys[.]”

API keys are not treated as security tokens by an API Gateway. The term “API key” is equivalent to a “database key”, not a security key, so don’t mistake it for a robust access control mechanism. It is mainly an identification mechanism. It is a gross misunderstanding to equate API developer keys with a standard access control cryptographic mechanism like PKI public/private keys.

“But keys have other ways of getting into the wild besides breaking into the application code.”

Right, so you should not rely on these keys for access control. The good news is that the API Management Suite’s Portal/Gateway combination makes it easier to revoke and reissue developer keys.

“For enterprise applications, an API gateway isn’t always enough – users need to get access to content on servers inside the firewall that may not be easily exposed through a Web API.”

And this is where the API Gateway really adds value. The Layer 7 API Management Suite allows companies to turn those backend interfaces from their native protocols into REST APIs or other formats that are friendly to mobile devices.

So, thanks to Ars Technica for flagging up this important aspect of mobile security and here’s hoping that this corrected information is included in the next article.

With February just beginning, the mobile world is gearing up for Mobile World Congress (MWC), which will be taking place in Barcelona, at the end of the month. It’ll certainly be interesting to see what new products and features will be announced at the show. From the ongoing trends (some of which Mike Amundsen recently discussed), I’d expect to see a number of announcements of IoT products.

The good old measure of progress, mobile subscriber penetration, doesn’t cut it anymore. Now, the real measure is how many other connected devices a subscriber uses – iPads, Smart TVs and even fridges (who wouldn’t want a Galaxy Kitchen or an iPad Mini?) This is just the start of a revolution in connectivity, which will make it easier than ever to consume information and equally easy to emit a lot of information, often through social networks.

But there is another aspect to this – not only will you be able to post your own information but there will be all kinds of devices that can “sense” information about you. I expect to see a lot of this at MWC – sensors and cameras scattered around the floor, mapping passers-by to Facebook profiles and other personal information. Obviously, the capturing and cross pollination of this information raises all sorts of privacy issues.

It will also have a number of significant ramifications for mobile developers. First, there will be a new wealth of information available in the form of Web service APIs, as most of the data will be stored in cloud. The sheer scale of this new information-rich world will require apps to leverage cloud processing capabilities in order to be truly effective. This will create opportunities for enterprises to rethink their mobile architectures.

Second, mobile developers will need to use standard protocols for authentication and authorization. OAuth and OpenID Connect are key standards for protecting resources and allowing app users to authorize apps to leverage their information. Will these standards address all the privacy issues mentioned above? Probably not but they will make it a good deal easier for app developers to comply with privacy laws and regulations.

Third, the most successful app developers will be those that are able to provide a seamless user experience (UX) across multiple devices. This is because the end user of the near future will naturally expect all apps to know about other sessions that user had with an app across all of his or her many smart devices. Devs will therefore want to migrate sessions across devices, to bolster the UX.

If you’re going to MWC, come and say hello to the Layer 7 team. We will be located in the App Planet area Hall: 8.1 Booth: A47. I hope to see you there!

Looking ahead, here are four tech-related trends that I think will shape the coming year. These are trends I noticed were already in flight during late 2012. I believe they will continue to affect the way we design and implement solutions in 2013.

As you’ll see, all of my predictions are driven by the relentless increase of connected mobile devices. This is the dominating overall trend that will continue to affect all aspects of information systems.

In a nutshell, I predict:

• Individual service deployments on the Web will get smaller and more numerous
• Mobile client deployment will be a bottleneck
• Server mash-ups will increase but client mash-ups will decline
• The demand for seamless switching between personal devices will increase

Services on the Web Get Smaller, More Numerous
Influenced by the existence of the many mobile apps running on a single device, Web-based services will become small, single-focused offerings that (in the words of Doug Mcllroy) “do one thing and do it well.” This will also explode the number of available services. The advantage of this trend will be an increase in the agility and evolvability of service offerings. The challenge will be an increased need for governance at the “micro-service” level.

Mobile Client Deployment Becomes a Bottleneck
As more services appear on the Web and more mobile devices spread throughout the world, keeping up with mobile app deployment will become more difficult and more costly. This is especially true for cases where an app store requires approval before release. To mitigate this problem, developers and architects will look for new ways to update and modify the functionality of already-installed mobile apps without the need for full-on redeployment. Solutions will include use of in-message hypermedia designs, reliance on remote discovery documents and just-in-time plug-in style implementations.

Server-Side Mash-Ups Increase while Client-Side Mash-Ups Decline
The increasing popularity of languages like Node.js, Erlang and Closure will make implementing server-side mash-ups more efficient and easier to maintain than doing the same work within a client application; especially for the mobile platform. This will reduce the “chattiness” of client-side applications and increase the security and flexibility of server-side implementations. The result will be a perceived increase in responsiveness and a reduced use of battery power on mobile apps.

Multiple Device Form Factors Will Demand Seamless Sharing
As more users access content on multiple devices, there will be an increased need to design apps that seamlessly share user data across these devices. This will affect the both client- and server-side implementation details. Identity will need to cross devices easily and content syncing will need to be seamless and automatic. App builders will rely more on the “responsive design” pattern in order to automatically adjust displays and functionality to meet the needs of the current form factor. Servers will need to be “context-aware” and provide the most up-to-date content while users switch from one device to the next.

Finally, whether my predictions are spot on or way off, I look forward to a very interesting and challenging 2013.