Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We've been thinking about software integration wrong for the past 50 years

nerve-signals.pika.page

Post reply on HN
Print view View original

21–30 of 40 posts

Re: We've been thinking about software integration wrong for the past 50 years

#21

Post by apimade »

zer00eyz wrote: post #3

I... I am dumbfounded. With the current state of the market why in the name of all that is holy would you depend on one vendor to get to another? I dont need to be at the whim of one vendor to get to the next one. What happens when the vendor in-between goes out of business or wants to present their own service or... I have no words for how bad this idea is.

You're thinking like an engineer. Engineers are poor at estimations, poor communicators and can't give me a damn budget. I'll never understand why engineers don't see that abstraction, even through corporations is bad in one area, but good in others (libraries, dependencies).

Zapier? Tines? Workato? That's $10B in marketshare that disagrees with this, without even considering the order of magnitude of revenue present in companies like IBM, Oracle, Salesforce, SAP, etc.

And with these tools I know how long it'll take because it's 90% already built. The SLA's and BCP they provide allow me to delegate risk "enough" - the insurance company agrees - just the same as I delegate risk for my authZ/authN to Okta and Auth0, and my infrastructure and pretty much the entirety of my business to one-or-many cloud providers.

Do I wholly agree with the above? No. I'd sooner we all moved to paper-based databases, and basic HTML forms linked up to printers. But I have to be realistic.

Re: We've been thinking about software integration wrong for the past 50 years

#22

Post by apimade »

bemusedthrow75 wrote: post #16
apimade wrote: post #12

Hey Matt, it's a really neat product idea. I'd really recommend taking a niche and building it for that first. Selling a new Enterprise-wide integration tool is hard. Selling a new data orchestration concept will be harder. I recently moved out of that area, but I worked in this space for about a decade. I can already see the rejections: Debugging and Support: Rather than a centralised support system with levels, to…

> it's a really neat product idea. The one thing this idea is not is neat , though. It's the opposite of it. It entrenches the opposite of neat.

At the end of the day it's SQL on top of my integration layer. I love that. I don't know how it'd work in practice, or if it's any better than adopting a data warehouse - but even for understanding state management or offering a tool to create a view of a "customer" data definition is valuable.

There's value to be had, I don't love the concept the author is proposing but the overall thing they're building, provided it "just works", certainly has some legs.

Re: We've been thinking about software integration wrong for the past 50 years

#23

Post by BrandoElFollito »

I am always put off by articles titled "we've been doing X wrong for Y years" ("and #3 will shock you!" :)).

I have the feeling that this is the article of someone who has a vision under the shower and shares it with the wrong-doers to bring them wisdom.

Now, I have not read this specific article so it may be revolutionary for once.

Re: We've been thinking about software integration wrong for the past 50 years

#24

Post by datadrivenangel »

apimade wrote: post #21
zer00eyz wrote: post #3

I... I am dumbfounded. With the current state of the market why in the name of all that is holy would you depend on one vendor to get to another? I dont need to be at the whim of one vendor to get to the next one. What happens when the vendor in-between goes out of business or wants to present their own service or... I have no words for how bad this idea is.

You're thinking like an engineer. Engineers are poor at estimations, poor communicators and can't give me a damn budget. I'll never understand why engineers don't see that abstraction, even through corporations is bad in one area, but good in others (libraries, dependencies). Zapier? Tines? Workato? That's $10B in marketshare that disagrees with this, without even considering the order of magnitude of revenue present…

The abstraction is visible. It's also important to remember vendor lock-in, and how they can raise rates and start squeezing out all of your profit margin.

Re: We've been thinking about software integration wrong for the past 50 years

#25

Post by datadrivenangel »

ako wrote: post #17
ivan_gammel wrote: post #11

Having Salesforce, Zendesk, Hubspot and Pipedrive that share the same data in one company I would immediately start cutting costs instead of thinking about integration. Even if I had to think about it, the only correct approach for data propagation is directly from source of truth (or in "colonial" terms - master system) to dependent systems, and the only middleware in between them being data delivery (simple queue o…

Not really, usually you have some translation to ensure data from different systems is aligned/translated into a unified format. It’s expensive and cumbersome to do this in every dependent downstream system over and over again. Especially if upstream systems change, you want to implement that change in one central place instead of all downstream systems. I think there’s a lot of value in the snowflake approach: put a…

This works great until marketing builds their own system because they can't get data access fast enough and then grows it into a competing CRM and you have multiple systems of truth...

Re: We've been thinking about software integration wrong for the past 50 years

#26

Post by lijok »

We tried this when we were building DAM integrations. It doesn't work. Lossy integrations. You convert a datetime from Zendesk to your format via Hubspot and it goes from 1943-01-01T14:00:00Z to 0 because HubSpot stores that field as a unix timestamp and is very lax around bounds. You pull a decimal and you loose precision. Floats become ints, lists become dicts, strings become xml, binary blobs become urls, etc.

Re: We've been thinking about software integration wrong for the past 50 years

#27

Post by beaviskhan »

zer00eyz wrote: post #3

I... I am dumbfounded. With the current state of the market why in the name of all that is holy would you depend on one vendor to get to another? I dont need to be at the whim of one vendor to get to the next one. What happens when the vendor in-between goes out of business or wants to present their own service or... I have no words for how bad this idea is.

Seriously, integrating with a single vendor is often nightmarish. And this guy is proposing some unholy vendor centipede? Harrrrrrd pass.

Re: We've been thinking about software integration wrong for the past 50 years

#28

Post by johnorourke »

Animats wrote: post #7

It's a clickbait ad for something called "Nerve". The original idea for "electronic data interchange"[1] was to have a standard format for inter-company invoices, purchase orders, bills of lading, customs clearance, etc. So you only need N implementations, not N^2. This got going in the 1970s. So the formats are ancient. This is a flight ticket availability request in the international EDIFACT format. UNA:+.? ' UNB+I…

I'm involved in "modern" systems for Purchase Order and Invoice transmission between companies - using a standard called "cXML". I say "modern" - it dates back to 1999 when we were shouting "XML all the things!". 25 years later companies are just discovering how to use it to stop manual data entry.

Re: We've been thinking about software integration wrong for the past 50 years

#29

Post by johnorourke »

apimade wrote: post #21
zer00eyz wrote: post #3

I... I am dumbfounded. With the current state of the market why in the name of all that is holy would you depend on one vendor to get to another? I dont need to be at the whim of one vendor to get to the next one. What happens when the vendor in-between goes out of business or wants to present their own service or... I have no words for how bad this idea is.

You're thinking like an engineer. Engineers are poor at estimations, poor communicators and can't give me a damn budget. I'll never understand why engineers don't see that abstraction, even through corporations is bad in one area, but good in others (libraries, dependencies). Zapier? Tines? Workato? That's $10B in marketshare that disagrees with this, without even considering the order of magnitude of revenue present…

The Zapiers of this world do not disagree.. they've built the hub and all the apps are spokes on their wheel. Engineers know that abstractions only help to create good architectures and high-level understanding, but they don't actually make the magic happen on the ground.

Re: We've been thinking about software integration wrong for the past 50 years

#30

Post by ivan_gammel »

datadrivenangel wrote: post #25
ako wrote: post #17

Earlier quoted context omitted.

Not really, usually you have some translation to ensure data from different systems is aligned/translated into a unified format. It’s expensive and cumbersome to do this in every dependent downstream system over and over again. Especially if upstream systems change, you want to implement that change in one central place instead of all downstream systems. I think there’s a lot of value in the snowflake approach: put a…

This works great until marketing builds their own system because they can't get data access fast enough and then grows it into a competing CRM and you have multiple systems of truth...

This is the reason why MarTech must be number one priority for a CTO of the company where execs are talking more about the funnel and CACs than about UX or security. Two CRMs is one of the biggest technical debts that you can imagine, the one that may require buy-in from the half of the company.
Post reply on HN