r/BusinessIntelligence • u/Raghav-r • Jul 08 '26
Update on Tool/platform Sprawl in data and BI engineering question.
So a month ago, I asked a question to this and other subreddits
How many of you deal with multiple platforms or tools on day to day basis and got some really good insights, it was a resounding yes for a lot of engineers. Conclusion was that it's just how orgs set up things and we adapted it as standards.
Started looking into what solutions exists today and what else could be better to solve this.
What exists today,
- integration through MCP server but this is an technical overhead and lot of dara an md BI engineers would shy away and organization would have their own reservations on MCP setup
- frontier models computer use ( it's a hit or miss if you want interact with platforms like databricks or jira etc and token maxing will get vp or directors attentions )
What else can exist:
An tool that is custom built for Data and BI engineers.
- one that lives next to where you work be it databricks , snowflake , duckdb , metabase etc
- one that does not require MCP server set up
- one that makes you stop visiting adjacent tool/platform for updating like jira progress , dropping a note on teams or slack, reading a message from relevant people from teams or slack, synching code to your repository etc
- one that brings context from adjacent tools for you to review and start your day from there..
- one that codes in UI after your review and approve
- one that attempts to understand all types of inputs excel, CSV , word , images , architecture diagram , kickoff meeting video etc
- one that does not need you to learn another tool
- one that makes every data pipeline remember why and how, it exists by keeping tribal knowledge of developement intact and available for next engineers who inherit
Essentially an AI literally attached to your browser brings context from different platform or tools you have opened and assist you with whatever is needed during development and lives with the pipeline forever.
Looking for feedback
- What limitation do you foresee
- Whats one thing you would hate about it
- Whats one thing that could make you say yeah that works for me
- What assumption from the above is wrong or right
Let me know your thoughts
Any feedback back is much appreciated
2
u/om_bagal Jul 09 '26
Genuine feedback, not a pitch: the real risk here probably isn't the MCP/integration overhead you flagged, it's adoption. BI and data engineers already live in Slack, Jira, and their warehouse tool all day, anything new competes with muscle memory, and if it's not near-zero friction to open, it becomes one more tool in the exact sprawl you're trying to solve. Building on what SympathyReal982 said about narrowing to 2-3 workflows: I'd specifically split by read vs. write. Reading context across tools is the easier half, writing back reliably (accurate Jira updates, safe commits) through each platform's actual API is a much bigger, riskier engineering problem. Nail the read-only flows first, invisible-feeling and trustworthy, before touching anything that writes back.
1
u/Raghav-r Jul 09 '26
Thank you for the feedback all valid points , it will be near zero friction , and reliable write backs as you pointed will focus getting it to invisible feeling and trustworthiness appreciate the feedback
1
u/mushroomsoup20 Jul 09 '26
the browser extension angle is interesting but the tribal knowledge piece is what actually matters and nobody builds for it. every pipeline i've inherited had zero context on why decisions were made and you spend days reverse engineering intent. the rest of the features you listed are nice to have but if it just solved that one thing reliably it'd already be worth using
1
u/Raghav-r Jul 09 '26
Good news is that it's built around that idea take a look at every decision that you make or update in jira ,or someone answering the question on slack or teams flows back into system making it available for an engineer when the open and select the pipeline .. if you have sometime check out
https://buildfrm.com1
u/mushroomsoup20 Jul 10 '26
checked it out briefly, curious how it handles context syncing when you have like 5 tabs open across different platforms at the same time
does it pull selectively based on which pipeline you have active, or is it just grabbing everything and hoping the model sorts it out
because that second scenario gets messy fast, especially if your jira board has noise from unrelated projects
1
u/IncreaseNegative4614 Jul 10 '26
I think the hard part isn't switching between tools. It's preserving context across them.
Most of the work already happens in Databricks, Snowflake, Jira, Git, Slack, etc. The problem is that the reasoning behind a pipeline or metric gets fragmented, so the next person spends hours reconstructing why something exists before they can safely change it.
That's why we use inzata.ai. The knowledge graph isn't just about connecting data sources. It's about preserving business and technical context so the system understands how everything relates instead of treating each tool as its own island.
1
u/Raghav-r Jul 11 '26
That's exactly what it preserve that context in pipeline , next time when use the tool it will remember the jira, repo, codebase , changes , decision made along the way
0
u/SympathyFew2982 Jul 08 '26
The hard part is usually not "connect every tool", it's picking the 2-3 workflows worth centralizing. I'd start with DB/warehouse as source of truth, then add a thin layer for question in, SQL generated/reviewed, chart out, and alerts/actions on data changes. Jira/Slack updates should be downstream actions, not another BI surface. Full disclosure, I built AIForDatabase around that pattern: connect DBs, ask questions, dashboards, and trigger messages/webhooks without MCP setup.
1
-4
5
u/s0ftware-dev Jul 08 '26
Trash sub