Who controls your intelligence analysis platform?

Over the years, I’ve seen two broad philosophies emerge for building an intelligence analysis platform. One concentrates knowledge and capability inside the vendor. The other builds them inside the customer’s own team.

The distinction matters more as the platform grows. More users, data, workflows, and use cases will deepen one of two things: your dependency on the vendor, or your own team’s ability to understand, operate, and change the platform.

Neither is inherently right or wrong. They optimize for different definitions of success.

One concentrates knowledge and capability inside the vendor through a tightly integrated, vendor-led platform. The vendor brings the technology, people, and expertise to build and evolve the platform on the customer’s behalf.

The other model is different. The vendor still brings technology, expertise, and support, but the customer’s team is involved in building the platform and learns to operate and extend it themselves. Knowledge and capability are concentrated inside the customer.

Take something as routine as adding a new data source. In the first model, the customer defines what they need and relies on the vendor to update the model, pipelines, and workflows. In the second, the customer’s own team has the knowledge to make those changes themselves, bringing in vendor support when they need it.

I understand why the vendor-led model has an obvious appeal. Intelligence programs are complex, and most organizations don’t have a data engineering team sitting idle, waiting for a new project. A vendor that arrives with technology, people, and a plan solves a real problem. For organizations that want a technology partner permanently involved in running and evolving their intelligence capability, that’s a fair choice.

The customer-led approach is a different proposition. Having worked in the public sector myself, I strongly believe in helping customer teams build and retain this kind of capability internally, with data engineering, IT, and analysis teams involved from day one. As they build, they also learn how the data, model, and workflows fit together. That knowledge – how to run and change the platform – stays inside the organization. Later, when something needs to change, such as a new source or a question nobody anticipated, the team doesn’t have to wait on the vendor. They can just make the change.

But the moment you choose between these two models is exactly the moment the vendor-led option looks most appealing. You’re trying to get a complicated program off the ground. Someone offering to take the problem off your hands sounds like exactly what you need.

But implementation is just the beginning. The intelligence capability you’re building should serve your team for years to come.

What happens when things go well?

Successful intelligence analysis platforms don’t stay still. They attract more users, more data, and more use cases. Analysts find new ways to use them. New workflows are built. More parts of the organization start to depend on them. 

And that growth compounds whichever model you chose at the start.

With a vendor-led model, that growth deepens the dependency on the vendor. More gets built on the platform, but the knowledge and control needed to change it still sit outside the organization. When even a small change means waiting on a support ticket, the delay can be costly. A lead can go cold while the change is being scoped, or the trail on an active suspect can disappear while you wait for the vendor to respond.

In a customer-led model, growth does the opposite. Each new source, model, and use case gives the customer’s own team more experience of building and changing the intelligence environment themselves. The platform doesn’t just grow; the team’s ability to keep adapting it grows too, so each future change gets faster and easier, not slower and further out of reach.

The dependency is also broader than support. Over time, an intelligence analysis platform accumulates far more than data. It contains the organization’s data model, pipelines, integrations, analytical workflows, and years of decisions about how intelligence should be represented and used. If those things can only be understood, changed, or operated through the vendor, the organization may technically own its data while no longer really owning the intelligence capability built around it.

That is how dependency becomes lock-in. Leaving no longer means replacing a piece of software. It means reconstructing years of accumulated capability somewhere else.

A few years in, two equally successful programs can therefore leave their organizations in very different positions.

How much control do you actually have?

In my experience, the model you intended to build is one thing. What matters a few years later is where the knowledge and control actually sit.

Three questions make that easier to assess.

Could you change it? 

Imagine your intelligence analysis platform’s been a huge success. So much that another team wants to use it. The new use case needs different data, a different model, and different workflows. Would your own team know where to start, or would the project start with a quote from the vendor?

Intelligence requirements change constantly, and new sources are only part of it. Priorities shift, threats evolve, and analysts start asking questions nobody considered when the platform was first implemented.
Who has the knowledge and ability to respond when they do?

Could you understand it?

There’s a difference between knowing how to use a platform and understanding how the intelligence capability behind it has been built. After a few years, who actually knows why the model looks the way it does, how the data gets there, and how it all fits together? 

If the people who built the original implementation disappeared tomorrow, could your team pick up where they left off, or would they be trying to open a black box without the tools or experience to do so safely?

Could you leave it?

This may be the question organizations think about least when they’re choosing a platform. It’s not just about the data. Years in, your intelligence analysis platform is far more than the data you started with. You’ve built a model around it, connected new sources, built workflows and integrations, and made thousands of small decisions about how it works.

If your strategy changed in three years, what could you actually take with you? Just the data, or the intelligence capability you’ve spent years building around it?

The choice we’ve made with GraphAware Hume

These are questions I care about personally, and they’ve also shaped how we’ve built GraphAware Hume, the graph data integration and investigation environment for Neo4j GraphAware solutions.

We’ve optimized GraphAware Hume for ownership: ownership of the data, the intelligence model, the pipelines and integrations, the analytical workflows, and the knowledge needed to keep changing them. 

GraphAware Hume uses an open, modular architecture that customers can understand, operate, and extend themselves. Customers keep control of their data and intelligence model, while their own teams build the pipelines and workflows they need as the mission evolves.

We’ve also worked hard to make sure this doesn’t come at the expense of speed. Teams can start proving value within days, with support from people who have built intelligence analysis platforms before. The difference is that what they build doesn’t have to remain dependent on those people.

Some organizations will always prefer a vendor-led model. What matters is knowing that’s the choice you’re making, with your eyes open to what it costs later, not just what it saves now.

Because the platform you choose today won’t just decide what your analysts can do next year. It will decide who owns the knowledge, skills, and control behind your intelligence capability for as long as you’re running it.