Data's Getting Easier. Ontology's Getting Harder.
It was great attending the Credit Invest conference in Boston last week with a couple members of the Hedgineer team. We connected with credit managers, met other vendors in the space, and heard Michael speak on a panel about AI.
Though we discussed a wide range of interesting ideas, one theme stood out: data. More than half the conference sponsors (including yours truly) were data vendors or data consolidators. It was refreshing to be in an environment of shared understanding that when we talk about AI, we have to talk about data.
How Data Got Easier
Not long ago, standing up a database felt like assembling a small power plant. Firms bought physical servers. Data pipelines were stitched together with convoluted SQL scripts that only one or two people understood. Every change risked breaking a dozen downstream reports. Operational cost was a function of headcount, key-person risk, and constant maintenance work.
In that world, it made sense for every department to build only what it needed, and teams often created duplicate systems in different ways. Research used one security master; trading used another. Consolidation was avoided because it meant more effort, more pain, and no alpha.
Today, the picture looks very different. Hyperscalers like Azure and managed platforms like Databricks turned infrastructure into something you configure instead of something you build. Scaling is elastic, storage is managed for you, and engines like Spark let teams process massive datasets without hiring a large data engineering staff. Modern tooling supports cleaner pipelines, automated testing, and version control.
It is not only easy to build a database. It is easy to build a good one.
The Hard Part
But scaling data in an organization of siloed systems is still difficult.
Think back to those two security masters. A fund can’t grow with two definitions of the same concept! So they must be merged. This requires unpacking every place they are used, identifying the subtle differences between them, and understanding how they connect to other datasets and reports.
At that point, you are no longer defining a security master for one team. You are defining it for the entire firm. And you are forced to answer a much harder question: what is the canonical anatomy of a security? This is where the real work begins. You’re now building an ontology the whole organization can agree on.
This is the moment many firms find themselves in today. The technical barriers have fallen. The infrastructure is manageable. The tooling is powerful. And with AI, even the process of implementing the code is accelerating. Yet the business complexity keeps rising as firms attempt to create a repository of truly centralized knowledge, often for the first time.
Many companies, including us, are trying to solve this problem for their clients. Which makes sense— the cost of building data infrastructure has never been lower, and the demand for cleaner data systems has never been higher. It’s a market ripe with opportunity.
But tackling this problem requires much more than good tech. It requires a deep understanding what it’s actually being used for. The challenge is no longer whether you can build the system. It’s whether you can build the right system— one that scales with your strategy, your process, and your growth.
In other words, data strategy is no longer a technical problem. It’s a business problem.