June 24th, 2013

Are APIs the New Toll Booths for the Information Superhighway?

APIs can turn Obama’s Open Data Mandate into city, state, and federal government Revenue.

As the recent Obama Open Data mandate is intended to increase federal government transparency, many agencies are forced to compliance yet have not been provided with additional funding.

The solution to this is tiered API plans and pricing that acts like toll roads for the data flowing out.

As a nation that derives most of its revenue from taxation of citizens and businesses, a new revenue stream can be created from placing tolls on the government data that flows on the information superhighway.

The data flowing out of the US Govt Federal Agencies, States, and Cities is a valuable bi-product of government operations. All of that government “big data” can provide businesses, US and International, with critical information about how to optimize and improve their products and services.  For example, the insurance industry can fine-tune their rates for health and auto insurance policies based on crime data, census data, and IRS data.

Just as drivers pay access to use better and faster roads, data consumers (businesses or citizens alike) will pay for access to use better and faster data resources.  The driver license is represented in the form of an API Key.

The maps we plan out our driving trips are similar to how data is represented through an API Explorer.  The road speed limit signs are represented through API Throttling and Rate Limiting. Will the government eventually launch a Department of API Access, that provides a similar function to a Department of Motor Vehicles?

The tollbooths on the information superhighway are API Gateways, and to pass through either one, the government can require good old-fashioned monetary currency for access.

June 6th, 2013

It’s Official… Layer 7 Joins CA Technologies

Layer 7 and CAThis week, CA Technologies officially closed its acquisition of Layer 7. As a Layer 7 co-founder, this represents the culmination of a decade’s worth of hard work. Equally important, it represents the opening of a new chapter for the company and an opportunity to amplify the vision we have been promoting.

Since our founding, we have preached the vision that enterprises can open their data and application assets programmatically in a secure way. When we started off, the primary driver for opening up was tighter business integration with partners. Today however, the demand for opening up data and application assets has exploded alongside the growth of mobile, cloud, Big Data and the Internet of Things (IoT).

The idea of organizations as walled-off castles is gone. Mobile is forcing organizations to deliver new business apps to customers and employees beyond the enterprise perimeter. Cloud is redefining how applications are consumed and delivered across a hybridized, extended organization. IoT will upend our notions of outside connectivity and data processing. APIs play a central role in making all this happen. Layer 7 gives customers the confidence to open up via APIs, without compromising security or operational integrity.

For us at Layer 7, security has always been a paramount consideration because our customers are enterprises and enterprises care about security. The CA Technologies acquisition reflects a common point of view on how to deliver new business value in mobility, cloud etc. while protecting the data and applications that are the lifeblood of a today’s enterprise.

CA and Layer 7 both appreciate that the old enterprise security perimeter is disappearing and that the only way to effectively enable online business while protecting information assets is to make identity the new perimeter. We need to focus on managing who gets access to what and what they can do with data once they have that access. Put another way, we need to focus on the identity, data and access that drives modern initiatives around Web, mobile, cloud, social and IoT. Together CA Technologies and Layer 7 Technologies offer enterprises the first truly multi-channel approach to enabling the business while securing its information assets.

Looking into the future, one clearly sees the scope for APIs will increase. IoT will make every formerly detached device connected – all through APIs. Where networking used to be about discrete routers and switches, it is now being transformed, via SDN, into something that is programmable and agile – again, this will be brought to you by APIs. And as for the server and storage infrastructure that underpins the data that drives the Web and mobile, Amazon Web Services has given us a glimpse of the future. As the “Web Services” part of that name suggests, APIs will play a significant role in provisioning in management of the cloud.

As we join CA Technologies, we now have the necessary reach and breadth to make Layer 7 the unassailable leader in the API security and management space. For customers, this means more of what they liked plus the ability to accelerate delivery of our original vision. We’re here to help organizations open up via APIs. And we’re open for business.

March 22nd, 2013

Enterprise Mobility & BYOD – Live Interactive Q&A

BYOD Tech TalkCalling all Enterprise Architects, Application Architects and Senior Developers! For our next API Tech Talk, we’ll be discussing Enterprise Mobility & BYOD live on March 26 at 9am PST. My special guests will be Layer 7 VP of Client Services Matt McLarty and Product Manager for Mobile Leif Bildoy.

The BYOD movement seems to be changing the hardware landscape permanently and it’s showing no signs of slowing down. Naturally, this presents both opportunities and challenges. Security managers within the enterprise have less control then ever. “Anywhere access” has blurred the lines of what used to be called the corporate network perimeter.

So what are CIOs and CTOs specifically worried about with BYOD? Well for one, mobile devices can easily go missing while containing sensitive data and employers often cannot even assess the impact of data security breaches from compromised devices. But locking down employees’ personal devices is generally not an option.

So how can enterprises re-assert control over their data assets while still allowing employees to use their own smartphones as they choose? We’ll be discussing this and other questions during out live, interactive Q&A. So, be sure to clear your calendar and join in the discussion on March 26 at 9am PST.

Here’s How to Join the Discussion
Make sure you click Add to Calendar to get the event details and a reminder in your calendar. Then, on the day of the event, click here to join:

To ask questions, you can:

March 8th, 2013

Nation Building in the Age of APIs

I’ve been working with a number of companies lately on their API strategies.  People seem to recognize that having an API is modern day necessity, but they’re not sure how to get started.  Since APIs are viewed as a technical innovations, responsibility for rolling them out is frequently handed to IT groups.

Clearly, there is business value to be attained by companies who utilize an API, and an accessible web API is a requirement for modern corporations.  For companies looking to launch an API, there is a temptation to focus on the technological aspects of implementation.  Good API design, architecture, and infrastructure are vital to the success of a company’s API, but there are other areas to address first.  I am currently reading the book “Why Nations Fail”, and recently read “Thinking Fast and Slow” by Daniel Kahneman.  Although the former is a geopolitical study whereas the latter focuses on the human mind, both share an identical observation that is the foundation of their arguments: a great amount of economic study is flawed because it fails to account for human behavior and tendencies.  I feel the same way about technology.

Every paradigm shift in technology has been driven by both innovation—the new technology itself—and application—how that technology can be used.  In other words, there is a machine side and a people side to every technology change.  The technologists responsible for implementing these changes often bias towards their comfort zone—the machine side—and overlook the people side.  This has led to frustration for companies who invest significantly in new technology only to miss the intended benefits of the change.  For APIs, the people side of the change is especially important.  In fact, the social nature of the API world means there are even more groups of people to consider.  Ultimately, the success of a company’s API will depend on the creation of a diverse community for that API—end users, partners, developers, and more—as well as the adoption of a business model that allows the API to contribute to the company’s bottom line.  Taking the community and the economics together, this means you will need to build a nation for your API.

Some of the biggest companies on the web have taken this approach with their APIs, and I recently explored some of their winning tactics in this VentureBeat article.  Please have a read and let me know your thoughts, and perhaps your own API lessons

January 25th, 2013

Considerations for Private APIs

Written by
 

Considerations for Private APIsIn the past, we’ve talked about the nature of private APIs (those interfaces that are built primarily to serve an organization’s own projects rather than to fulfill the needs of others).  But what are the specific challenges and architectural decisions that need to be made when implementing a private API?

First and foremost, an API can’t be considered private if it is open for widespread public use, right?  A simple way of keeping an API private is to host the interface on a public network without explicitly advertising or documenting its existence.  This can work well initially but may lead to problems in the future. If your service is valuable enough that others want to get their hands on it, even an undocumented, unsupported, private API can easily end up becoming a depended-upon API for application developers, resulting in an outcry when the API publisher has the audacity to modify or retire its own service.

A better approach is to provide access control at run-time and restrict usage of your API to a few known parties. There are a great number of methods for protecting access to internal resources but the best ones are those that achieve a balance between ease of implementation and resistance to infiltration. Security at all costs can greatly increase the complexity of an interface and – in turn – the time required to complete the projects that depend on it. Instead, we need to implement access control that is practical. Thankfully, security protocols like SSL, HTTP Basic authentication and OAuth 2 are great for providing the basic level of access control needed to make it difficult for outsiders to use a private API. Bear in mind that there is much more to API security than simply validating identity but this is the minimum level needed to ensure a degree of privacy.

Although a private API’s developers are generally known to the publisher, the best private APIs utilize API portal components to provide self-service registrations and integration to their private developer communities. This can greatly reduce the friction involved in getting API integration-based projects started and reduce the overall project costs for B2B and mobile-based initiatives. In fact, many of the lessons of simplified design, documentation and administration learned from the public API world can be directly applied to private API management. While the ultimate goal may be different (driving efficient API usage for private APIs rather than far-reaching adoption of open APIs), the ways of getting there are largely the same.

A unique characteristic of private APIs is the need to manage groups of developers. Unlike the public API space, private API publishers will often define out of band contract terms before offering up a quick self-service integration mechanism for that team. This type of group-based role definition is particularly common in integration projects that occur between organizations and can stretch the limits of API portal software that has been built primarily for open API use. Ideally, an API portal should at least be capable of managing developers within groups, communities or organizational affiliations as part of the self-service registration process. Even better, the portal could  provide capabilities for managing whole communities as separate domains within the same infrastructure.

Designing a private API certainly requires a different perspective but the good news is that much of the knowledge around public API design can be directly applied to interfaces you want to keep secret. Of course, building the management and security capabilities required to expose the API to your trusted parties can be daunting but that is why a great API management portal and gateway combination can save the day.