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.

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.

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.

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.

If They Have to Ask…
Try this:

• Create a new Web API
• Get it up and running on some server or other
• Hand the single URL to a client dev and say: “There ya go!”

Is the API self-descriptive? Does it contain enough information in the responses to allow client devs to know what the API is for, what it is capable of and how they can make valid requests to the server and properly parse the responses?

Here are some questions for you:

• How many assumptions do you have about your API?
• Are these assumptions shared by client devs?
• All clients devs?
• Even ones who have never met you?

If your answer to any of those questions was “No” or “I’m not sure” then it’s likely that devs will need to ask you a thing or two about how to properly use your API. That’s no big deal, right?

…You Didn’t Afford It
In everyday life, if people have to ask how to use a device (television remote, toaster etc.) then you can be sure that device is “poorly afforded” – it’s a case of weak design. We all know devices (especially electronics) that come with huge manuals and complicated explanations – and we all know what a bummer it is when that happens.

In this respect, your API is the same as any other consumer device. It should be “well afforded” – developers shouldn’t have to read the technical equivalent of War & Peace before they are able to successfully use your API.

Yes, you can supply detailed instructions in prose, provide a long list of possible methods, include lots of tables etc. These resources are helpful for devs but they can be daunting to read and cumbersome to maintain.

Another approach is to include this kind of information in a machine-readable format – and one that most devs will also understand quickly. This can be achieved by providing instructions (that get automatically updated whenever your API changes) via hypermedia controls in the response. Why write a Web page of documentation to tell devs to construct a URI and use that URI to execute an HTTP GET when you can just include that (and much more) information in your API responses?

Help your client devs out. Throw ‘em a bone, here. Don’t make them read pages of documentation when you can just include simple run-time instructions as they’re needed.

In conclusion: If they have to ask, you didn’t afford it.

(Originally published on my personal blog.)

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!

Las Vegas Mobile App Hackathon (November 16-17)
The local developer community is thriving in Sin City, which may be a surprise to many. I was very impressed with the talent of the developers in Vegas, most of whom were writing native Objective C or Java for their iOS and Android apps. Also, the local PhoneGap user group manager was onsite, providing support for Adobe’s app development framework. The apps produced were quite polished and impressive. Several included API integrations while others came with plans for future Web integration of APIs, to add context and information.

Miami Mobile App Hackathon (December 14-15)
This hackathon brought an impressive group of sponsors together including AT&T, Microsoft Azure, Blackberry Dev, GitHub and – of course – Layer 7. With over 200 signups and some highly technical evangelists sent by the sponsors, I was excited to see what kinds of apps would be produced. The developers mashed together numerous Web services using native code or PhoneGap. It was great to see the local developer community come together, with numerous local start-up incubator leaders onsite scouting for new talent and investment opportunities.

For 2013, Layer 7 will once again be joining the AT&T Hackathon team for several events. Many organizations with APIs powered by Layer 7 will be promoting their APIs and providing prizes at these events. Stay tuned – we’ll be helping evangelize a lot of great APIs in 2013!

Find out more about upcoming Layer 7 Hackathons

For example, hackathons provide a fantastic way to grow developer awareness of your API as a brand in and of itself, separate from your core business. When the developers who attend your hackathon go back to their day jobs on Monday, they have added your API to their programming tool belts and will use it, when appropriate, in upcoming projects. Additionally, hackathons will attract the attention of thought leaders and influencers who will mention your API on blogs and forums, spreading the word further. These benefits can deliver considerable value but they can also be difficult to quickly quantify.

Nevertheless, API evangelists will be held accountable for demonstrating the real-world value of their hackathons. One way to do this is to show how hackathons enable your company to conduct developer user experience (DevUX) research at a minimal cost. Gathering feedback and data from hackathons provides the most cost-effective way to optimize the quality of your API as a product by answering questions like:

• How user-friendly is my registration process?
• Do my APIs ever return incorrect or unexpected results?
• What new features should I add to future versions of my API?
• Is the skill level of my API appropriate for long-tail app developers?
• What kind of tutorials and other documentation will my developers need?
• Which programming languages are my developers using to implement my APIs?
• How useful is my API and what are the most common/innovative use cases for it?

The data and feedback you gather will also help you to further demonstrate ROI by providing the answers to questions such as:

• How many developers registered and how many actually attended?
• Did the hackathon appeal to the types of developer we want to attract?
• Did any valuable or innovative apps get prototyped?

Hackathons offer a fantastic way to build excitement around your API and optimize the quality of your interface. If you still have any doubts, join us for a hackathon (and participate!) to see how other API platforms are doing it.

Recently, we began a series of free eBooks that will distill our communal knowledge into specific, targeted recommendations for dealing with a variety of challenges around APIs – from interface design, to security, to developer engagement. Today, I’m pleased to announce the first two of these, which deal with API exposure for internal mobility projects and for externally-facing open APIs.

First, we have Enterprise on the Go: 5 Essentials for BYOD & Mobile Enablement. This eBook focuses on the challenge of securely exposing internal applications and information assets to mobile employees, either on their own devices (BYOD) or as part of a larger mobility initiative. These five key points for a successful deployment are presented in an easy-to-consume synopsis and then backed up by white papers, webinars and customer case studies. Of particular interest to our enterprise customers are the sections on repurposing existing services and using middleware to optimize for mobile use cases.

Next, we have 5 Ways to Get Top Mobile App Developer Talent for your Open APIs. While not all enterprises have chosen to expose their APIs externally, those that have are faced with the challenge of acquiring a talented community of developers that will build useful mobile apps for the consumer marketplace. However, enterprises can’t simply assume “build it and they will come.” Getting devs onboard requires investment in documentation, branding and community development. This eBook discusses some of the best methods for onboarding and rewarding those developers who provide the most value.

Whether focused on internal or external developers, these eBooks are valuable resources for anyone looking to expose APIs for mobile access to enterprise assets. We welcome your feedback on this format and look forward to continuing the series.