The Software Connectivity Conundrum: Why We Started Blended Edge
I’m coming back to Medium to share ideas about software integration and SaaS from my voice.
Our company blog is the company’s voice and the company’s perspective, and it’ll overlap with mine in a number of places. I’m the CEO/cofounder. It probably should, albeit not exclusively.
This will be my channel to prognosticate as me — to discuss the challenges that ultimately inspire our business. To discuss the problems we seek to help our customers solve.
I thought it would be fitting to start off with the fundamental reason Blended Edge exists: solving the software connectivity conundrum.
What is the software connectivity conundrum?
The term “connectivity conundrum” is not mine. I’m not even sure it’s anyone’s, frankly. But, I’ve seen it used in a variety of industries including healthcare, education, finance, and of course, software.
In software, most issues of “integration” or “connectivity” center around the user. Ultimately that's understandable, but trying to solve the user’s need at the user’s level is pretty inefficient. There are a lot of users in the world.
Less focus is placed on what connectivity means to the producer of the software that the user is using. Solving it at that level inherently solves it for all of the users of that product. It’s a value lever.
Here’s how I think about what the the term “connectivity conundrum” means to a software company…
To build a successful software business, you are required to build digital experiences that enable your user to do their job faster, easier, cheaper, more effectively, or whatever (the word “job” being used loosely).
It is not possible for you to build software that literally does everything for your user, so there will be many instances where your user will need to combine your software product with another to do their job.
This is is a cross-product user experience.
These cross-product needs will fall somewhere on a spectrum of marginally useful to nice-to-have to really beneficial to absolute requirement. Your user gets to dictate where any given cross-product experience may fall.
To deliver maximum value to your user, that means you must understand and enable cross-product user experiences, in addition to the experience within your product.
If you don’t, eventually your competitor will.
This means that you need to understand what experiences your user is trying to bridge with other products, with what other products specifically, what the value of that experience is to your user, and what their pricing threshold is for such an experience.
In technical terms, you need to figure out which other software products you must enable your product to share data with in service of your mutual users’ needs. Fundamentally, this is software product integration.
Product integration requires that you create a collaborative “product” relationship with another company with its own goals, shareholders, and perspective of the world. It requires that you work together to deliver the cross-product user experience.
Back to the technical level… It requires that you architect features that share data, often bidirectionally, often in real time, often in large volumes, and always with a low tolerance for failure, collaboratively with that company’s software product.
Software integration is challenging engineering work. Challenging means time consuming. Time consuming means expensive. No one wants to do expensive things.
As a producer of software you are (more than likely) not a software integration company. Your investors didn’t invest in that. Your employees didn’t sign up for that nor are they experts in that. Your customers don’t really want you for that.
But, because of what your customer demands of you — helping them do their job, even across software products — you are required to figure out a way to be really good at software integration.
Thus, we come to the absolute basis of the software connectivity conundrum…
Software integration is hard. Being good at it doesn’t really add fundamental shareholder value to your company. But, if you aren’t good at integration, you cannot maximize the value of your product to its users nor your company to its shareholders.
Rock. You. Hard place.
Why isn’t this solved?
Software isn’t new. Integration isn’t new. User experiences aren’t new. Customer demands that pay no mind to the boundaries between two companies isn’t new.
Surely, someone has solved this problem, right? Turns out the answer is “not really”.
This article from CIO Magazine, getting damn near 20 years old now, talks about using Enterprise Application Integration (EAI) tools to help enterprise users connect the separate software products they use without having to write cumbersome, custom integration code. Sounds great, but…
Over these two decades, we’ve cycled through a series of terms to describe this kind of third party integration software, including Enterprise Service Bus (ESB), automation platform, extract-transform-load (ETL) software, and most recently, integration platform-as-a-service (iPaaS).
Side note: Before the data people get on my case, I know ETL is a bit of an outlier in that list. I’m thinking about “integration software” fundamentally: take data from here, put it there, times a lot of data.
These products are third party “middle men” that deal with connectivity. They are data pipes. You don’t buy them without buying the two things that need connected. And, data integration is hard, so what else are you to do?
All of these software products claim to make it easier for the user to connect the systems they use. All of them overcommit (to varying degrees) to how easy it is. Most importantly, all of them are not solving the fundamental problem.
Users don’t want integration! Users want seamless cross-product experiences.
The problem with how the vast majority of software integration experts have tried to “solve” the connectivity conundrum is that they are doing it for the wrong stakeholder.
Software connectivity should be the software producer’s problem.
Software connectivity (integration) should not be the user’s problem. It should just work, so they can just work. It should require the least possible critical thinking, requirements management, and budget from the user.
That means, it’s the endpoint software producers’ problem — the teams that make the software that must be connected.
Back to conundrum: it’s hard and it’s not that software company’s core value proposition.
That’s where we come in.
Our reason for being is to build software products and offer services enabled by those products to help any software company who faces this challenge (hint: all of them). We set out to make you awesome at building software product integration without you having to go through the gauntlet of figuring out how to be awesome at it.
We also do it in a way that is economically advantageous for your P&L. We don’t lock you in to a “forever” vendor relationship. We make sure you build to own your integrations — not rent them. Most importantly, we focus on empowering you to empower your customers.
We know integration is hard for everyone. Users hate integration projects. Trust us…we’ve done plenty of those projects.
If we can help your company alleviate that pain, it means we also do so for the tens, hundreds, or thousands of customers that you serve. That makes you, the software producer, more awesome. That makes us happy.
Software connectivity is a goofy problem to contend with. It’s nobody’s fault. It just is.
But, after multiple decades of not really solving this problem, it’s time that someone solves this problem.
We’re going to take a shot at it.
