5 reasons I will never buy an iPaaS

July 9, 2021

There's been a surge in something called an iPaaS: "Implementation Platform as a Service''. Basically, service providers figured out that big companies are comprised of a large number of moving pieces that need to coordinate in specific ways. How does the sales data from the webstore get funneled to the accounting system? How do we verify the sales totals against the credit card processor and the bank account? How does the inventory data flow between the warehouse, the webstore, and the ERP? When we sell a unit with a warranty, how do we associate the serial number with the customer? When we onboard a new employee, how do we create an employee ID, email account, and invite them to our services?

The iPaaS sector makes connecting between these different data silos faster, enabling workflows and automations to answer those questions and millions more. To some, these are the relatively mundane details of running a business. I feel for those people, I really do. Because I think they are missing out.

To those of us on the inside, these systems are the very essence of the business– they are an opportunity to find new efficiencies. Deliver better customer experiences. To understand the levers that control the business. This second group understands that how well these systems are built and maintained are tightly correlated to the overall success of any organization, and someone with mastery over them will have a long and lustrous career. Someone that masters these operational controls is respected, always has a seat at the table, and is the person the whole room turns to for buy-in when big new ideas start talking implementation.

To anyone that's been at a company through an ERP integration, they know very well the catastrophic consequences if the systems are compromised or go down. You can tell if someone's lived through this because when you mention the platform's name, they get a distant look in their eye, like they've seen a ghost. A bad ERP implementation is memorably painful. Ask them about a good ERP implementation and they'll pause, reflecting finally with, "does such a thing even exist?".

At my last company, we always wrote our own apps and services to handle these operational tasks. They should have been small, free-standing connectors between APIs, bouncing data around to the place it provides value, with great reporting so anyone on the team could understand how it worked. But, too many of them were esoteric corners of our monolith that chugged along quietly, until some problem came to a head and an engineer had to become an expert for a week or two, with lots of emails and meetings to tease out details of what it was supposed to be doing, as described by whoever actually used it everyday. We were a software startup, so I felt that if we didn't own our code, we didn't own our business. That said, it's hard to look at pitches from companies like Workato and Celigo and not get lured into the vision of a brighter pasture– why write all that messy, expensive code? Just click and drag and you'll be on your way! It's tempting.

Here's where those solutions break down for me:

  1. You don't own your source code. This is a dealbreaker; I want to have control over my business down to the bones. In some ways, this fuzzy-feeling-turned-hard-rule is a summary of all the rest of the points.
  2. Lock in. Transitioning your business rules to any system is a big company-wide lift, and doesn't happen often. As a customer, this makes me feel vulnerable because the vendor *knows* they are hard to fire, and performance may suffer accordingly.
  3. Future proofing. I can't predict what needs we'll have in 6 months, let alone the 5-10 years something like an ERP will be installed for. I need to know that whatever we choose, it has the flexibility to not block the projects we'll want to launch down the road.
  4. Extensibility. At my last company, we didn't just want to flow data between services for ourselves, we were often doing this on behalf of our customers. This means a whole extra dimension of complexity around user privileges, security and white labeling. I worried extra friction here would make our product materially worse.
  5. Cost. The platform you embed your logic in has you in a somewhat vulnerable position; if the platform suddenly decides to double prices, what options am I going to have? These things take months to implement and cause no small amount of strife. Perhaps today's management at the vendor would never do such a thing. But on a long enough timeline, the chances that a short term, profit-motivated operator will take control are high enough to be considered.

Does that mean we can't benefit from some of this point-and-click, so-simple-your-intern-can-program-it UX? Hardly, and that's where things get interesting. There are a few requirements you'd need to have to turn these concepts into something I'm willing to bet my career on:

  1. Source control. Click-and-drag all you want, but deliver the source code so I can see every line for myself. I don't have to write the code, but I do need my engineers to review it.
  2. Make more experts. Give the people adjacent to the dev team great reporting and debugging tools to get more brains on how the data actually flows and which fields matter. Stop playing telephone, asking the dev or data teams how the schemas interact.
  3. Safe releases. Default to development, staging, and release-based branches. Transition these to production in a phased rollout. Teach the team what kind of tests matter, make them dead-simple to write, and make sure they pass before going to production. And it goes without saying, but make them easy to roll back in the event that everything goes sideways.
  4. Portability. If we're going to make a major investment inputting our business rules somewhere, we should store that logic in as portable a format as possible. We've chosen JSON, which we compile into Javascript. In the future, we'll compile this to other languages, and there's nothing stopping someone from writing their own compiler.
  5. Security. I hope this goes without saying, but for the love of all things good, follow best-practices for security. At the most basic, encrypt sensitive data at rest, offer detailed user authorization to expose only what's needed on a per-user basis, and don't hand out write privileges to the database.

There's clearly value in a beautiful, syntax-light UX to codify our business logic, but you shouldn't have to give up control of your business to take advantage of it. We're accepting a limited number of applications for the Trivial pre-release, get in touch if you've got some systems you'd like to connect in a way the product and engineering teams both can love. And that's why my team and I are making Trivial.