A Thousand Kisses Deep


My great friend and mentor Doc Searls posted a poignant eulogy to Leonard Cohen.

I had no idea he felt the same way I do about his music.

Through the soundtrack of my life, nobody else taught more about how to be a man, a lover, and a human being with one foot in the temporary world and the other in eternity.
< p dir="ltr">I’ve listened over and over to all of his albums. I especially like “The Future” and “Ten New Songs.” His new album—“Songs from a Room” is also fabulous.

His music played a huge role in getting me through many a tough time, A Thousand Kisses Deep.

The ponies run,
the girls are young,
The odds are there to beat.
You win a while, and then it’s done –
Your little winning streak.
And summoned now to deal
With your invincible defeat,
You live your life as Continue reading "A Thousand Kisses Deep"

Trust Frameworks and the Blockchain

Excellent TED Talk on how the Blockchain technology will play a role in managing trust and identity.

The Thesis

Rachel Botsman is studying the defines trust as a “confident relationship to the unknown.” She is studying how technology is transforming the social glue of society.

Human beings are incredible in being able to take trust leaps.

She then introduces the concept of “climbing the trust stack.”

She then posits that we are going thru a massive change in the trust model, one from an instituionalized model to a distributed model.

She goes on to say that the blockchain technology will play a major role in how we effect digital trust. So much so, that the trust stack can be simplified, and the need for institutionalized trust intermediaries can sometimes be mitigated.

Watch the entire video. Very enlightening and provides a clear and consice explanation on how the blockchain Continue reading "Trust Frameworks and the Blockchain"

Self-sovereign Identity System (SIS)

In a recent series of blog posts by Phil Windley, the concept of a self-soveriegn identity system is introduced.

SIS purpose is just like it sounds. An independent identity system managed by users. The series leads up to the announcement last week of Sovrin.org. (But I will get to that later.) Since these are in a series of blog posts, they are in reverse chronological order. So here they are in order.
  1. Service Integration Via a Distributed Ledger
  2. Governance for Distributed Ledgers
  3. An Internet for Identity
  4. Self-Sovereign Identity and the Legitamacy of Permissioned Ledgers
Some of these are lengthy. The topic is complicated, but fundamental to the future. Take your time. Dont let TL;DR syndrome sidetrack you.

In World of Ends, Doc Searls and
Dave Weinberger enumerate the Internet’s three virtues:

The New Laws of Identity: By Kim Cameron


Keynote–Updated Laws of Identity: Kim Cameron


This is a transcription of a keynote speech given by Kim Cameron (Chief Identity Architect, Microsoft Corp.) at IIW (Internet Identity Workshop) in May of 2016. The beginning was not recorded, the transcription begins shortly after his talk commenced. I have also pulled out a section about the blockchain, I would like to hear more about what Microsoft is planning to do using blockchain technology. (Can you address this Kim?)
But we also have the evolution of decentralization. So to me things like the blockchain are hugely important because the blockchain represents a way of removing the exclusive power of the concentrators.

The Laws of Identity

… what was a digital subject? So a digital subject is a person or thing in the digital world that is being dealt with. That’s all. That’s also from the dictionary, a subject is Continue reading "The New Laws of Identity: By Kim Cameron"

Tweeting a Live Event

Kevin Marks At the most recent Internet Identity Workshop (#iiw), I was watching the #iiw twitter feed. As the keybote speaker began (Kim Cameron), a barrage of insightful tweets from Kevin Marks ensued. I looked over at Kevin Marks tapping away on his laptop. Something didn’t make sense. There was just no way the number of keystrokes he was making was matching the prodigious output of tweets. WTF? So I aksed him how in the world he was doing that. He happily reavealed a tool for tweeting events that he and some others had developed. Noter Live Brilliant. Love it. Since then, I have noticed others starting to use it with astounding results. Phil Windley.

Proper Language is Important

Doc Searls treats the question of referring to the Internet as just “internet.”
There is only one Internet just like there is only one Universe. There are other examples of neither. Formalizing the lower-case “internet,” for whatever reason, dismisses what’s transcendent and singular about the Internet we have: a whole that is more, and other, than a sum of parts.

  Spot on.

Identity Hero

Something very unusual happened this year at IIW. Phil invited a “keynote” speaker.
This is very much not in line with the unconference format, but it worked.
Kim Cameron is seen as a visionary concerning Identity and published the 7 laws of identitya few years back. He updated them to 10 laws. He hasn’t posted them to his blog yet. I hope he does soon.

Old friends and new friends

At the Internet Identity Workshop last week, I met a wonderful person named Mei Lin. She is so passionate about bringing technology to what she refers to as “the next 1.5 billion.” Mei and Doc were also fast friends. She sent me an outline of her thinking.

IIW 24

I attended Internet Identity Workshop 22 in Mountain View last week. Fabulous conference. There is always lively discussion for experienced identity people and newbies. Above is a shot of our beloved Doc Searls. Thanks Doc. Everyone is interested in learning and sharing information. This is my favorite conference to attend.

2015 Winding Down

2015 has been a most difficult year for me. Lots of oppourtinity for growth. Ugh.
Robbed, evicted, and hospitalized.
To finish it, one of my dearest friends, mentor and advocate died from a staph infection last week. On the good side, I have lost alot of weight. I feel better and am getting around much better. Looking forward to a wild 2016.


2015-03-31 21.36.56

Sketched in Procreate on an iPad.

Writing. I find it ironic that the thing that is the hardest for me to do—write—is how I make my living. Be careful what you ask for. In the interest of improving my craft, I read books about writing. Writing Down the Bones: Freeing the Writer Within, How to Write a Sentence: and How to Read One, Writing White Papers: How to Capture Readers and Keep them Engaged and recently I discovered  Uncreative Writing: Managing Language in the Digital Age. Note: I find it painfully bizarre that Kindle will not let you cut and paste text.
For the past several years, I’ve taught a class at the University of Pennsylvania called “Uncreative Writing.” In it, students are penalized for showing any shred of originality or creativity. Instead, they are rewarded for plagiarism, identity theft, reproducing papers, patch writing, sampling, plundering, and stealing. Not surprisingly, they thrive. Suddenly, what they’ve surreptitiously become expert at is brought out into the open and explored in a safe environment, reframed in terms of responsibility instead of recklessness. Each semester for their final paper, I have them purchase a term paper from an online paper mill and sign their name to it, surely the most forbidden action in all of academia. Each student then must get up and present the paper to the class as if they wrote it themselves, defending it from attacks by the other students. What paper did they choose? Is it possible to defend something you didn’t write? Something, perhaps, you don’t agree with? Convince us. All of this, is technology-driven. When the students are writing class, they are told that they must have their laptops open and connected. And so we have a glimpse into the future.

Uncreative Writing: Managing Language in the Digital Age, Kenneth Goldsmith

I love this sort of thinking. Inspiring.

The Compuserve of Things


My good friend and mentor Phil Windley recently published “The Compuserve of Things”. As usual the information is well thought out and clearly articulated. It is so good I wanted to reiterate portions. Here is the summary: On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980’s, or will we learn the lessons of the Internet and build a true Internet of Things? This also reminds me very much of the saying Doc Searls gave me:

Freedom of choice does not equate to choice of captor.

The way the internet is being used today, we have become numb to the process of being herded into silos of captivity. The first step to remedy this is awareness. Not always easy to resolve.

A Real Open Internet of Things

If we were really building the Internet of Things, with all that that term implies, there’d be open, decentralized, heterarchical systems at its core, just like the Internet itself. There aren’t. Sure, we’re using TCP/IP and HTTP, but we’re doing it in a way that is closed, centralized, and hierarchical with only a minimal nod to interoperability using APIs.
When we say the Internet is “open,” we’re using that as a key word for the three key concepts that underlie the Internet:
  1. Decentralization
  2. Heterarchy (what some call peer-to-peer connectivity)
  3. Interoperability
I really like these concepts. It all begins with awareness.


Pondering the real open IoT causes me to in all sorts of directions. In my next post I will explore the relationship between Bitcoin and IoT.

The Five Axioms of the API Economy Summarized and Series II

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since. It’s been a pleasure for us to work together on trying to derive a sound basis for thinking about the API Economy – but that basis isn’t very useful if it isn’t built upon. So today we’re introducing the second part of the API Economy Axioms series – a look into what the consequences of these axioms are.

We’re starting off in this post by summarizing the five axioms and from next week we’ll be covering what happens next:

  • Implications for individual organization
  • Implications for Internet and business ecosystems as a whole
  • The challenges to be faced – both technical and organizational

If you missed any of the Axiom posts, they are linked below in each section.

Summarizing the Five Axioms

In summary, the Axioms are defined as follows:

  • Axiom #1— Everything and everyone will be API-enabled: This Axiom highlights the fact that almost every network connected endpoint is becoming an API that can be invoked and read by other software systems. This transformation, when seen device-by-device or step-by-step, seems logical – perhaps even mundane. However, the point behind this Axiom is that as a macro phenomenon we are quickly accelerating into a world where almost every device and system is addressable via APIs. [Axiom 1]
  • Axiom #2— APIs are core to any cloud, social and mobile computing strategy: More concretely than Axiom 1, this Axiom describes how APIs form part of what are arguably the three most important transformational forces in the online economy today: cloud, social and mobile. It’s very clear that many of today’s innovations in these areas would be impossible without API-like architectural patterns (even if not always named APIs) and that APIs are enabling yet more of this same transformation. [Axiom 2]
  • Axiom #3 – APIs are an economic imperative.: This Axiom shows that APIs are at their core not simply a technical phenomenon, but are intrinsically linked to the creation and access to value – resulting in economic impact. This does not necessarily mean relevant APIs are “paid for services” (although some are), but in fact that almost all APIs enable, improve or scale value in ways which increase economic impact. [Axiom 3]
  • Axiom #4: Organizations must provide core competence through APIs: This Axiom zeros in on the fact that the transformation that matters most is when it’s core competence as an organization is made available as an API. In other words when APIs become drivers for core business, and enable partners and customers to engage, provision and consume that core competence in new ways. [Axiom 4]
  • Axiom #5 – Organizations must consume the core competencies of others through APIs: This Axiom is a counterpart to Axiom #4 and highlights the fact that consumption of the APIs of others is of equal importance to provision. When this consumption is of the core competences of others then this provides the strongest foundation for business partnerships. [Axiom 5]


By themselves, these Axioms can seem rather dry or disembodied – why these Axioms and not five others? While it is hard to know whether we chose the correct five building blocks they were chosen because they illustrate different dimensions of what is happening in the API Economy today:

  • Scale – Axiom #1: reaching almost every software and hardware system being deployed.
  • Momentum – Axiom #2: underpinning huge global transformative trends.
  • Economic impact – Axiom #3: moving from a technical phenomenon to a business essential.
  • Imperative to provide –Axiom #4: demonstrating the impulse to offer APIs.
  • Imperative to consume – Axiom #5: closing the loop on provider – consumer relationships for services.

But, the proof in the pudding is whether or not, these Axioms allow us to say something about how we think the API Economy will evolve, change and impact business.

This is the subject of the next set of posts we have queued up – we’re looking forward to people’s thoughts on both the Axioms and what we can derive from them!


The Five Axioms of the API Economy: The Macro Effects of APIs – Rise of the API Economy

This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since. Having stated the Axioms in previous posts, a number of big picture questions arise: beyond how they are related to individual organizations, what effect do they have on the evolution of the web and the economy as a whole? What challenges are there in making the API Economy a reality? The first post covered implications the Axioms have for individual organizations. In this second post, we cover implications for the market in general, the API providers, consumers and infrastructure organizations. To look at this, it’s helpful to think in terms of what the axioms imply and what can be derived from them for the technology market in general:
  • Axioms #1, #2, #4 and also the arguments in the previous post on the imperatives for individual organizations to become API providers, show there is very clear pressure for more organizations to open APIs — both to smaller selected groups of partners and to the wider world. The value of each API is initially in the ecosystem built around the API and this is already sufficient to push many organizations over the edge. One of the important byproducts of this is also to increase the supply of APIs available in the economy — essentially each launch creates a new building block for others to use.
  • Via Axiom #5, there is huge benefit in consuming the APIs provided by others — often the organizations providing them offer specialist services of very high grade which would be impossible to replicate internally. Not using these often results in significant loss of competitive advantage. This fact creates clear demand pull for available APIs and further, leads some organizations to go as far as asking their existing partners and suppliers for access to API capabilities.
  • As the economic imperative plays out (Axiom #3), organizations are naturally drawn to want to exploit these opportunities for increasing gain: providers to reach a greater audience with their offering and API consumers seeking increased benefits from external services.
  • So, one can think of the API Economy emerging initially as a series of strong individual ecosystems around valuable individual APIs — each of which has its own growing customer or partner user base. However, over time more and more APIs emerge, and those API consumers getting benefit in one place begin to demand it elsewhere. This dynamic implies a “positive feedback loop” between new APIs becoming available, new API consumers and increased API consumer pull — an autocatalytic chain. The growth of new APIs is the driver for new API consumption and vice versa. The question is – what are the signs that this interconnectivity is emerging and acting as a loop? We first look at the API supply-side, then the demand-side and finally end with some thoughts about the feedback loop.

    Supply-Side Dynamics

    There are some excellent API programs we can examine that can be examples for how all providers should design their programs (Twilio, Sendgrid, Stripe, NPR, Twitter, Facebook for example) and they have gone on to build huge audiences. As a result, all of these organizations have large and successful developer programs with a significant number of apps and services that use their APIs. The ultimate objective of any API program is to garner a relevant group of developers that use the provider’s APIs. Each API Program – whether tailored to the broader public, customers or close partners creates its own community of value, as illustrated in the Figure 1 (Source ProgrammableWeb): web growth Figure 1—API Growth                                                               Source:ProgrammableWeb In Amazon’s case, APIs spurred both internal innovation, resulted in a large network of resellers, power their own mobile devices, and added a whole new line of business. The API layers built by the company are now an intrinsic part of their business. Once a customer/partner community is within this particular orbit, they are able to plug into existing services. However, Amazon has also added new services over time to serve more demand. For example:
  • Amazon Redshift—distributed hosted data warehouse services
  • Amazon Route 53—highly available DNS services
  • Similarly, many other organizations extend the functionality of their APIs over time – Paypal, Twitter and more. In some cases functionality is also restricted over time as business models change. As we have noted in previous posts, an interesting dynamic occurring in the industry is as more new and traditional vendors are jumping into the game with solid API programs, this stimulates interest in partners, competitors and other constituents to do the same:
  • Walgreens was one of the first retailers to open an API, many other retailers have since done the same.
  • USA Today and the New York Times were very early in the media field — many other news and content organizations have since followed.
  • The result is impressive annual growth in the number of APIs — both public and private. The number of APIs now listed on ProgrammableWeb is now approaching 14,000.

    Demand-Side Dynamics

    The other dynamic regulating the growth of the economy feedback loop are the dynamics occurring in the consumption of APIs and mashups of APIs from all sorts of organizations and independent groups and developers. Some of these dynamics are recognized in the following ways:
  • Each of the APIs has its own user base,
  • Each user of the API is deriving value from the APIs,
  • Many API consumers use more than one API.
  • As an indicator of developer engagement, the number of developers using APIs is continuously rising — 3Scale now has 150,000 developers using the APIs it powers as does Mashery. While there is likely overlap in these populations, there is strong regular growth in developer numbers. It is a little harder to measure demand-side pull for new APIs. Anecdotally however:
  • Quora regularly surfaces questions of the form “Does X have an API?” — Recent examples for X include WhatsApp, Uber, Square, ZocDoc, Viber, Qwiki and Quora itself.
  • Many of the organizations working on new API programs also cite customer and partner demand as a major reason for opening a program.
  • In sharing the first API Economy axiom with a close friend and programmer we received his response that brought up some relevant questions: “Maybe this will be covered in later axioms, or maybe it isn’t appropriately part of the axioms, but this is my gut reaction as an old programmer when I read about the API Economy: ‘Gaaaah!!! It’s hard enough keep track of the few hundred APIs in the Windows SDK and the handful of web libraries I use now. So now I’m supposed to be able to use potentially billions of APIs for every service, company, platform, and potentially every user on the internet? Who will document all those APIs? Who will test them? Will there be meaningful version control so I know when something changes? Will there be any consistency in syntax, performance and data usage? I think I should have listened to my Dad and gone to law school’.” As this programmer asks, what about version control and search? Many organizations use Github to present their APIs to API consumers to address this.. Indeed Github has its own set of APIs to automate this process. Kin Lane—API Evangelist—gives a great example of a coder that instinctively figures out how to make this happen on his own (the post is here.) There is much done, and much more to be done on the consumer side of the dynamics of the API Economy. With some exceptions, todays APIs are individual silos that are focused on interacting with just the constituents of a specific organization. They are islands of functionality – the question is, will these islands join up into a coherent “economy”?

    A Feedback Loop And A True “Economy”—Distributing, Managing, Monetizing And Aggregating The API Economy

    Each API grows its own user-base over time but there are often overlaps in the mesh of APIs and certain API providers with together — for example Twilio, Sendgrid and a number of others often participate in hackathons together. There is also clear API consumer demand being expressed. The question is, are these individual islands driving and feeding each other enough to create a big enough loop to generate autocatalytic growth? The answer is — yes. There are clear signs that this supply-demand loop is acting, accelerating, and at the same time causing acceleration of growth in the creation of API programs. Further, there are also clear signs that while the API landscape is still a patchwork of ecosystems and technologies, there are structures emerging that are beginning to cut down the friction and create more connectivity. At the most fundamental level, there is clear cross-pollination between API programs:
  • API consumers of one type actively demand and subsequently use APIs in other areas
  • Organizations that see competitors provide and consume open APIs are driven to follow
  • Technology best practices are increasingly being re-used across APIs so developers are less often faced with unfamiliar design patterns.
  • These are now being reinforced by a wide range of fledgling activities which act to glue activities that when combined together reduce the “friction” in any economy:
    • Conferences: A number of API conferences have now sprung up from the API Strategy & Practice Conference to APIDays, Nordic APIs, API World, iLoveAPIs and APIcon as well as Gluecon which cover APIs often and early. These and smaller technical events like RESTFest and API-Craft do much to share best practice and encourage technical development.
    • Best practice blog posts and books: A large amount of blog materials, video, presentation and other content is now available to share how to achieve things with APIs – both from technical and business perspectives. Efforts such as APICodex (by 3scale) and APIAcademy (by Layer7) help categorize and track the best of this content.
    • Analyst reports: all major analyst groups and most subgroups are proactively monitoring and reporting on the API economy.
    • Directories, discovery and search: A fundamental element of a genuine economy is the ability to find APIs to use – ProgrammableWeb was an early pioneer in this respect, acting as a directory for open APIs, Mashape plays a similar role and APIs.io is attempting to add a search engine style approach.
    • Tools for API providers and consumers: The technology for deploying and managing APIs was complex and unwieldy early on – however companies such as 3scale, Intel-Mashery, Apigee now provide tools which make it easier for providers to get into the game. On the consumer side, the toolset is also increasing with tools such as APItools, Runscope, oAuth.io, APIMetrics, SoapUI making API testing and usage much easier.
    • Ratings and Trust: A problem that arises as an economy grows is knowing which APIs to trust and api500 is a first attempt in that direction.
    • Aggregators: The emergence of aggregator APIs which wrap other APIs are also another sign of structure being added that connects individual APIs – examples include Newscred, Segment.IO and Singly (now part of Appcelerator).
    • Mashup Tools: Lastly tools such as IFTTT and Zapier are making it easier for end-users to combine APIs – improving the value that can quickly be gained by using multiple APIs at once.
    In some of these cases products and services are still in early stages, while others are already very mature. Together they are all signs of a connective tissue forming which helps the iterative interactions between API providers and API consumers. The two-way flow of demand is therefore becoming more agile and efficient and creating the autocatalytic positive feedback loop we are looking for. Photo Nov 09, 1 21 58 PM


    APIs as a tactical means to support the business of an individual organization deliver value – in general both to the provider and the consumer. This, in and-of-itself makes them valuable to build. However, what is also clear is that there are many transversal benefits to the development of many APIs – competing and complimentary. Shared technology, conferences, inspiration and re-use in unexpected ways all drive the feedback loop to make an Economy of APIs more valuable than the sum of the parts. Many of the structures that glue this economy together are still extremely nascent or not widely used, but the fact that they exist at all suggests there is increasing value in the feedback loop. It seems likely that both the number of individual APIs and these structures will all accelerate. In the next post we’ll explore how we might define the API Economy and in posts that follow we’ll look at challenges for individual organizations and the Economy as a whole.

    The Five Axioms of the API Economy: Micro Effects of APIs – API Drivers for Individual Organizations

    This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since. The Five Axioms of the API Economy (find a summary post here) presented in previous posts articulate some baseline assumptions about world that appear to be true – and are likely not just to hold –but grow stronger over time. Having stated the Axioms, a number of questions arise: how do they relate to individual organizations? What effect do they have on the evolution of the web and the economy as a whole? What challenges are there in making the API Economy reality. As we continue the series, we’ll dive into these questions from different angles. The first, covered in this post, is what implications the Axioms have for individual organizations. According to a research report by Wipro & Cutter Consortium, 83% of organizations are either engaged in an API program now, or are planning to in the next three years. (API research report) – so this indicates that there are clearly drivers in play for organizations to work with APIs – the question is what do our Axioms tell us.

    Axiomatic Implications

    To look at this, it’s helpful to think in terms of what the axioms imply for an individual organization (specifically, what can be derived from them). In particular:
    • Axiom #1 tells us that it’s likely products, services and the organization itself will require APIs at some point in this future – as will those provided by competitors – the only question is how and when.
    • Via Axiom #2, if the company is investing in social, mobile and cloud integrations or products, APIs are likely already on the agenda in some form and effort is already being put in – however, not necessarily with the right long term focus.
    • Via Axiom #3, the api-ification is likely to have significant economic impact on the top and bottom lines at the point when it is carried out.
    Axioms 4 and 5 together tell us that organizations need to find ways to provide their customers/partners access to their competences in API form. Additionally, they should find strong, stable partners to bring in competences that are secondary to them. In other words, there will be a push for APIs to play a significant role for most organizations – at least those with some kind of digital presence. There is little sense of timing however. Although there is a general sense that API-ification is proceeding quickly in some sectors of the economy, it’s difficult to pinpoint sector-specific timing. The only clear indicator is that early movers potentially have a large advantage in locking up customer/partner ecosystems for themselves. So, a statement like: Go and do APIs, urgently! is not particularly helpful, so in this post we’ll look at some of the most common use-cases for APIs today. At the end of the post we’ll wrap up with critical questions to help evaluate what the drivers for an individual organization are.

    Common API Use Cases

    In this post, we’ll cover six of the most common API use cases we see commonly – at 3scale it’s rare that customers seeking to launch APIs have use cases outside of these six or combinations of them. They use cases are:
    • Mobile Enablement
    • Customer Ecosystems
    • Partner Ecosystems
    • Distribution for Content and Transactions
    • New Business Models
    • Internal Innovation
    A more in depth discussion of these can be found in the introductory eBook Winning in the API Economy.

    Mobile Enablement

    First generation mobile applications typically offered functionality that was limited to the operation of the device itself – making calls, sending messages and storing modest amounts of data in local memory. Applications soon began to provide more utility and richer experiences by using backend services for added content and transaction functionality. As mobile applications evolve, they are now generally available in multiple versions for various operating systems and devices—Android, iOS, Windows Phone or even next-generation non-mobile devices such as Smart TVs. This increases audience reach but also significantly increases management complexity. Recently, it has become clear that the platform of choice for new applications is the mobile device. Smartphones and tablets are quickly overtaking the desktop as the place where developers have focused their efforts for new applications. Almost without exception, this new breed of mobile applications is being built on existing and emerging APIs. According to Evans Data’s recently released Developer Population and Demographics Study, of the 19 million software developers in the world, 8.7 million are now writing apps targeted for mobile devices. That number becomes even more impressive when we consider that the mobile developer population has doubled since 2010 and added 700,000 new developers in 2013.

    Customer Ecosystems

    A common challenge for organizations is to serve special needs that vary on a customer-by-customer basis. In enterprise scenarios this typically leads to staffing significant post-sales engineering teams to provide on-premise customization and installation. In others, it can make products hard to sell versus in-house builds. In still others, companies simply cannot tackle certain market niches since they are not profitable enough to serve. Exposing programmatic functionality to customers has multiple benefits. First, it enables customers to increase the value they derive from a service to suit their own needs more closely. Second, tighter integrations encourage customers to drive more transactions through the systems, often increasing revenues. Third, integrations by customers represent significant efforts, reducing the likelihood that they would switch vendors. Lastly, platform access is often an up-sell driver (for example, Salesforce API access is only permitted for enterprise level contracts). Using APIs to develop customer-centric applications is changing the way organizations approach managing customer ecosystems. Organizations are building both customer-facing applications and allowing their development through and API program.

    Partner Ecosystems

    A similar but different opportunity for APIs is in exposing APIs to third party organizations that act as partners rather than customers. Specifically these organization may be suppliers, resellers, provide value-added features or generate a range of other benefits. A partner ecosystem and API typically differs from a Customer Ecosystem in that the functionality accessible to the partner tends to be in the form of management level interfaces (account creation, affiliate management, metrics across customers and so forth). Further, partners generally have differing legal agreements. Partner Facing Applications: Exposing functionality in ways that allow third parties to re-package functionality and deliver it to new audiences is covered in more detail in the next sections. However, it is one of the most common ways to view platforms. Platform tools allow motivated partners to create specialized versions of a service for new audiences and market them separately. Integrators and Software Partners: Rather than replicating functionality, a third type of platform user is one that augments the functionality of the original product, either by providing new software applications (such as the Salesforce Application Ecosystem) or by providing connectors to their own services (partner marketplaces for example, such as those run by Zendesk and Atlassian where the apps are often bridges to other systems).

    Distribution for Content and Transactions

    One of the areas in which platform thinking has been most immediately valuable, and deserves its own category, is in powering distribution. The notion of a digital sales channel used to be tied to companies having and managing a web presence, an HTML destination site where customers could browse product information (content, media, services or physical goods) and engage in purchasing transactions. But mobile added another channel that needed to be managed—often in an entirely different way from how existing properties are managed. In the new API economy, however, this thinking is outdated, and there are more opportunities for distribution than ever before. A multi-channel distribution channel is now clearly the strategy to pursue. Building APIs that accelerate reach fall into two broad categories, depending on the type of product involved:
    • Content and Data: Content and media businesses are always seeking new ways to reach their audiences. While a company’s own web property and mobile applications may provide the primary means to reach audiences, in the API Economy this is no longer enough. Because consumers expect content to be available whenever and wherever they need it, companies that become adept at delivering this have a powerful advantage, be this on new hardware devices or through partner channels or aggregators.
    • Transactions: Providing inventory and transaction capabilities in a programmatic way and using both to drive transactions is a powerful strategy for eCommerce businesses, and it can also be beneficial to brick-and-mortar retailers. Since business success is strongly correlated with transaction volume, APIs can enable increasingly powerful affiliate models to drive business, or even more radically, support wholly self-sufficient third party resellers.

    New Business Models

    Although many API use cases involve feeding and extending existing business models, some are focused on the creation of entirely new business opportunities or even the establishment of new primary channels. A new API may even become the primary product for a company or one of its divisions. Consider these two examples:
    • Google Maps: While many users experience Google Maps on one of Google’s own properties, it is also by far one of the most widely-used embedded APIs, which adds Maps to a wide range of third-party sites and applications. Although Maps are free to use for the end user, and though the API is also free up to a certain number of users, Google does charge for usage above this level, to recover the costs of serving the heavy traffic loads.
    • Twilio: Twilio is one of the leading companies worldwide in programmable communications infrastructure. The company’s well known API makes it simple to set up voice calls, send SMS messages and carry out complex call management tasks using just a few API calls. Additionally, the company is widely praised as having developed one of the most developer-friendly API experiences.
    The business model in both of these examples is directly tied to the number of calls on their APIs, the number of results returned or other metrics directly related to API traffic. Such metrics can be used in contracts, and are tied directly to billing. In each case, the API is essential to the business model. Each API call (an SMS sent, a map tile served), is closely correlated with calls to the service and value to users.

    Internal Innovation

    Until now, we have provided examples of external-facing APIs, and we described how to use such APIs to build strong partner ecosystems and drive new business. Arguably, however, the most immediately accessible opportunity for many businesses is an internal use case for APIs. Companies manage collections of important internal systems, all of which mesh in complex ways to deliver products and services. As an organization grows, these systems change, get re-purposed, and, if they are well managed, they can become key assets in delivering ever more innovative services. Unfortunately, the development of new products, services, and processes is often carried out in a manner that weaves a complex web of inter-dependencies across legacy systems. This can slow innovation significantly and in some cases, it simply rules out new projects. Potential issues include:
    • Greatly complicated maintenance, since the layers of dependencies often need to be worked out prior to setting regular maintenance activities.
    • A significant amount of refactoring forced on teams tasked with creating new systems.
    • Challenging and lengthy work required to actively define the nature of the interfaces to different internal systems, departments and processes can create an environment that is ready for change and innovation.
    Using APIs internally eases these burdens and can create synergy between divisions and workgroups that didn’t exist before. Many organizations—such as Amazon—require that internal groups provide API access to information and resources.


    There are strong business and technology trends that are driving universal adoption of the API Economy and the trend of 83% of organizations being engaged in creating an API program is no accident. The benefits of an API program are proving to be valuable and measurable. As we have shown, the key business and technology drivers occurring in the industry are the same drivers that indicate organizations should do more than just consider an API program. In the next few post we’ll be exploring the Macro affects of this proliferation of APIs and also the steps to take to run a successful API program.

    The Five Axioms of the API Economy, Axiom #5 – Organizations Must Consume Core Competences of Others Through APIs

    This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

    The Five Axioms of the API Economy

    This blog post is the fifth in a series of blog posts outlining the axioms of the API economy – and covers the fifth and last axiom. However, it won’t be the last post in the series – once we’ve covered all the axioms, we’ll proceed and talk about their consequences also. The five axioms we’re covering are as follows, in order:
    1. Everything and everyone will be API enabled.
    2. APIs are core to every cloud, social and mobile computing strategy.
    3. APIs are an economic imperative.
    4. Organizations must provide their core competence through APIs.
    5. Organizations must consume core competences of others through APIs.

    Axiom #5: Organizations Must Consume Core Competences of others through APIs

    The fifth and final axiom is the converse of the fourth axiom. Just as there is value in exposing APIs for others to consume, there is value in consuming the APIs of others. So much value in fact it is very likely a critical failure not to do so. Examples of this have already been given with Axiom #2 – for social, cloud and mobile (the former two in particular), the amount of functionality now available via API to simple use “out of the box” is staggering. More specifically – the effort required to rebuild the features of many PAAS, IAAS, SAAS systems to the same level of functionality and consistency is beyond the capacity of all but the largest companies. Replication of some services is furthermore impossible – while it is feasible to write code for a microblogging service, Twitter is Twitter since it commands a global audience, not because of the functionality it provides.
    The richness of functionality now available “by API” extends into multiple different realms:
    • Data: impressive data catalogues of many types – many unique.
    • Communications: SMS, Telephony, Instant Messaging, Video, Email.
    • Processing: IAAS, PAAS platforms or specialized services like Aniomoto.
    • Transactions: Payment APIs, Subscription Billing and others.
    With such a rich set of tools available, developing systems has become significantly easier than it was 5-10 years ago. While choices need to be made both between providers and which elements should be developed in-house it is clear that many of these systems have the possibility to be of very significant value to an organization. Any work an organization does that this is not focused on its core competence is arguably overhead. In other words, if comparable competitors were to use external APIs to achieve some important but non-core / non-differentiating functionality and this worked at least as well as an in-house build, this competitor would have freed up time to move further ahead on their core product. The opportunity cost of in-house builds of non-differentiating services is great. It is therefore an imperative for organizations to:
    • Identify what their own core competence / differentiation is and ensure that the majority of effort is targeted towards this.
    • Where possible consume APIs of others to bring in functionality that is non-core in in this way.
    There is a final, subtle angle to this axiom – it suggests consuming the core competences of others, not any competence. This means that if an API is chosen for use, it should ideally be something which is clearly and obviously linked to the core business of the organization providing it. This ensures that:
    • The provider is likely to remain committed to the API.
    • They derive value (economic or otherwise) from third party use of the API and hence should continue to support it.
    These are all very strong indicators that the API will be maintained and improved over time. They also means that in many cases (though not all) there are likely competing companies providing similar APIs – providing a switching path in the case of failures on the part of the chosen provider. If an API is a secondary, side business for an API Provider or does not seem to be core, this may be a higher risk integration – generally assurances from the API Provider should be sought.


    Axiom #5 makes it clear that any API strategy not only includes the publishing of APIs for other constituencies to participate with but for organizations to plan on integrating the core competencies of their constituencies into their applications services and infrastructure. Make sure your organization understands the dual nature of API publishing an API consuming.

    The Five Axioms of the API Economy, Axiom #4 – Organizations must provide core competence through APIs

    This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

    The Five Axioms of the API Economy

    This blog post is the fourth in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first three Axiom posted (also see an intro to the series in the first Axiom). The five axioms we’re covering are as follows, in order:
    1. Everything and everyone will be API enabled.
    2. APIs are core to every cloud, social and mobile computing strategy.
    3. APIs are an economic imperative.
    4. Organizations must provide their core competence through APIs.
    5. Organizations must consume core competences of others through APIs.
    Axiom #4 addresses the issue of what should an organization choose to API-enable first and why.

    Axiom #4: Organizations Must Provide Core Competence through APIs

    The fourth axiom contains two core elements. When an Organization chooses to provide APIs:
    • Those APIs should provide substantial value to their target audience.
    • Those APIs should cover the Organization’s core competency.
    In other words, an organization should provide APIs that some other individuals or organizations (customers, partners or the world at large) can consume and find useful. These APIs should generally be related to the organizations core business – and not a small side detail. While these are separate, it’s easiest to understand them together. As already stated in the previous axiom, APIs have the power to generate significant economic value but:
    • This value is only unlocked if a particular API set has a user-base. These users may be customers, employees, third party partners or the world at large – but without a user base an API is a wasted investment.
    • An API is only as valuable as the data or functionality to which it provides access. So if an organization delivers a particular core competence (e.g. shipping, book retail, flight reservations, car hire), it stands to reason that the most valuable APIs this organization could provide link to and drive volume to exactly these core competencies.
    Axiom 4 Graphic Figure 1 illustrates the relationship between providing value to the target audience and using the provider’s core competence when designing and delivering an API suite. Obviously the provider should go for the “Sweet Spot” and develop APIs that focus on the provider’s core competence and deliver high value to the target audience. Anything less will meet with undesirable results. In a theoretical example, a car hire firm may consider two APIs: 1) a data API providing historical trend analysis on US driving patterns, 2) transaction capability to book hire cars from the company’s fleet.
    Both of these APIs are interesting and potentially valuable to someone (and both are worth considering). However, if the organization needs to choose between the two projects the second is clearly more valuable both to itself and its customers, partners. This is because:
    • Transactions on the API drive the hire company’s core business.
    • Transactions on the API help partners/customer carry out the key business with the organization in a new way.
    • The company can safely say it is likely to continue support for the API if it succeeds since it will be contributing to core business metrics.
    For the second API however, while this could certainly be valuable, it represents a deviation from core business. The car hire company would likely not be able to back the API with as much resource. Further, the API would need a new, separate business model. Though this could certainly be welcome if revenues were significant, they would likely need to be very significant compared to the company’s core business. Worse, if the API gets significant traction, costs could rise – potentially forcing a shut down. In other words, this second API is a much more fragile proposition both for the provider and potential users of the API. In order to reinforce this point consider some examples of companies who operate APIs that directly drive their core business:
    • The Walgreens API: subscription filling and photo printing
    • Nike+: social network enabled sports clothing
    • Twitter: read and write tweets
    • Getty Images API: stock photo search in real time
    In each of these cases, APIs form a channel directly onto the company’s core business and if successful will drive more business (which would likely grow over time). This channel delivers a very clear advantage over their competitors since potential partners and customers now have increasing reasons to partner with Walgreen’s, Nike, Twitter and Getty Images specifically. It could even be argued that over time, an API could become the single most important business channel for many companies, since mobile, partners, and product integrations could all tie into a single channel. Interestingly, it has taken a while to learn this lesson. Many of the early APIs that were created by large organizations were offshoots or experiments that were deliberately not related to the organization’s core business. In other words, organizations wanted to explore the impact of APIs but not affect their core businesses – this approach often leads to failure of the API program since:


    Becoming an API provider is driven by one key realization: ensuring an organization’s core competence is available in the simplest form possible for others to integrate into their own systems such that they can become valuable suppliers, customers and partners. Also providers should enable API access to core competence and preserve value to the target audience. Focus on the “Sweet Spot.” Note: This is not intended to be an argument that every organization should have a fully public open developer program. In many cases that goal wouldn’t meet business objectives nor would it provide value. Instead the axiom states that becoming a provider to some kind of audience – typically a subset or superset of an organization’s existing customer base, or a new one they wish to address – is the important focus. A fully public open API is simply the mechanism to reach a particular type of customer base. Up next is Axiom #5: Organizations must consume core competencies of others through APIs.

    The Five Axioms of the API Economy, Axiom #3 – APIs are an Economic Imperative

    This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

    The Five Axioms of the API Economy

    This blog post is the third in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first and second Axiom posted (also see an intro to the series in the first Axiom). The five axioms we’re covering are as follows, in order:
    1. Everything and everyone will be API enabled.
    2. APIs are core to every cloud, social and mobile computing strategy.
    3. APIs are an economic imperative.
    4. Organizations must provide their core competence through APIs.
    5. Organizations must consume core competences of others through APIs.
    Axiom #3 addresses what kind of impact APIs are likely to have. Seen from the outside, APIs may often look like un-important add-ons, but there is a strong and clear argument that economic value is at the core of APIs.

    Axiom #3: API’s are an Economic Imperative

    As is clear from the first two Axioms, APIs provide significant value in a wide range of scenarios: making new types of products and services possible, reducing integration costs or speeding up existing processes. However, It may still appear that the majority of the beneficiaries of APIs are likely to be primarily digital or technology companies like large social media companies or media organizations. It is also difficult to see past the technical nature of APIs to their business value since much of the current debate around APIs is inherently about implementation details, technical architecture and so on. However, APIs are, at their core, not a technical device. Instead, they are a means of delivering or providing access to a service or a product. In other words, the precise technology involved may vary but the essential nature of an API is to provide access to something of value. This in turn means that APIs intrinsically provide economic value. For example:
    • Twitter’s API provides the availability to send a tweet and have this visible to the whole of Twitter’s user base: clear value.
    • Salesforce’s API provides the ability to synchronize customer data with third party tools – making those tools and Salesforce itself more useful: clear value.
    • The City of New York’s 311 API provides the means to report problems to the city managers so they can be addressed: clear value.
    • Twilio’s Telephony API allows the sending of an SMS to any phone number in the world in one line of code: clear value.
    • United States Postal Service (USPS) API. The U.S. Postal Service provides a suite of USPS Web Tools that customers may integrate into their own websites to validate or find mailing addresses, track and confirm mail delivery, calculate shipping rates, and create domestic or international shipping labels: clear value.
    Interestingly, only in the case of one of these APIs is the actual API invocation charged for (Twilio charges per SMS sent), yet they all still provide value – often to the provider of the API as well as the user. For digital native companies such as Netflix, this value is already very clear: Netflix API has evolved tremendously since it’s launch and provides the key meta-data and navigation flow that underpins Netflix players deployed on over 1000 different types of devices. Without the API Netflix players would not be able to nimbly navigate the Video content Netflix delivers or deliver a custom experience on each device. But beyond inherently digital businesses, many more large organizations are deriving clear value from APIs:
    • General Motors: GM via onStar provides a rich set of APIs to control the systems in some of its vehicles. The APIs provide both in-vehicle and remote information and control – enabling third parties to provide new applications and experiences to GM customers.
    • Walgreens: The Walgreens API Program enables partners large and small to integrate and both print photos and file prescriptions – important and valuable services for both the developers writing the apps and for Walgreens itself.
    • Johnson Controls: JCIs Panoptix division amongst others employs APIs to provide access to data and control systems from its in-building installations. This in turn creates a marketplace for new applications compatible with their systems.
    To complete the Axiom however, we also need to discuss whether or not APIs are an economic imperative. This is equivalent to asking –
    “Yes, but how important is this additional value? Can I live without it? How do I compare it to other valuable initiatives I have going (opportunity cost)?”

    While not every industry sector and every player in every sector is in the same situation and hence, the answer to this question may vary. However, there are several reasons to believe that for most organizations there is a clear imperative to deploy APIs:
    • The value created is likely to have direct impact (being able to do new things) and indirect structural impact (making the organization more agile in the future).
    • The value of APIs is often on the top and bottom line: on the revenue side – APIs enable new products and services or drive more volume for existing products/services, on the cost side – integration costs often drop dramatically when API-driven.
    • Many API strategies enable creation of a partner or customer ecosystem – reinforcing the value of products/services with third party additions. This type of effect is often strongly biased to the first few movers in a space – enabling them to grow proportionally faster than their competitors.
    There are industry sectors where no significant players make significant use of APIs, the economic case is clear – once one or more players come out with offerings, they will force transformation amongst all the remaining players. What is without doubt is that APIs are already starting to have a significant top and bottom line effect on a business. It has already become an imperative to leverage their power– just as cloud, social and mobile have become imperatives in almost every sector.


    Proper use of APIs provide clear value. It is economically imperative that organizations integrate well-designed API strategies into their planning and development processes. These actions will provide value to any organizations top and bottom line economic values. Axiom #4 will be coming next.

    The Five Axioms of the API Economy, Axiom #2— APIs are core to any cloud, social and mobile computing strategy

    This is a joint post with 3scale’s Steven Willmott (njyx on twitter). I dreamt up the original idea of the five axioms and we have been iterating since.

    The Five Axioms of the API Economy

    This blog post is the second in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first Axiom posted here (also see an intro to the series). The five axioms we’re covering are as follows, in order:
    1. Everything and everyone will be API enabled.
    2. APIs are core to every cloud, social and mobile computing strategy.
    3. APIs are an economic imperative.
    4. Organizations must provide their core competence through APIs.
    5. Organizations must consume core competences of others through APIs.
    Axiom #2  focuses on the fact that APIs are an integral part of what are arguably the three major forces currently transforming the Web and IT  – The Computing Trifecta—Mobile, Social and Cloud Computing. These transformations have been underway for a while but they are combining increasingly strongly and the effects are still getting deeper.

    Axiom #2: APIs are core to every cloud, social and mobile computing strategy

    Early Web systems were single destinations acting as self-contained silos within which a browsing user could act – consuming information, uploading data or authorizing transactions. Many current systems still function this way. However, while this metaphor functioned credibly for a “human powered” Web, it provides no support for the software-to-software interactions that that are increasingly occurring between devices and web services. As web interactions become more automated, higher velocity and more fragmented (many smaller transactions like sending a tweet – versus large ones  like downloading and browsing an entire web page) software-to-software interactions are a clear requirement for success. Humans in the loop simply cannot effectively keep up with the velocity and accuracy required. Nowhere is this better exemplified than the implementation of what are commonly the three largest Information technology challenges faced by organizations today: cloud computing, social and mobile.

    APIs in the computing trifecta — cloud, social and mobile computing

    “Cloud Computing” is a term used so much that its meaning can often be obscured or misunderstood. It is generally accepted that cloud computing be thought of as a stack of services classes. The three classes of services are Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure as a Service (IaaS).

    Figure 1 illustrates the idea of Cloud Computing being a stack of service classes.


    Figure 1—Cloud Computing Service Classes                                    Source: Burtonian Here is how we view these services classes.
    • SaaS—applications designed for end users, delivered over the web.
    • PaaS—tools and services designed to make coding and deploying SaaS applications quick and efficient.
    • IaaS—hardware and software that powers it all—servers, storage, networks, and operating systems.
    While for illustration purposes, a diagram showing clear cut differences between these classes is useful, in reality the lines between these service classes  is getting blurry and will continue to do so in the future. However, the distinction is still useful in understanding how cloud computing and its services classes relate to APIs. In their earliest incarnations, SaaS variants of cloud started with hosted email, blogging and other tools but quickly progressed to key enterprise applications such as CRMs, HR, accounting and other functions. Many of the earliest SaaS apps began life as a browser based alternative to desktop software – and hence human interaction with the application through the browser was their key use. Modern SaaS apps have evolved way beyond this and providing the means for software integration with a SaaS app for customers and/or partners is table stakes in almost every sector. Further, for PaaS and IaaS layers, the means to integrate with the platform/infrastructure via APIs is in many cases the key driving factor in adoption decisions:
    • SaaS: APIs are crucial for adoption since they enable customers of the service to carry out bulk operations, integrate tightly with other SaaS applications and internal processes, as well as providing an extra level of comfort with respect to platform lock-in. Almost every major SaaS offering is now deploying at least customer facing APIs to permit easy integration. Many also have or plan to have partner ecosystem APIs enabling third parties to develop add-ons and modules that benefit their customers.
    • PaaS: Platforms provide compute, storage, messaging and other services and essentially act as hosted APIs onto which developers can layer their code. APIs for PaaS essentially fall into two categories – those available to the code effectively running on the provided PaaS servers themselves, and those available to push-pull data into and out of the service. This access may be for other parts of the application that are not hosted on the PaaS, mobile applications calling the PaaS or for bulk control, management or monitoring operations.
    • IaaS: Last but not least, as with PaaS services, APIs play a key role in remote access to the infrastructure being provided. In this case most IaaS providers are providing raw compute power, storage and networking as a resource – so application development for code which is to run on the IaaS is often directly using the operating system primitives available (Linux, Windows etc.) rather than some higher level, more abstract API as they do in the PaaS. However the external APIs for bulk operations, control, management, monitoring remain critical.
    In each of these cases, while it is still technically possible to use a cloud hosted service in a way in which everything about the application is hosted within that single cloud service and requires no external integration, this mode of operation is insufficient for almost all significant use cases. Trends in the market also shows a strong correlation between the strength of a cloud service provider’s APIs and their relative success in the market.

    Social and APIs

    Social media has clearly had an enormous impact on both consumer Internet usage and enterprise applications. Facebook now counts more than 1.2 billion users, Twitter 230M, Instagram 15M and popular messaging app Whatsapp was just acquired by Facebook for $19B. On the enterprise side, social integration with mainstream networks as well as “social” features to enterprise products are all now table stakes for most organizations. Diverse examples of enterprise social products include:
    • In-enterprise social network products such as Salesforce Chatter, Yammer and others
    • Code collaboration products such as Github and Altlassian’s Bitbucket
    • Collaboration tools including wikis and task managers
    Social logins such as Facebook Connect, Twitter Auth, Google Login and Github Auth are being used with increasing frequency to manage work related identities for enterprise SaaS products, media access and almost everywhere that a user login-in is required. A third dimension of social surrounds the gigantic amounts of data that are produced by social media applications. Companies such as GNIP (now part of Twitter) and DataSift have sprung up to process the real-time streams produced by large social networks. Other companies such as Marketwired’s Sysomos, Radian6 (now part of Salesforce), and Klout (now part of Lithium) analyze these data flows and provide value added aggregate information on top. As user behavior continues to reinforce the growth and importance of social media and the value of enterprise social increases, companies and individuals are compelled to include social integration options in their own workflows and products. Such an integration or addition requires the use of APIs – either by integrating APIs provided by third parties or (in the case of products with a social dimension) providing a new API. At their core, social systems provide a range of key functions:
    • Messaging and notifications
    • Media sharing
    • Collaboration
    • Search and monitoring
    • Data aggregation
    Each of these functions can be a means in itself (a discrete task carried out by an individual) or part of a large workflow:
    • Tweeting out the result of a process, or arrival of a new piece of content or an opinion or comment
    • Pushing out a Facebook post when an Instagram photo is published
    • Updating a Github work ticket when a software integration test passes
    • Regularly search on the same set of keywords for mentions of a company’s brand
    • Tracking statistics of certain behaviors across different social networks
    As a social strategy evolves, it invariably requires processes to be established and made replicable. Hence APIs become central as these small individual actions are strung together into a larger flow. In other words, the bite-sized nature of many of these interactions make them key components in larger processes. In a similar way, any new product with its own social features (e.g. a new code collaboration tool) will quickly run into the need for integration with existing other tools in the workflows which are already established. As a result, an API becomes an indispensable part of the product. Conversely shipping a product with pre-existing integrations to the APIs of other tools in the workflow is a major added value for a product.

    Mobile Computing and APIs

    For the final category, it goes without saying that mobile is a huge driver of API adoption. However, it may not be 100 percent clear as to why this is so for an individual company – after all, it is rare that an organization sets out to build an API if their focus is putting an application in a user’s hands. However, APIs are at the heart of such projects since they provide the server-side synchronization point with which applications communicate. Going back to 2008 and the launch of the iPhone with the first generation of apps, and even further back to early feature phones Blackberry and  Palm Pilot, the vast majority of apps were software that ran in a self-contained manner on the mobile device. In other words the app’s value was solely in the software executing on the device. Through 2009, and to this day, a continuing transformation has taken place in that almost all meaningful apps are composed not only of software executing on the device, but also server-side services that provide support services. Everything from backup to live data or ecommerce transactions functions this way. This server connection requires an API to receive and respond to traffic. With the rise of Android and the proliferation of the number of device types that can run mobile apps, there are often many versions of a mobile app that are available at any one time – all of which need to be able to access server-side components. A modern mobile strategy is therefore increasingly like the one shown in Figure 2, with an API-driven core and a wide variety of different clients calling the API. Platform Figure 2—API Driven Platforms Power Broad Mobile Strategies Source: 3scale These trends in APIs are likely to be at the heart of many of the major strategic IT initiatives most companies have planned. This is becoming increasingly true as the number of end devices, operating systems and frameworks a given company wants to deliver mobile functionality to also increases, and so the value of an API increases rapidly if it can be shared by different clients.


    As with the first axiom, the truth of this axiom may seem obvious – but this is part of the point. APIs are often “in the picture” of transformative strategies in mobile, social and cloud, but rarely mentioned. Every organization is evolving strategies to deal with the Trifecta—cloud, social and mobile computing— and these come in varying shapes and sizes. However, it is critical they they be viewed from a perspective of being API-centric, since APIs are a key glue which make each of them stick. Axiom #3 will be up next.