This post was originally published here on October 29, 2018 on ProgrammableWeb.com.

We thought we started a software startup. We were wrong.

I’ll explain. It was 2011. Like many soon-to-be founders, we were getting frustrated with the inefficiencies of our day jobs.

Our specific frustration was with everyone’s favorite email app: Gmail. Google designed Gmail for users to add and move attachments using Google Drive, but in reality, their users had Dropbox, Box and other services in their cloud storage tool belts.

Since Google wasn’t going to support their own competitors, we saw an opportunity to make Gmail and other cloud services play nicely together.

We made an extension that sat seamlessly within the inbox and let Gmail users select any cloud storage service they wanted to move or attach files to their email, without exiting their inbox. And voila! Kloudless v1.0 was born.

Then came the hiccup. To keep our product running and make customers happy, we needed to keep building more integrations and keep interacting with a lot of storage service APIs that all differed from each other. Many lacked features that we needed. What’s worse, they continually changed, updated and broke our integrations.

We became an integrations shop instead of a software company.

At this point we couldn’t stop. Did we have a choice? We were an early-stage startup after all. Customers would say that they’d only use our product if we added a new integration.

So we built them. Our CTO shaved off his mustache. The funny business and along with it the fun, was over.

Things got worse before they got better. On a Friday afternoon, Microsoft changed its API without notifying anyone. It made an update that wasn’t backwards-compatible with the Sharepoint API we’d been using and just like that, our integration was broken.

At first we wondered, is this a problem with our system or theirs? Our three engineers figured out that Microsoft had made an update and they scoured the documentation to find which code we’d need to rewrite to make everything work again.

An abbreviated release cycle later, our product’s integration was working again but we were thrown off our roadmap. The fix had side-tracked our engineers from their regularly scheduled programming, turning them into integration minions.

Fast-forward to 2014. We sold our Gmail extension. Our slog through integration hell opened our eyes to a much larger problem that needed solving.

Each Enterprise department is a special snowflake, building its own application stack for its users’ particular needs. For example while Sales uses Box and GCal, Sales Operations uses Dropbox and Outlook, while Marketing uses OneDrive and CalDAV.

Meanwhile each of these cloud services has little care for how its product plays with other products.

When these systems fail to talk to each other and product integrations stall or break, at the end of the day it’s the end-user who really suffers. To further complicate matters for the IT teams serving these users, amid the new-age software takeover, legacy software and the need for some on-premises management continue.

A Glimpse of the Future

Everyone should get along in the playground. In the future, every software provider’s service would come with integrations out-of-the-box. Data would flow more freely because cloud services get along from the start.

What if centralized integration services – the Dell Boomis and Zapiers of the world – are getting it wrong?

The Status Quo

The overloaded and shrinking IT Team dilemma is not new. Thousands of companies aim to ease this pain. How is the decentralization of iPaaS going to break ground here?

First let’s review how we got here:

1980’s – Big Hair, Big IT Teams.

They build connections between internal systems and other endpoints like servers, computers, etc. All on premises. External help takes the form of systems integration services (i.e. a dozen outsourced engineers) who come onsite and manually build out integrations.

 

2000s – The Onslaught of iPaaS.

IT manages on-prem or cloud software (think Workato, Jitterbit) that performs the bulk of their integration work.

 

The Evolution of iPaas

And where we’re going

The Future – The Application Network.

Each product has plug-and-play connectivity with every system and service, saving IT from app orchestration and workflow set ups.

The evolution comes in the form of every cloud service having their own mini, built-in iPaaS, which means apps from disparate cloud services support integrations with each other. IT Teams avoid tedious integration work and end-users have better product experiences.

And at the risk of ruffling some feathers, I have to point out why cloud services with their own integration platforms will do a better job than the centralized integrations-as-a-service.

The key is that each cloud service has its domain expertise – for Dropbox it’s storage, for Uber it’s transportation. Who better to provide that specific connectivity than the experts in each field?

Or would we rather a Science School’s Dean, with all due respect for his PhD in Organizational Development, teach the Advanced Astronomy class? I would hope not. Let’s give credit where credit is due and put a pro stargazer where she or he belongs.

In other words, decentralization of integration services needs to go a step further so that the apps themselves provide all connectivity. It should be a given that cloud services play nicely together, freeing up enterprise IT to focus on providing business value on top of the connectivity.

In a sense, we are moving beyond the developer. We’ve isolated the integration work and now we’re free to take it a step further by directly delivering the best connectivity for end-users’ unique needs.

What’s at Stake

And what if we don’t take this leap into decentralization?

Personally, I picture myself back in the shoebox office coding and recoding for hours. I picture the many cool products that will never reach the virtual shelf because we’ve spent all our time unraveling the same spider webs among our services.

If you’re a developer, you could picture a Cyborg-esque transformation in which you slowly become part of a whole race of integration robots, with every new application feeding a steady drip of tedium, obligation and dread. And if you instead offload the integration burden to the end-user, you’re contributing to a dystopian landscape of dysfunctional workflows, riddled with gaps in functionality and deprived of engagement.

A New World

Developers and IT professionals are practical beings, happy to grab the code they need in the short-term to solve a problem that matters to their stakeholders. But they’re also innovative beings, with dreams of designing flexible and future-proof structures that scale. In the future, the best of them will have stopped trying to solve integration problems and started using solutions that launch easily and last.

These techie heroes will take for granted that the business applications they choose deliver complete connectivity. That’s because each of those applications set up Kloudless – a “playground enforcer” of cloud services – from the start.

In this future Utopia, there are no integration robots, but for the next generation of technical know-it-alls, out-of-the-box connectivity is a no-brainer.

About Kloudless

Kloudless is the go-to platform for enterprise software integrations. Businesses use Kloudless’ unified API products to connect to many kinds of enterprise applications such as Salesforce, Box, Dropbox, G Suite, Slack and more. With Kloudless, developers can stop building tedious and expensive one-off integrations by using Kloudless to build once and integrate many. We are trusted by more than 15,000 developers in over 4,000 organizations.

Kloudless is backed by top tier investors including Aspect Ventures, Alibaba, Vivek Ranadive (Founder of TIBCO), David Sacks (Founder of PayPal, Yammer), and Tim Draper (investor in Box, Tesla, SpaceX). We are also a member of the Heavybit Industries, a community of developer-focused companies, founders, investors and advisors.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.