Business & IT: two mindsets, one organization
A Story of Two Ways of Thinking
In pharmaceutical organizations, innovation often stalls in unexpected places. Not in technology choices, not in data availability, not even in regulatory constraints, it stalls in conversations.
A data platform is delivered. A knowledge graph is built. Integration is achieved. And yet, business teams remain unconvinced. IT insists that “everything is there.” Business responds that “nothing has changed.”
And both are speaking from fundamentally different ways of understanding the world.
The IT Mind: Seeing Structure Behind Reality
Over time, IT professionals develop a very specific way of thinking. It is shaped by years of working with systems that reward precision, consistency, and formal logic.
They learn to see what is not visible: architectures, dependencies, data flows. They break down complexity into manageable components. They rely on deterministic logic “if X, then Y.” They hold multiple variables in mind and resolve problems through structured reasoning.
The world starts to look like a system of entities and relationships. Concepts become tables, attributes become columns, identity becomes a key. Understanding becomes an act of linking, joining one dataset to another.
In a clinical data context, an IT professional might say: “If we standardize the schema and align identifiers, we can connect all trial data across systems.”
From their perspective, this is not just correct, it is sufficient.
The Business Mind: Making Sense of Uncertainty
On the other side, life science business professionals operate in a very different environment though fundamentally the same.
Their world is not defined by certainty, but by ambiguity. Clinical outcomes are uncertain. Regulatory decisions are interpretive. Market dynamics shift. Timelines stretch over a decade. To function in this environment, they develop different cognitive strengths.
They integrate multiple dimensions at once: science, regulation, market access, stakeholder expectations. They reason probabilistically, asking not what is true, but what is likely. They build narratives that make complex situations understandable and actionable. They constantly anticipate how different actors (e.g. regulators, physicians, patients) will interpret information.
In the same clinical context, a business leader might say: “Does this data support a convincing story for regulators? Is it strong enough to justify moving to Phase III?”
For them, structure is not enough. Meaning is everything.
Schema vs Meaning: The Core Misalignment
This is where the tension becomes visible:
IT asks: “What is the schema?”
Business asks: “What does it mean?”
This is not a communication issue. It is a cognitive mismatch.
For IT, identity is fixed and explicit defined by keys and attributes. For business, identity is contextual. A drug is not just a molecule; it is simultaneously a clinical intervention, a financial asset, and a therapeutic promise.
For IT, relationships are exact and defined. For business, they are interpretive and evolving. For IT, logic is deterministic. For business, it is probabilistic. For IT, success means consistency. For business, it means viability.
When Knowledge Graphs Enter the Picture
Knowledge graphs (KGs) are schema-free or to be more precise, they allow to structure data in flexible schema that one can define by their needs. KG often introduced as a way to blend silos and connect data across domains in a dynamic fashion.
In theory, they are perfectly positioned to align structure and meaning. In practice, they often fail to deliver value. Why?
Because they sit precisely at the intersection of these two cognitive worlds and inherit their misalignment.
KGs for IT
From the IT perspective, a knowledge graph is a strange data warehouse in which relationships are queried rather than objects or attributes. Ontologies are fuzzy schemas that are supposed to link data across systems.
This creates a certain discomfort. It challenges deeply ingrained habits: instead of designing rigid structures upfront, one must accept evolving models; instead of enforcing strict schemas, one works with semantics that are negotiated and refined over time. To many IT professionals, this can feel imprecise, even risky “Where is the control? Where is the guarantee of consistency?”
Yet this perception reveals something important.
A knowledge graph is not just another data architecture. It is a shift from data modeling as structure to data modeling as meaning.
Where traditional systems optimize for storage, performance, and consistency, knowledge graphs optimize for interpretability, interoperability, and context. They do not replace structure—they relax it just enough to allow connections across domains that were never designed to fit together.
In that sense, ontologies are not “fuzzy schemas.” They are shared agreements about meaning, continuously evolving as understanding deepens. They are less about enforcing rules and more about enabling alignment.
This is precisely why knowledge graphs sit uncomfortably in the IT landscape and why they are so powerful when they work.
They require IT to move from:
- controlling data → enabling meaning
- enforcing structure → supporting interpretation
- designing systems → facilitating understanding
And that is not a technical shift. It is a cognitive one.
KG for business
From the business perspective, a knowledge graph is often perceived very differently.
It appears complex, difficult to visualize, and dense with information. Nodes, edges, ontologies, relationships—these are not natural representations for business users. Instead of clarity, it can feel like cognitive overload: too much information, not enough direction.
The immediate reaction is often simple and pragmatic:
“How does this answer my question?”
Because business users are not looking for connections, they are looking for decisions. They expect a system to tell them:
- “What should we do next?”
- “Where is the risk?”
- “What decision does this enable?”
When presented with a knowledge graph, they may see a sophisticated representation of data but they struggle to see:
- how it reduces uncertainty
- how it accelerates a decision
- how it changes an outcome
In a clinical context, a business stakeholder does not ask:
“How are these datasets connected?”
They ask:
“Given all this, should we move to Phase III or stop?”
This is where the gap becomes critical. A knowledge graph answers questions about the world. Business users need answers about what to do in that world. Bridging this gap requires more than exposing connections. It requires translating those connections into:
- signals (what matters)
- context (why it matters)
- implications (what it changes)
Until then, the knowledge graph remains impressive but distant. Not because it lacks value, but because its value is not yet expressed in the language of decisions.
A Concrete Example: Clinical Trial Design
Consider the design of a new clinical trial.
A knowledge graph successfully integrates historical trial data, endpoints, patient populations, and outcomes. From an IT standpoint, this is a major achievement.
But the clinical team asks: “Which endpoint increases our probability of regulatory approval?”
The graph contains the data but it does not yet provide the answer. Because the missing piece is not connection it is interpretation. Without translating structured knowledge into decision-relevant insight, the system remains impressive but underused.
The Real Source of Friction
The friction between IT and business is not due to misalignment of goals. It comes from how each side defines “understanding.”
- For IT, understanding means that the system is consistent, complete, and logically sound.
- For business, understanding means that a decision can be made with confidence under uncertainty.
These are not competing definitions but they are incomplete on their own.
Reconciliation: Connecting Structure and Meaning
Bridging this gap requires more than better tools. It requires deliberate reconciliation between two ways of thinking.
First, structure must be enriched with meaning. Data models and identifiers need to be complemented with semantic layers that explain what concepts represent and why they matter.
Second, narratives must be grounded in structure. Business interpretations need to be traceable to data, consistent across contexts, and reusable.
In practice, this means moving from:
- data → information
- information → knowledge
- knowledge → decision
Most importantly, it requires people who can move between both worlds: system thinkers. Individuals who can understand both perspectives without judgment, who are empathetic, and who can translate meaning across two languages, two mindsets.
These “dual cognition” professionals are able to translate a business question into a structured representation and then translate the result back into a meaningful narrative. This translation is becoming easier with the support of language models, but the underlying cognitive skill remains essential.
They can explain to IT why meaning matters, and to business why structure is necessary. They are not just translators, they are contextualizers and integrators, enabling alignment where others see only disconnect.
The Real Challenge Behind Graph Ways of Working
In big pharma, IT builds systems that are correct. Business makes decisions that must be viable. Knowledge graphs enabling system thinking only create value when they connect these two dimensions.
Because in the end, systems thinking does not fail because it is wrong, it fails because it is too complex for humans to fully embrace.
It requires empathy across domains, the ability to hold multiple perspectives at once, and the discipline to understand contexts that are not our own. In reality, few of us can consistently encompass all the parameters needed to truly understand others, their constraints, their language, their way of thinking.
And so, the system breaks down. Not because the model is flawed, but because we are limited in how we perceive and connect meaning across boundaries. It fails because it is not understood in the way that matters.
Solving this problem is not a technological challenge. It is (still) a human one. It requires us to bridge how we think across functions, disciplines, and cognitive frameworks.
If we are unable to do so, machines will. Not because they are smarter, but because they are better at handling complexity without bias, without ego, without cognitive fatigue.
And that is where the real shift lies: not in technology replacing humans but in humans being unable to keep up with the level of integration that modern systems demand.
The question is no longer whether we can build these systems. It is whether we can think at the level required to use them or whether that role will gradually be taken over by machines.
