19 Comments

Summary:

The arms merchants of the cloud and a new wave of developers armed with APIs are going to cause massive technology disruption.

Screen shot 2013-11-21 at 4.22.47 PM

There is a war coming soon. The arms merchants of the cloud and a new wave of developers armed with APIs are going to cause massive technology disruption. And APIs are the ammunition fueling this change.

Antony Falco described recently how developers, armed with APIs, will radically change enterprise IT. Everything from banking systems to payment platforms, from airline systems to e-commerce platforms, from automotive systems to medical devices, will all soon have developer API access and it’s going to turn our world upside down.

 What impact will this proliferation of APIs have on product development, competition and how we approach software engineering?

Micro-SaaS APIs & Pluggable Features

SaaS is the fastest growing software industry we’ve ever seen. There are more than 2,100 SaaS companies today in a market expected to grow to $120 billion by 2020. By 2015, 85 percent of all new software is expected to be SaaS.

Today, SaaS companies generally deliver a complete product or broad layer of functionality via the cloud – like CRM or billing. However, as more and more companies focus on building APIs we’re going to see a new type of SaaS company emerge that focuses on micro features that they do really well. Imagine a payment company that solely focuses on an API for high speed payment transfers or a travel company that provides an API that can notify you of hotel rooms opening up in your area in real-time or an insurance company that has an API offering a low-cost car insurance policy whose premium drops in real-time based on your good driving behavior captured from a device connected your car.

These micro-features do something very specific, very well, and other developers will want to incorporate it into their products to build even better applications. This will also fuel something else, Disruptive Applications.

Disruptive Applications

As APIs proliferate, a radical new business model for building applications is emerging. One where companies and developers choose micro features via public and private APIs that can be integrated and discarded with relative ease.

As easy as Amazon Web Services has made it to provision new servers, leverage storage in the cloud and integrate large-scale search into your application, APIs will make it as simple for developers to build new applications, both inside the enterprise and in the cloud.

Not only will it be easy to get a new application out the door, it will be cheaper and faster. We will see a whole slew of micro-startups emerging who are able to deploy new applications on the web in days or weeks, not months or years.

These companies will get MVPs for their product idea out the door in record time and be able to test the market with minimal investment. They will cause a never-ending stream of new competition.

Companies that already have a lot of IP and technology built up will assume they have huge leverage over the competition, including startups competing against them. But it will be a fallacy as all this “pre-existing IP advantage” quickly evaporates in an API-driven world. A startup can just plug-in and swap-out features with ease from other vendors and get a feature-rich product out the door at light speed and adapt it to market changes even quicker. Now the startup has the clear advantage.

Companies that don’t have API strategies in place will feel the pain and quickly fall behind.

Arm Yourself

How do you arm yourself to succeed in this new world?

Companies will need to migrate their existing platforms to be API-enabled and open them up to developers.

The approach many companies are going to take is to just put an API on front of their existing systems. However, slapping an API on top of an existing system and calling it done will not be enough. Companies are going to have to retrofit and redo the plumbing beneath these APIs. Many underlying issues that aren’t currently obvious or visible will show up when exposing your product functionality via an API to the outside world – security, versioning, latency, scalability, QoS, flexibility, etc.

To compete, companies are going to have to go further, dig-deep and refactor their underlying architectures to be in the same end-state as the startup that started from scratch. They will need to have the same flexibility in place in their final product as the startup does, one that allows them to plug-in other best-of-breed vendor APIs as necessary. If not, they simply will not be able to compete.

This remodeling work has a name, it’s called API ReModeling or ARM. It’s an initiative your company and engineering teams will have to take to reshape your APIs and retrofit the underlying foundations of your platform to allow easier integration with APIs.

Companies will need to start putting these API strategies in place now and start acting on them sooner rather than later. Start by ramping up your development teams to think API-first. Start visualizing what your platform would look like if you were to design it from scratch today without any constraints and make it flexible enough to be able to easily plug-in third-party APIs, especially in those areas that don’t provide any differentiated product value.

Start arming yourself today for the upcoming API wars.

James Donelan is VP of engineering at MuleSoft, provider of the world’s most widely used integration platform. Follow him on Twitter @jdonelan.

You’re subscribed! If you like, you can update your settings

  1. Reblogged this on Grandiose Data Delusions and commented:
    Another article of great relevance from GigaOm. The API revolution / evolution is well under way and the pace is picking up… Fast.

    I think that in addition to the vendors offering API access into their environment, the vendors of not just development tools like Mulesoft, but integration enablers like IFTTT and Zapier and apigee will be part of this coming technology singularity.

  2. There’s an app for that remodeling part, right?

  3. Interesting article James. I’d be interested to know who, in your view, is doing this or has done this really well to date. Or maybe even a sector where this API-centric development philosophy is being more rapidly adopted?

    1. Hi Will
      There are some great examples out there, especially in SaaS and enterprising software companies like Twilio, Stripe and others. Of the more established companies, travel giant Expedia took a travel website and turned it into an API-driven technology platform that now supports 5,000 developers and accounts for over half it’s revenue – $1.5 billion. Just last week SalesForce announced Salesforce1, a unifying API wrapper around everything Salesforce.com offers. On the consumer side of things, Twitter’s API handles over 13 billion API calls a day and there are over 9 million applications built on the Facebook Open Graph API. Neither of these companies could have built out the application ecosystems they have today without having great APIs in place. BTW, I wrote a bit more about this here http://blogs.mulesoft.org/the-hunt-for-the-perfect-api
      – James

      1. In addition to James’ examples of external APIs, there are existing examples of companies that have adopted an internal API policy and rebuilt their application tier as fine-grained services. Netflix, Twitter, LinkedIn, have all given talks on their internal initiatives to transform their systems architectures from monolithic tiers to services with internal APIs. More details at: http://nirmata.com/2013/11/rest-apis-part-2/

  4. Nobody builds a robust, maintainable, large and complex, flexible, corporate mission-critical system relying on the nebulous and often changing (and breakable) API’s from 3rd party vendors. Speaking as a software dev of 40 years experience, this article is total bullcrap.

    1. Tobechukwu Nwanna Jeff Monday, November 25, 2013

      Yeah really, Jeff. I actually had this very discussion with a friend of mine as we’re both working at startups and are both the primary backend developers for a good portion of our respective platforms. The way I see it is that you have to judge the benefits of both sides and decide which is best for you.

      On one hand you have internally developed proprietary software which has the advantages of being highly flexible, tweak-able and familiar as you wrote it. However, it has the disadvantages of requiring dedicated resources to fix, and update as new features need to be supported.

      On the API side you have the advantages of not having to dedicate resources to and not having to worry about it being up to date feature wise, with the only disadvantages being less control. Your “fear” of 3rd party APIs being “nebulous and often changing (and breakable) ” is only partially true as API providers of popular features are pretty vigilant when it comes to maintaining backwards compatibility unless they absolutely have to change it and if the features the API supports are often changing you’d also be changing whatever proprietary support you have as well.

      Basically, the way I look at it, and I’m sure other startups do, is that when you use an API you essentially have an entire other team dedicated to just that one aspect of your web app and that’s a huge deal when your team is already small and busy working on other aspects. While big companies don’t necessarily have that issue, considering how badly managed most tech companies are, it would probably benefit them to become leaner and start adapting a similar mentality

    2. Jeff, I am keen to hear your thoughts on alternatives.

  5. Jeff,

    You sound like the people 10 years ago that said Cloud was bull crap.

  6. Good article.Apart from the image of the non -sexy -fat-ass sumo wrestler that ruined it.

  7. Prediction – lots of 3rd party APIs, none compatible, from startups that come and go. Mass chaos and management headaches as lots of quickly built webs of loosely coupled software start to exhibit failures due to those startups going dark.

    Later, a review body will begin rating these APIs and allowing user rankings, bringing sanity to the web of APIs. The hype dies down and it’s another strategy that people can leverage.

    Goal: come up with a plan to manage risk in the cloud when you have 25 different service providers that can go under, change pricing, and have network problems during the course of a year. I don’t think anyone in that position can come up with anything that has predictability at all.

    +1 for Jeff’s point of view for enterprises. Startups will tolerate this because their apps will become quickly composable, and disposable unless they get purchased and funded to re-write their software to be more reliable and controllable. By then, probably in what surely will be legacy Node.js :)

    Ken

  8. Jeff, Ken and Tobechukwu may be right. The history of the web is lots of innovative noise, followed by a period of adjustment as those players that can only burn but not add to capital disappear. What is left are those success stories you want to integrate with, and generally the mash-ups and integration piece is not the hard part. The hard part is choosing the right SaaS partners. Those that are going to add value to your business, and be around more than a year or two and not gobbled-up and neglected by the monoliths.

    Another problem, with API’s and standards, everyone has their own. Why? probably some misbegotten belief that there is commercial value in uniqueness or just plain ignorance and stupidity. Have been pursuing pretty solid standards for years, but very few vendors bother to oblige. Of course, the giants like Google Apps will oblige by making things simple, because they want your data passing through their system, its “gold” to them. Some interesting tool providers with some attractive propositions ranging from web robots, to screen scrapers to API automation and similar propositions get a nod from developers, and then they get swallowed up. Staff get pee’d off and leave, and the new owner is left with some pretty hard decisions…sell off, scrap, or invest in what they largely don’t understand or if it is any good, turn it into a cash-cow until something new comes along. Cynical yes. But been around long enough to know that business, innovation and technology are uncomfortable partners.

  9. This thought is one of those concepts that work in theory but not in reality, when you are in the SAAS space you want your customer to have a continuous seamless product, API’s do not do this, every company has its own interface, data transfer, who holds and owns the data when these companies dissapear, the user experience is not great, the communication between different companies is not great, eg say you have product y and 50 companies want to connect with you but they need a bit more integration and they need you to do a bit more with your software to make a nice product, of your 50 companies which one do you focus on, and you now have 50 APIs to maintain.
    EG stock control, everyone has requirements for stock control.
    The more likely scenario is niche software that is narrow, vertical and very deep.

  10. +1 Jeff
    Unless you’re a startup that just wants to get a product out the door to show investors you just cannot build a viable app were you use lots of 3rd party micro-apis. Imagine you come up with the best UX for CMR and you start integrating APIs for billing, customer support, emailing, calendars. Nothing is proprietary, just your beautifully crafted UX. The model for this type of business is “wait to be bought or go to the next big idea”.

    If you are a small hosting company with a few hundred clients, sure, you can get away with building your user account management interface with 3rd party micro-apis but not if you’re Rackspace. On the other-hand, if you’re a small hosting company you already have fully functional apps for account management that doesn’t have ALL the features and you still can get away with it.

Comments have been disabled for this post