The Quiet Drift From Fabric to Wallpaper

Data fabric, in its Gartner definition, is an architectural pattern that uses active metadata, knowledge graphs, and integrated services to deliver unified access, governance, and semantics across distributed data assets.3 The word that carries most of the meaning is active. A functioning fabric does not just describe data; it moves it, enforces policy on it, resolves identifiers across systems, and reacts when something changes upstream.

In practice, the programs that get stuck almost always drift toward something more passive. The catalog gets populated. Lineage diagrams are drawn. Data stewards are appointed. A steering committee meets. And the underlying systems continue to behave exactly as they did before, because none of the promised active behavior was ever actually wired in. That is the drift from data fabric to wallpaper: it looks impressive on the walls of the enterprise architecture deck, and it changes nothing about how data actually flows.

80% Of data and analytics governance initiatives projected to fail by 20271
85% Of failed AI projects cite poor data quality as a root cause2
50% Increase in FDA CDER warning letters in FY 2025, with data integrity a recurring theme4

None of this is a reason to walk away from the architecture. It is a reason to be honest about which parts of a fabric implementation are actually load-bearing and which parts are decorative. The five warning signs below are the ones we see most consistently in pharma programs that have gone quiet. Each one has a remediation path. Together they define a rough diagnostic that any senior leader can walk through with their data and IT teams in a single working session.

Before walking through the warning signs, it is worth naming why this drift happens so consistently. Data fabric programs are usually launched into organizations that have already lived through one or two waves of data platform investment. There was a data warehouse program, then a data lake program, then perhaps a lakehouse initiative. The teams that lived through those cycles have learned to be measured in their enthusiasm, and they have also learned that the language changes faster than the underlying reality. Fabric is the current word for the same recurring problem: pharma data is scattered, the systems that hold it were not designed to interoperate, and the people who need it cannot get it in a form they can trust.

What is different this time, and what makes the stakes materially higher, is the AI overlay. A data fabric that quietly underperforms in a purely analytical context produces slower dashboards and grumpier analysts. A data fabric that quietly underperforms while feeding AI models produces recommendations that clinicians, commercial teams, and quality reviewers act on, sometimes without ever seeing the underlying data lineage. The consequences of drift compound. This is the practical reason to be sharper about the diagnostic than we needed to be in earlier cycles.

Warning Sign 1: Fabric Implemented as a Metadata Catalog

The first and most common failure mode is the one that looks most like success on the surface. A team stands up a data catalog, connects it to source systems, harvests technical metadata, appoints stewards, and calls the result a data fabric. Nothing is technically wrong with any of those steps. They are just not, on their own, a fabric.

The distinction that matters is between passive metadata and active metadata. Passive metadata describes what data exists, where it lives, and how it is structured. Active metadata refreshes automatically, detects anomalies, and triggers downstream actions in real time.5 A catalog with only passive metadata is a search tool. A fabric with active metadata is an operating layer that participates in how data moves, transforms, and gets governed.

How this shows up in pharma programs

In a large biopharma we reviewed recently, the enterprise data catalog had cataloged more than 40,000 assets across clinical, commercial, and manufacturing systems. The self-serve portal was polished. Data owners were named. Yet when a medical affairs team asked which fields in the safety database mapped to which fields in the CRM, the answer took two weeks of back-channel emails between three teams. The metadata described the assets. It did not connect them.

The underlying problem is not the catalog. It is the assumption that the catalog is the fabric. A data catalog that lists Veeva Vault CRM as a source but has no active connector, no policy enforcement, and no automated schema drift detection is a directory of intentions. It documents the fabric that leadership hopes exists.

Diagnostic question. If a source system schema changes tomorrow, does anything in your fabric detect it, notify affected downstream owners, and hold or reroute impacted flows? If the honest answer is “someone would find out eventually,” the fabric is passive.

Remediation pattern

Rather than replatform, most teams can move a passive catalog toward an active fabric by picking two or three high-value data domains and wiring in the active behavior for those domains only. That usually means a change data capture layer against the source system, a metadata layer that observes and reacts to those changes, and at least one automated downstream action such as a notification, a policy update, or a rerouted flow.

The point is not to make everything active at once. It is to prove, in a specific domain such as clinical trial enrollment or field team activity, that the fabric can actually do work instead of describe work. Once that pattern is established, the catalog stops being the whole strategy and becomes one supporting layer in a larger operating architecture.

The most persuasive proof point we have seen for a passive-to-active transition was not a technology switch. It was a two-week exercise where the fabric team picked one downstream question the business had been asking, followed it back through the catalog to the source, and instrumented the full path with active behavior. When the source data changed, a notification went to the affected consumer within minutes rather than being discovered at the next monthly reporting cycle. That single exercise made the difference between the fabric being funded again and being quietly wound down. The lesson is not that all fabrics need dramatic demonstrations; it is that leadership stops paying for capabilities they cannot see working. Give them one thing they can see.

Warning Sign 2: Governance Rules That Cannot Be Enforced

The second warning sign is a governance program with clear policies, named stewards, an approved data dictionary, and no ability to enforce any of it against the systems where the data actually lives. This is especially common in pharma, where a significant share of the source systems that feed the fabric are older, on-premise, read-only from the fabric’s perspective, or governed by change control regimes that make ad-hoc modification impossible.

Governance in a data fabric is meant to be encoded as policy-as-code and applied consistently across the estate. If the fabric can only apply policy to a small ring of modern cloud sources, and the older LIMS, MES, and legacy ERP systems remain outside that ring, the practical result is a two-tier governance model where the newest data is well controlled and the most critical data is not.6

Why this pattern is so common

Most mid-size pharmaceutical manufacturers have not connected their LIMS to their ERP, and even the ones that have often rely on point-to-point integrations that pre-date the fabric program.7 These older integrations are validated. Any change to them requires re-validation. The fabric team, understandably, does not want to open that scope, so the legacy sources are left as read-only feeds. Policies exist on paper for what those sources should look like. Nothing in the runtime environment enforces them.

Combined with a passive catalog, this produces a program that can describe the ideal governance state in great detail and cannot actually cause it to happen. The gap between policy and enforcement widens with every quarter of unresolved technical debt.

The inspection risk. Recent FDA warning letters increasingly describe computerized systems that lack the controls needed to enforce audit trails, user access, and change management on the actual data flows, not just on documented procedures.8 A fabric governance model that stops at documentation does not close this gap.

Remediation pattern

The workable approach is to make governance enforceable in stages, and to be honest about which sources are inside the enforcement perimeter today. That usually means three moves. First, publish an explicit map of which sources are inside the runtime enforcement perimeter and which are outside. Second, for sources that must stay outside, define compensating controls, typically a combination of scheduled reconciliation jobs, exception reports, and named human review at defined cadences. Third, plan the phased inclusion of remaining sources with realistic timelines that account for validation work.

What does not work is pretending the perimeter is bigger than it is. The most damaging failures we have seen came from programs that told leadership that fabric governance was in effect enterprise-wide when the enforcement mechanisms only touched a fraction of the estate. When the gap is later discovered, usually by an internal audit or an inspection finding, the credibility cost is disproportionate. The team that was doing serious work on the modern sources gets tarred with the failure to enforce on the legacy sources, even though the mismatch was really a communication and scope failure.

A related trap is the assumption that all governance work can be done in the fabric layer. Some of it needs to be done in the source systems. If a legacy LIMS lacks user-level audit trails at the record level, no fabric policy running above it will manufacture that audit trail from nothing. The fabric can add compensating controls. It cannot fix the source. Being honest about that distinction with leadership, and framing legacy remediation as a parallel workstream rather than a fabric deliverable, tends to preserve the credibility of the fabric program while getting the underlying work funded.

Warning Sign 3: A Semantic Layer That Nobody Speaks

The third warning sign is a semantic layer that is technically correct and organizationally unusable. Someone, often a small central data engineering team, defines the canonical business terms. “Patient,” “product,” “site,” “adverse event,” “prescriber,” “customer” all get precise definitions with lineage back to source. And then the commercial team keeps using “customer” to mean an HCP, the medical team uses it to mean an account, and the market access team uses it to mean a payer contact. None of them are wrong. None of them are using the semantic layer.

In life sciences, consistent semantics and data definitions are foundational, and regulators expect a data dictionary that standardizes terms across the enterprise.9 But a dictionary imposed from a central group without validation against how each function actually uses the term will be quietly ignored. Analytics teams build their own local mappings. Reports drift. The semantic layer becomes another artifact rather than a working contract.

The IDMP parallel

The pharma industry has already lived through this dynamic with IDMP. The ISO IDMP standards define hierarchical relationships between medicinal products, formulations, substances, dose forms, routes of administration, and the organizations responsible for them, using controlled vocabularies from the EMA Referentials Management Service.10 Companies that treated IDMP as a pure compliance exercise, mapping their internal terms to ISO terms once, generally ended up with translation layers that grew brittle. Companies that used IDMP as an opportunity to converge internal semantics with the external standard got more durable value.

The same principle applies to internal semantic layers. A layer defined in isolation from the functions that use it will be a compliance artifact. A layer defined jointly with those functions becomes an operating contract.

CENTRAL DEFINITION

Semantic layer as authority

Central data team defines canonical terms, publishes a data dictionary, expects downstream consumers to adopt. Works only when the central team has veto authority over downstream reporting, which is rare.

FEDERATED CONTRACT

Semantic layer as agreement

Each function co-owns the definitions that touch their domain, with a central data team facilitating convergence. Slower to define, dramatically more durable in use, and the pattern most functioning pharma fabrics actually run.

Remediation pattern

The fix here is process, not technology. Pull the small group of people who actually use each contested term into a working session and reconcile the definitions in the open. Publish the reconciled definition alongside the history of the disagreement and the reasoning that resolved it. This sounds trivial and it is not. It requires senior sponsorship, patience, and a willingness to accept that the “correct” term may not be the one the central team originally proposed.

Once a term has been reconciled through this process, its lineage in the fabric is not just technical. It carries a small artifact of organizational consent that makes it far more likely to be honored downstream. The semantic layer stops being a dictionary and starts being a contract.

A second consideration, often overlooked, is that the semantic layer needs to be versioned in the same way source code is versioned. Business terms change. A “customer” definition that made sense when the commercial model was purely retail becomes contested when specialty pharmacy, direct dispensing, and payer-provided services enter the picture. A semantic layer that pretends definitions are static will silently accumulate mismatches with the way the business actually operates. Treating each reconciled definition as a versioned artifact with a change history is the difference between a semantic layer that ages gracefully and one that quietly diverges from reality.

Warning Sign 4: Vendor Lock-In on the Fabric Itself

The fourth warning sign is more subtle because it does not necessarily surface until years into the program. A fabric platform is chosen, often a single vendor’s integrated stack, and the metadata, semantic definitions, transformation logic, and governance policies are all expressed in that platform’s proprietary formats. Everything works. And then, three or four years in, a change of leadership, a change of licensing terms, or a change in the underlying strategy makes the team wonder how they would move off the platform if they had to.

The honest answer, in most cases, is that they cannot. The fabric’s value has been fully embedded in a form that only that vendor’s tooling can execute. The data itself may be portable. The intelligence layer that turned raw data into governed, semantically consistent, policy-enforced data is not.

The pharma industry is particularly exposed to this pattern because the fabric layer often sits above investments in Veeva Vault, SAP S/4HANA, Snowflake, Databricks, and various validated GxP systems that each represent multi-year commitments in their own right. Adding a fabric on top can create a stack whose combined switching cost is measured in tens of millions of dollars.11 That is a legitimate business decision to make, but it should be made deliberately, not by accident.

$4.55B Projected global data fabric market by 2026, up from $3.18B in 202512
18-36 Typical months for full enterprise data fabric implementation and expansion2
85% Of biopharma executives planning increased data, AI, and digital investment in 2025-2612

How the lock-in accumulates

Vendor lock-in in a fabric context rarely starts as an obvious commitment. It accumulates through small choices, each of which looks reasonable at the time. Semantic definitions are expressed in the vendor’s native modeling language because it is faster than writing portable definitions. Policies are written in the vendor’s policy DSL because the alternative is a generic engine that needs custom integration. Lineage is captured in the vendor’s proprietary lineage format because it integrates cleanly with the vendor’s monitoring tool. Each choice is locally optimal. The cumulative effect is a fabric whose intelligence is inseparable from the vendor’s tooling.

Remediation pattern

The workable pattern is not to avoid using vendor tooling. It is to keep the highest-value artifacts in portable forms even when the vendor’s tools operate on them. Semantic definitions expressed in a standards-based ontology can be consumed by multiple platforms. Governance policies expressed as declarative rules can be re-implemented on a different engine with predictable effort. Lineage captured in an open format such as OpenLineage can be replayed against a new platform.

The Sakara Digital perspective. We are not vendor-agnostic in the sense of pretending all platforms are equivalent. We recommend platforms all the time. What we advise against is expressing the strategic intelligence of the fabric, the semantics, the policy, and the lineage, in forms that only one vendor’s tools can read. Keep the vendor tooling. Keep the intelligence portable.

This is not a hypothetical concern. Vendor consolidation, acquisition, and pricing changes in the data platform space have accelerated over the last three years. A fabric strategy that quietly assumes today’s vendor landscape will persist for the useful life of the platform is making an implicit bet that experienced pharma IT leaders would not make explicitly.

There is also a subtler form of lock-in worth naming: expertise lock-in. When a fabric implementation is done entirely by a single vendor’s professional services team, using that vendor’s preferred patterns, the resulting operating capability lives partly outside the organization. The internal team can operate the platform but often struggles to extend it in directions the original implementation did not anticipate. Building at least a core of internal capability during the implementation phase, even if it slightly slows initial delivery, produces a program that is easier to evolve and easier to defend when a subsequent leadership team reviews the architecture.

Warning Sign 5: GxP and Commercial Data Treated the Same

The fifth warning sign is the most consequential, because when it goes wrong it tends to go wrong in the way that regulators notice. It is the tendency to treat validated GxP data flows and commercial or research data flows as fundamentally equivalent inside the fabric, applying the same access, transformation, and quality controls to all of them.

The intuition behind the equivalence is understandable. From a pure data engineering perspective, a batch record and a sales call log are both tabular data with lineage. Applying uniform controls is simpler. It is also incorrect. GxP data flows are governed by ALCOA+ principles that require attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available records, with change control regimes designed to preserve those properties across every transformation.13

Where the divergence matters

When commercial data flows through a fabric, aggressive transformations, opportunistic denormalization, and rapid schema evolution are all healthy behaviors. They accelerate insight. When GxP data flows through the same fabric under the same operational patterns, each of those behaviors is a data integrity risk. A transformation that is not fully documented and validated breaks the audit trail. A schema change applied automatically breaks the reproducibility that inspections rely on. A performance optimization that quietly drops apparent duplicates can, in a manufacturing dataset, delete evidence of a batch anomaly.

The 2025 EU GMP Annex 11 draft, published for consultation and expected to be final in 2026, explicitly treats data in motion and the controls around AI-enabled and cloud-hosted computerized systems as core GMP requirements, with a companion Annex 22 focused on AI validation.14 A fabric that cannot distinguish GxP flows from commercial flows at the runtime enforcement level is not aligned with where the regulatory environment is going.

The failure mode we most want to prevent. A fabric team, under pressure to demonstrate consolidation, moves a validated flow into the general purpose fabric without documenting the equivalence in controls. The flow works. A year later, an inspection notes that the validation state of the original system does not clearly cover the new flow. The remediation is expensive and slow.

Remediation pattern

The workable pattern treats the fabric as a set of tiered zones, not a single uniform surface. GxP-validated flows live in zones with stricter change control, full audit trail preservation, defined validation status for every transformation, and explicit boundaries that prevent them from being casually merged into non-validated flows. Commercial and research flows live in zones with faster iteration, opportunistic transformation, and lighter change control. The fabric knows which zone a given asset belongs to and enforces different behaviors accordingly.

1

Classify every source and asset by regulatory zone

GxP-validated, GxP-relevant but not directly validated, commercially sensitive, research, public. The classification drives the runtime behavior; it is not a documentation exercise.

2

Define enforcement primitives per zone

Which transformations are permitted without validation review, which require it, and which are forbidden. Encode these in the fabric’s policy engine, not just in a governance document.

3

Prevent zone crossing by default

Flows that cross zones require explicit, documented approval. The default behavior of the fabric should be to raise an exception, not to silently merge.

4

Keep validation state visible in metadata

Every GxP asset in the fabric should carry its current validation state as active metadata that consumers can query. This closes the gap between what the fabric thinks it is doing and what quality assurance is signing off on.

When Data Fabric Actually Works

Against those five warning signs it is worth being specific about what a functioning data fabric looks like in a pharma context. The programs we see delivering value share a small number of characteristics, and they are surprisingly consistent across companies of very different sizes.

They start narrow. Rather than a boil-the-ocean announcement, the initial fabric scope is two or three high-value data domains where the pain is well understood and the sources are within realistic reach. Clinical trial operations paired with safety is a common starting point. Field team activity paired with medical inquiry is another. Manufacturing quality paired with supply chain is a third. The scope is chosen because it produces a defensible business outcome within twelve months, not because it demonstrates architectural ambition.

They pair architectural centralization with domain accountability. This is where hybrid data fabric plus data mesh patterns are showing up most often in practice.15 The fabric provides the technical integration, the active metadata, and the enforcement primitives. Domain teams own the products, the definitions, and the quality of the assets they publish into the fabric. Neither pattern alone tends to work; the combination gives central IT the coherence they need and gives functions the autonomy they need.

What we look for when a program is working. A specific business decision that was previously slow is now measurably faster and better sourced. A specific compliance question that previously required an ad-hoc data pull can now be answered from the fabric with lineage that a quality auditor will accept. A specific AI use case that previously stalled on data quality is now in production. If none of these are true after twelve to eighteen months, the program has drifted, no matter how good the architecture diagrams look.

They budget for the semantic and organizational work, not just the platform. In the programs that succeed, roughly half of the total cost over the first two years is people work: reconciling definitions, redesigning stewardship, changing how functions ask for and receive data. Programs that plan around a much smaller ratio of people to platform spend consistently underdeliver.

They keep the validated GxP surface deliberately separate. Even in mature programs, GxP flows tend to run in a fabric zone with its own change control cadence, its own validation lifecycle, and its own audit trail preservation guarantees. The fabric provides consistency of access and metadata across GxP and non-GxP zones without pretending they are the same operational surface.

What the successful programs look like at inspection

A functioning fabric changes the character of an inspection response. Instead of running around to source systems to answer a data integrity question, the quality team can produce lineage, transformation history, and validation status of the exact records in scope from the fabric’s active metadata layer. This is not a nice-to-have. Given the 50 percent year-over-year jump in CDER warning letters in FY 2025 and the ongoing intensification of data integrity enforcement, being able to respond authoritatively and quickly is a real risk-reduction outcome that the fabric enables.4

Dimension Drifting fabric program Working fabric program
Metadata Passive catalog, updated on a schedule Active metadata, event-driven, triggers downstream actions
Governance Written policies, informal enforcement Policy-as-code with defined enforcement perimeter and honest gaps map
Semantics Central dictionary, ignored downstream Federated contracts co-owned by consuming functions
Vendor posture Intelligence embedded in vendor-proprietary formats Vendor tooling accepted, high-value artifacts kept portable
GxP handling Same controls as commercial data Tiered zones with distinct enforcement primitives
Business outcome Architecture diagrams and stewardship charter Named decisions faster, named compliance questions answered from lineage

The organizational operating rhythm that keeps a fabric working

Beyond architecture, the programs that sustain their value share an operating rhythm. Data product owners meet with fabric stewards on a fixed cadence. Semantic disputes are surfaced quickly and resolved in the open rather than left to accumulate. Validation state changes on GxP flows are communicated proactively rather than discovered at audit time. The fabric is treated as a product, not a project, with a named owner, a roadmap, and a lifecycle. When any of these elements is missing, the fabric can still function technically for a while, but the organizational memory of why it was built the way it was built starts to erode. That erosion is the slow-motion version of the drift we described in the warning signs above.

Conclusion

Data fabric is not the problem. It is a legitimate architectural response to a real problem, and in the programs where it is implemented with discipline it delivers on its promises. The failure mode is more specific than “fabric does not work.” It is that a fabric implementation without active behavior, enforceable governance, negotiated semantics, portable intelligence, and tiered GxP handling quietly degrades into wallpaper. Everything looks in order on the wall of the enterprise architecture deck. Nothing has actually changed about how the organization uses its data. The five warning signs in this article are the ones we most often see when that drift is happening, and each has a remediation path that does not require replatforming.

The five warning signs are not exotic. They are the ordinary failure modes that emerge when architectural ambition outruns organizational readiness, and they are treatable when they are named early. The programs that avoid them do not necessarily start with a bolder architecture. They start with a narrower scope, a more honest map of what is inside and outside the enforcement perimeter, a semantic layer that is negotiated rather than imposed, and a clear distinction between GxP and non-GxP operating surfaces. None of this is glamorous. All of it is what makes a fabric survive its second and third year in production.

Sakara Digital works with pharma and biotech organizations that are building or repairing this kind of data fabric, particularly at the point where governance, semantics, and validated GxP flows have to coexist in one architecture. If you are running a fabric program that is not producing the outcomes it was funded for, or if you are early enough in the design phase to make the load-bearing decisions deliberately, we are happy to have that conversation on your terms.