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.

While several start-ups have demonstrated the potential of tapping the long-tail developer community (look at examples like Twillio, Tapjoy, Stripe and Braintree) the number of enterprises that have seen similar success is less clear (Amazon Web Services is an obvious counterpoint).

One reason for this is simple – enterprises have conflicting interests and are almost never set up to successfully service these communities at all costs. This doesn’t negate the value of fostering relations with the long tail. External developer programs make sense for enterprises and should be viewed as strategic, even if the immediate payback is not obvious. With the advent of the app economy, developers represent as important a channel to market as traditional distributors.

However, often overlooked in the race to launch an external API developer program is the potential benefit of an internal API developer program. Enterprises have, in many cases, thousands if not tens of thousands of developers internally. Often, internal developers are supplemented by contractors. Enabling all these developers to become mobile innovators through APIs holds out the promise of delivering the kinds of leaps in productivity, agility and experimentation that will benefit any enterprise.

To make internal developers innovation leaders, it is essential to provide a canonical way for these developers to access all corporate application and data resources. An API abstraction layer delivered through an ESB or API Gateway simplifies the process of API-ifying information resources and consuming APIs.

But that’s not enough because developers will still need a central directory or registry of APIs to discover which APIs are available and what these APIs do. In the WS*-centered Web services world of SOAP-oriented APIs, which most enterprises still inhabit, this function would be handled by a UDDI directory and some accompanying “repository” software. But in the API world, no exact analog has existed – in part because every API Management vendor has insisted on provisioning its API portal in the public cloud only, a place most enterprises are reluctant to post APIs aimed at internal developers. Layer 7 aims to bridge the gap.

The Layer7 API Portal is the first turnkey API developer portal that can be deployed 100% inside a customer’s private cloud, datacenter or IT facility. Moreover, it is the first developer portal to offer simultaneous support for both RESTful APIs and SOAPy APIs, meaning it can act as a substitute for existing UDDI-style services while providing a pathway to newer RESTful services. Best of all, it can be implemented with different grades of privacy so that the same API Portal can support internal, contract and external developers at the same time – with each group seeing only what the enterprise chooses.

By centralizing where APIs are presented for discovery and consumption by developers, enterprises can make it easier for their service innovators to build new capabilities and mash multiple existing services into newer composite business functions. They can introduce new apps and applications faster. They can respond to change faster. They can build and iterate on new mobile apps in less time, with less error. It all comes down to the API presentation layer.

With the steady decline of the PC business, Intel clearly has to look elsewhere for its future growth. The cloud datacenter is not a bad place to start. Cloud server farms clearly consume lots of processors. Still, servers powering Web sites can operate fine without APIs, thank-you. But servers powering mobile is a different story. Mobile apps (whether HTML5, hybrid or native) get the data that makes them valuable from applications that reside in datacenters. And APIs are the key to letting cloud data be sharable with mobile apps.

Clearly, app-centric “smart” phones and tablets and TVs and cars and watches and glasses are changing the way we go about our daily business. And APIs will power these smart devices by giving enterprise and Internet companies a way to push their data to apps. That hope of bridging the cloud with mobile is probably why Intel has kept its current API product intact. Mashery broadens Intel’s API scope by providing a way to not only share data with mobile apps but now also the developers that build these apps. But will this plan succeed?

If it does, it will take quite a bit of time. The reality today remains that Intel – even despite the semi-recent McAfee acquisition – is not oriented to selling software or even cloud services into the enterprise. It’s missing the sales force. It’s missing the history. And in many ways, it’s missing the rest of the software stack it needs to power the networking, infrastructure and application parts that underpin data in the cloud. That will make selling an API platform comprising a legacy API Gateway and newfound API developer platform a harder proposition. It’s kind of out there alone.

Another obvious roadblock to making the Mashery acquisition successful is that Intel’s existing API Gateway and the Mashery API service are designed for two very different audiences inside the enterprise, with un-reconcilable needs. The API Gateway is designed for an IT department that wants to run its API Management layer in its own datacenter. The Mashery offering is designed for a non-IT buyer (a mobile program manager, say) who wants to run everything in someone else’s cloud.

One is technical, the other is not. One is on-premise, the other is SaaS. One sells traditional software licenses, the other pure subscription. The first aims to address internal and external API integration challenges. The latter is only really concerned with the challenge of acquiring external API developers (though Mashery would probably protest this point).

Will the two be a marriage made in heaven? Given that the Intel/Mashery partnership is already a year old and that Mashery was barely able to grow its revenues in that time, the likelihood seems remote. But who knows for sure? And anyway, Intel has probably not bought Mashery for its $12M in revenue but for its long-term potential as a pathway to mobile.

Mobile devices and social media have multiplied the number of touch-points available for engaging buyers. The line between retail and “eTail” has grown blurry as location increasingly defines all shopping experiences. Big Data now makes it possible for marketers to tailor promotions to every shopper, based on buying history and inferred intent. And API-driven architectures provide a way to tie all online channels, data sources and cloud services together in an event-driven, context-aware network that can engage buyers wherever they are.

All these elements assembled together suggest a new era of personalized commerce. This will place the buyer back at the center of a commerce universe of disparate data, mobile, cloud and social elements that will converge to deliver him or her a more exact shopping experience tailored to his or her choice preferences at that point in time and that place in space.

For Layer 7, this convergence of trends that puts the shopper at the center of an API-connected ecosystem plays to two particular strengths. Firstly, it leverages Layer 7′s leadership in networking enterprise, mobile, social, cloud and partner services via APIs. Secondly, it cements a concept of enhanced identity, where a fuller user profile can be built around an ID to deliver a more complete view of that subject. Both will be essential for delivering on the vision of highly-personal commerce that spans online channels, is location-aware, leverages multiple data sources and can determine a context-specific action across mobile, payment and Web services.

To learn more, read the API-Driven Omni-Channel Commerce solution brief >>

For instance, most organizations will derive far more immediate payback from an API initiative if it enables internal developers, enterprise mobility initiatives, tighter partner integrations or even IT rationalization through hybrid cloud. Each of these endeavours will pay dividends in terms of productivity, agility, distribution and lowered IT costs. Each deserves its own dedicated discussion. However, underpinning all of these API business drivers  – external developers included – there is one often-overlooked consideration for cost and return in any API program: how do you introduce and innovate new APIs cost effectively?

Obviously, there are many ways to stand up an API. Many packaged software applications have some kind of API already, even if some are XML- or SOAP- centric. But in many instances, nothing exists except the desire to expose a piece of functionality or quantity of data as an API. Programmers can obviously build “programmable  interfaces” onto almost anything. It just takes time and people. However, the results will be brittle and the journey expensive.

A faster, less costly and more flexible route is to use an adaptation layer that can talk to various application or data backends and dynamically render one or more as an API. Using a backend adaptation layer can, with the right product, also solve the related problem of iterating on an API, both in terms of versioning but also composition. Add to that the promise of facilitating new business functionality by orchestrating API interactions with external mobile, social and cloud services and you get a pretty compelling ROI story.

Not surprisingly, Layer 7 provides such an adaptation layer. Our API Gateways provide more than just security and management; they simplify backend connectivity, new API formation (i.e. composition) and novel orchestrations with all kinds of cloud, social and mobile services. Like many of our API compatriots, we provide tools that help enterprises build and foster developer ecosystems. But we also realized early on that much of the cost and potential of an API program will rest on how quickly and cost-effectively new services can be launched and evolved. Something worth considering the next time you evaluate the ROI of an API program.

1. There’s just so much of it that it’s easy to lose sight of the byte-sized trees in the petabyte-sized forest

2. It’s locked away in every recess of the enterprise – from applications to relational databases, to non-relational databases, to in-memory caches, public clouds, Hadoop clusters etc.

Data growth and diversity have made data access harder. But data access is the foundation of mobile app development, anything to do with the Internet of Things (IoT) and all kinds of Big Data analytics. Given this need for data in the face of access complexity, it didn’t come as a total surprise to see some of the most innovative Layer 7 customers start using our API Gateway technology as a novel data access, aggregation and presentation solution. As our resident IoT expert Holger Reinhardt pointed out to me: they are using our products to build highly-customized “lenses” across their distributed data backends. To me, this characterization is perfect because what these customers are looking for is perspective on their data. A lens gives perspective with focus.

Now, a Layer 7 API Gateway is more than just a data integration solution. Our technology has several unique features that make it ideal for collecting, composing and presenting data. First, we can talk to all kinds of data sources natively. That wasn’t easy to achieve and it’s something we developed over many years. Second, we can represent the source data as a RESTful API. Even better, we can dynamically generate a virtual API view for a specific user, app, partner etc. The API then becomes the entry point for accessing the aggregated data. Third, we can add fine-grained access and protection policies that ensure only authorized consumers get visibility to specific slices of data, while also protecting the data sources from attack and misuse. When combined, these capabilities give organizations a way to focus on just the information that is relevant to a particular mobile, IoT or Big Data analytics project and then share selectively with an app, cloud service, developer or partner.

A data lens is born!

If you want to learn more about our Data Lens solution, have a read of this new solution brief. Also, feel free to reach out to us with any questions.

Why did  the “disintermediated” direct-to-buyer model win? Simple: it was simplicity. The problem with multilateral exchanges is complexity. They require members to buy in completely and never hedge with alternative paths to consumers; they require the exchanges to always be subservient to the members; and they require 100% participation and 100% consensus. That’s why they keep failing despite the best efforts of organizations like GSMA, the UN, OASIS and others. They require a rigid web of multilateral agreements, subjugation of individual corporate needs to ephemeral collective goals and universality. Just because the broker is a for-profit entity like Apigee doesn’t change anything so long as success or failure depends on universal cooperation and comity. To repeat an oft-used metaphor: putting lipstick on failed efforts like WAC and OneAPI won’t make them any more attractive. They will never have the agility and directness of an over-the-top direct-to-buyer/consumer/developer service. That’s why giant operators keep getting beat by three-person Y Combinator start-ups.

Does this mean aggregation is dead? Of course not! Aggregation models can work but only if the “broker” has the independence and freedom to go off and negotiate unilateral agreements as needed. The aggregator must have the freedom to be run like a self-interested business where the wishes and hopes of the underlying providers don’t factor in. As evidence look at the growing disparity between Netflix and Hulu. The latter emerged as a deliberately-crippled response to the growing power of Netflix. However, the need to accommodate multilateral interests has made it irrelevant. ISIS is fairing no better in the payments arena.

For operators, there is a similar lesson. Be the broker or sell to the broker. Each model has clear economics and places success or failure in the hands of the operator. If an operator wants to offer non-geo-specific services to buyers, it should partner with over-the-top providers or get the capacity from other operators one-to-one. If an operator would rather wholesale its services, be promiscuous and enable every broker/aggregator to consume its services, fine. Then let them be your buyers. The beauty of both models is that they are non-exclusive and don’t require consensus, universality or other impracticalities.

I give Apigee credit, the API Exchange is an improvement over the failed WAC. However the problem was never just technology. Some business models just don’t work in practice.

My rather unsurprising answer to both questions is: “No”. Clearly, some developers will be more valuable than others and borrowing will never be a substitute for ownership. Here’s why:
•    The only developers that matter are those that are engaged and active

Registration numbers don’t matter. “Key Wielding” this or that is marketing fluff. Looky-loo’s don’t build apps that drive revenue or reach. They may take your time, they may toy with your APIs but they won’t deliver business value. And if they are borrowed, “drive-by” developers, guess what – they never will!

As a vendor that helps organizations publish APIs, my advice is to always own your developer. Don’t get caught up in the promises of vendors lending access to hordes of faceless developers. The only developers that matter are the ones engaged directly with you because those are the ones that care about your API and those are the ones that you can develop and nurture.

This does not mean that making it easy for high-value developers to access your APIs should not be a goal. Giving engaged GitHub developers the ability to use their credentials to access your APIs is smart. There are millions of current, high-quality developers waiting for the right project.

So, pick a vendor like Layer 7 that enables onboarding and Single Sign-On from GitHub and other deep pools of active, engaged developers. And be careful not to get caught up in the developer equivalent of a feel-good payday loan. You will pay a high price in the long run.

Not surprisingly, they all emphasized their security and management credentials as being central to their value propositions. Each vendor took a different approach to protecting the welfare of the enterprise but in the end, we all promised we could defend organizations against risk, both technological and financial. What we neglected to mention, I realized afterwards, was that a little risk is sometimes good.

Don’t get me wrong, security is something I take seriously. We at Layer 7 guard some of the most sensitive government and commercial APIs against cyber attack and misuse. But there is a downside to an unbalanced emphasis on insecurity – and that is fear. Some fear ensures prudence. Too much fear can arrest the progress of whole industries.

In a few short years, smart mobile devices have completely transformed how we communicate, socialize, shop and get entertained. Almost overnight, an economy has grown up around mobile apps. This same app explosion is poised to change how enterprises function, by completely un-tethering employees, while providing a way for companies to reach their customers beyond the PC and TV. But to get there, enterprises will have to encourage app innovation and the only way to achieve that is by opening up.

Now, no one says that opening up needs to be a foolhardy effort. Opening up data and applications to mobile apps needs to be done in a guarded and prudent manner. But in all the talk around mobile security, it’s important not to stifle innovation around mobile development. Security has to go hand-in-hand with connectivity.

Apps have become ubiquitous in just a few short years. It’s no surprise, then, that companies large and small want to be part of the app economy. For these companies, enabling internal and external app developers holds the promise of growing market reach, opening revenue streams and maximizing customer retention – all on the back of developer innovation.

For almost a decade, Layer 7 has been helping large organizations open their data and applications to outside partners, cloud services and developer communities. With APIfy, Layer 7 is now making these same capabilities available to smaller organizations and departments, straight from the cloud.

To small organizations looking to open their first APIs to outside developer communities, APIfy offers the core API Management, security and community features necessary to get started. And for users that end up wanting more advanced features, APIfy provides an easy entry point to the Layer 7 API Management Suite. With APIfy, we aim to create an API platform that can grow with our customers.

Over the next several months, we’ll be offering APIfy free on a limited-use beta program. We’re eager to get feedback, so we’re inviting you to sign up and work with us to make APIfy an industry-leading service for opening APIs to the app economy. Enjoy the trial and let us know how we can make things better!