[neeleshs]

This is not true in many use cases. There are tons of ways to handle low code/no code. It is a very hard problem to solve, and vendors end up building basic "low-code" wrappers around API endpoints, and that's why it looks like a lost cause.

Done right, (we are a living proof it can be done, at Syncari), one can do a lot of stuff done without any coding

[newcrobuzon]

Do you have any links to some blog posts discussing it (the "doing it right" approach)? I would agree that it definitely depends on the use case.

I will definitely check out Syncari - just opened the landing page and it looks great!

[neeleshs]

Thanks! Haven't had a chance to write a lot about this (heads down building and selling), but https://syncari.com/a-brief-history-of-todays-data-woes-and-... touches on it a bit.

For us, it is about:

* implementing deep integrations that are commonplace

* not spraying too thin in the quest of supporting hundreds of systems

* thinking from a data model/data/eventually consistent system perspective

* completely dropping the reactive/trigger based/if-this-then-that point-to-point model.

[newcrobuzon]

Thanks Neelesh for the link, I like the way of thinking with the focus on data.

It is similar with what I am seeing - i.e. lots of older integration systems are terrible with data simply because they force you to use some way of data modeling (e.g. their OOP data models, WSDLs/XSDs etc.) while the newer ones just rely on json which is good but can lack the (sometimes necessary) complexity. To do some data cleansing on the way then seems like an unachievable task (there is certainly such a thing as overdose on XSLT ;) ).

I also like the approach you took with centralized data dictionary - it certainly is something the industry might need, I would wonder how it impacts change management though (especially in bigger companies).

Wishing you good luck!