Making mobile apps is not the developer driver it used to be. When it comes to monetizing the API space, the trend is towards enterprise hybrid cloud apps and platform agnostic products.

Instead of chasing microsales in app ecosystems controlled by the major players, dev shops and internal teams are building service specific applications that focus on traditional economies scrambling to modernize.

In other words, they’re going after deeper pockets.

Fintech, health, and manufacturing applications usually depend on localized data sources, and now, these companies are trying to find ways to leverage that data in a secure and effective way. They’ve embraced a public presence and are offering versatile and multifunction web apps instead of old school, locked down portals.

One approach is incorporating external APIs to handle services and resource management in ways that don’t expose the internal systems. In the recent past, that meant tasking a dev team with programmatic integration and aggregation of third-party APIs.

Integration platforms came along, sniffing an opportunity. But, what started out as mashup tools and feature directories has evolved into large scale business service platforms. Essentially, API management has gone enterprise. That’s the trend we’ll study today — we’ll look at four players that have evolved (or not) their integration tools into platforms.

Cloud Elements

Service-as-a-service

Cloud Elements is a company that uses the API mashup (one-to-many) concept to provide a comprehensive set of connections to mainstream cloud based business services.

Their primary strength is the ability to connect well known cloud services into business workflows that yield singular and consistent APIs. If you need to bridge the Salesforce API to the Kissmetrics API, this is the sweet spot they’re going for.

Under the hood, they are routing API requests and events from these services into novel APIs that yield their own documentation and portals.

You can add custom APIs, but a look at the categories of services they integrate tells the real story. They are: cloud storage, help desk, customer, messaging, marketing, finance, social, e-commerce, human capital, infrastructure, planning.

Notice a pattern? These are all business services, not consumer features or utility sets. You wouldn’t use Cloud Services to build an app that reads your tweets in Yoda’s voice. In fact, there is a whole new breed of dev shops that have pivoted from custom development of internal services to being business workflow consultants.

It’s a similar knowledge base but the need for deep engineering is much lower. If you want to do anything specific or custom, you’ll still need the coding chops. But, ramping up to a viable solution is potentially faster and more consistent.

Cloud Elements focuses on direct service connections instead of API metadata entry. Setting up an “Element,” or external API, is done through a login screen to the external service. The platform sets up the metadata for keys and paths.

It’s the kind of process a Product Manager would be more comfortable with, as opposed to needing an engineer to intervene. They emphasize that it’s still APIs underneath, which probably appeals to decision makers trying to satisfy both product and engineering teams.

Mulesoft

As big as a horse, but strong as a donkey

Mulesoft has quickly mutated from a humble API connection utility written by Ross Mason into a major Silicon Valley company. The platform aims to be an entire ecosystem of API based application services. It offers API design tools, analytics, security, dev experience portals, documentation, API management, and more.

There is a marketplace for finding predefined ways of accomplishing common connections and workflows. It’s similar to Cloud Elements, offering cloud application connections. But, instead of just yielding an API to build an app on, the platform has very deep tools for building the application itself.

For example, Mulesoft has a full suite of IoT connections and templates for building consumer facing IoT apps that also work seamlessly with backend business services.

Where Cloud Elements has focused on business workflows, Mulesoft has expanded its scope to incorporate multi-tier consumer and industrial services. But, to do that you’ll need to deploy Mule tools to your devices and applications. That’s an engineering strategy call that companies would end up facing if they go down the Mulesoft path.

For those companies that don’t have the luxury of retooling their systems for shiny new features, legacy integration will be the middle ground. Mulesoft addresses this in its marketing but is a bit shy about explaining the technical aspects of exactly how they do it. I imagine it involves custom work from their teams.

Who are they targeting? A company with currently existing API usage with enterprise business services like Cisco, SAP, and Oracle would be Mulesoft’s target audience.

DreamFactory

For a more DIY approach

DreamFactory offers an interesting approach to integration and legacy data sources. They’ve created a platform that runs locally and yields an API suite from many different data sources.

Recent updates include ways of integrating third party APIs and defining certain workflows, events, and triggers. It’s much more of a development environment than the GUI rich dashboards of Mulesoft and Cloud Elements.

But, what it’s doing under the hood is powerful and may be of interest for many industries that can’t (or just don’t want to) transport their data or only want to expose very specific data sets for interaction.

Not everyone can move their data into the cloud. Industries with legacy data sources that are constrained by technical debt or legal constraints seek limited means of exposure through targeted APIs. DreamFactory is one of the only solutions that allows companies to keep their data localized, but with extensible APIs that can be integrated with third party APIs within the same platform.

It also works with a huge range of data sources and databases. That’s something that would take custom development for a lot of other platforms. A healthcare company needing an API for their internal database to use with external service would be well-served with this platform.

Mashape & RapidAPI

How much longer will Yoda speak?

One of the early attempts on capitalizing on API mashups was Mashape. It began as an API mashup directory of sorts. It morphed into an API marketplace and tried to monetize the aggregation of services.

The marketplace still exists, but they have pivoted to offering lower level tools as individual platforms. They can be consumed as a unified offering from Mashape, but are offered distinctively as Kong, Galileo, and Gelato.

Last year, RapidAPI absorbed the Mashape API marketplace in an effort to expand its API hub. Combined, they offer 7,500 APIs. A dive into the current directory yields offerings of mixed usefulness. For example, it’s unclear how much longer APIs offering text translations into Yoda speak will be needed.

What’s more interesting is the structure they’ve built for the marketplace itself. As more companies go “API first,” the distribution and marketing of those APIs will become a new battleground. They’ve staked out a hill early in that battle.

As far as Mashape is concerned, it’s pretty clear that they are trying to grow beyond brokering services to individual app developers/teams and into more enterprise offerings, such as Kong. This follows the trend happening across the API space.

RapidAPI is now a large API directory service. Traditional, feature-based app developers making consumer facing mobile apps could make use of the wide variety available. But, now that the marketplace is decoupled from Mashape’s Kong, it lacks the backend capabilities for providing a true integration platform.

The Takeaway

The initial surge of interest in novel, feature based APIs has begun to wane. The idea of creating a mobile app that makes money in an app store is far less interesting than creating a service or utility that can be used to iterate many apps.

You can see it in the amount of companies that get bought for a particular tool or approach they created (or acquihires), as opposed to an actual product that was made. Today, those apps are a distant priority compared to the technology and userbase they ended up with.

Google absorbed the API manager Apigee, despite having enormous API development resources of their own. TIBCO bought API manager Mashery from Intel to integrate its deep portfolio of enterprise customers dealing in Fintech, international shipping, and much more. Enterprise player Red Hat scooped up the API gateway platform 3scale to augment its own middleware tool chest.

Also, internal teams at larger companies are being tasked with niche apps and multifunction app-like services that can be consumed on many different platforms. Beyond just mobile or web distinctions, applications are being built as API service platforms, independent of any particular consumption platform.

Axway filled out its API lifecycle offering with the acquisition of Appcelerator (Titanium). They’re an example of the move towards courting internal enterprise needs instead of arming app store warriors. Axway offers enterprise customers more of a closed ecosystem, in contrast to the open integration efforts of other solutions.

Integration platforms and services are catering to this movement and shifting away from just app development and towards enterprise business needs. We’ll see more and more companies whose product is a customized business API collage, instead of distinct public-facing apps.