Whatever-as-a-Service and the Bad Data Myth
Why Platforms like ServiceNow are Quietly Rewriting the Rules
Everyone says you can’t do artificial intelligence with bad data. And at face value, the argument seems reasonable. But what is the answer then? We can’t simply keep repeating that transformation will take longer than expected without a clearer explanation of how fragmented enterprise data, with all its inconsistency and incompleteness, is supposed to be fixed before AI can safely operate.
And what about the organisations with messy data that are already beginning to see real operational value from AI platforms? Not through chatbots or document summarisation, but through automation, orchestration and decision support embedded directly into enterprise workflows. How does that make any sense?
Well, as it turns out, it is precisely this contradiction that reveals the deeper truth. The biggest barrier to AI inside most organisations has never been bad data. It is that they have never clearly described how the relationships actually operate between people, systems, approvals and the work that flows between them.
Enterprise technology has long been dominated by the simple assumption that systems require clean data. This belief emerged from the era of enterprise resource planning where systems were designed to execute deterministic transactions. If the underlying data was inconsistent, the results could not be trusted. That was fine for a generation, but the same assumption has carried forward into the AI era almost without question.
But artificial intelligence does not simply operate on tables and records. It operates on meaning. And that requires us to stop thinking about this technology in the way we have managed enterprise systems for the past thirty years.
For AI to perform real work inside an organisation, it must understand several things at the same time. It must know what objects exist in the enterprise, how those objects relate to one another, who has the authority to act on them, and how work moves between them. That’s what I mean by understanding the relationship structures of the organisation itself.
We’ve all worked for organisations that have never formally defined these relationships. They exist implicitly inside systems, processes and job descriptions, but rarely as a coherent model of how the enterprise actually functions or behaves. That model has a name. An ontology. And without that model, artificial intelligence is forced to improvise.
Ontology is a word that sounds abstract and so it is rarely used even by the companies that have great ontological solutions, and almost never in executive company. But the concept is straightforward. It is simply the structured representation of the things that exist in an organisation and the relationships between them.
A council, for example, operates around concepts such as citizens, properties, permits, assets and service requests. But the important thing is not simply that these records exist in systems (as a data model). It is how they relate to the work of the organisation.
A citizen may own a property. That property may require a permit before certain activities can occur. A permit must be assessed and approved by an officer. An inspection may later confirm that the conditions of that permit have been met.
Taken together, these relationships describe how the organisation actually operates, how decisions are made, who is responsible and how work flows across the council. Without that structure, artificial intelligence is left guessing or hallucinating. It can see the records, but it cannot understand the work.
Language models don’t fix this. Even connected to the right documents it can only summarise policies or generate reports. But what it cannot do alone is safely execute work across systems, departments and authorities. It does not know which team owns a service, which role must approve an action or how a process should unfold. Those rules do not live in the data alone. They live in the meaning of the enterprise. And meaning is the currency of AI. Said another way, AI runs on infrastructure but it operates on meaning. It’s just that most organisations have never actually modelled what their organisations mean.
So how did we get here? We can all agree that the cloud revolution dramatically expanded the number of systems inside organisations. It has been an appslosion! Sales teams adopted customer platforms, HR teams adopted workforce systems, finance departments moved to cloud ERP solutions and collaboration tools multiplied across the enterprise.
It’s a phenomenon I call “Whatever-as-a-Service”. A decades long application frat party. Connectivity improved dramatically but organisational meaning did not. It actually got worse. Each system introduced its own definition of the world. A “customer” in one application became an “account” in another and a “ratepayer” somewhere else. Integration platforms allowed data to move between these systems, but they rarely reconciled their underlying semantics.
We humans have quietly resolved these inconsistencies through experience and context, not architecture. But Artificial intelligence cannot. For AI to operate safely, the enterprise must first be represented somewhere as a coherent model of objects, relationships, authority and process. But where? This is where platforms like ServiceNow begin to change the conversation.
They have gradually assembled a structure that resembles an operating environment for enterprise work. Through frameworks such as the Common Service Data Model (CSDM) and the Configuration Management Database (CMDB), it is the role of the platform to model relationships between services, applications, infrastructure and teams. Incidents impact services. Services support business capabilities. Teams own responsibilities. Workflows define how requests are approved, escalated and resolved. What emerges is not simply a data platform, but a representation of how the organisation behaves.
You can see this clearly in some of the publicly available architecture diagrams. The ontological elements I am talking about in this article do not sit purely within a data model or the organisation’s systems of record.
Instead they appear in what ServiceNow describes as the semantic and intelligence layers of the platform. This is the connective tissue that ties enterprise data, workflows and AI together. It’s the secret sauce your systems architecture is probably missing if you want to do AI well.
That ontological representation of the business provides something more valuable than perfectly structured data. It provides operational coherence. And when relationships between services, teams and responsibilities are clearly defined, work can move predictably through the enterprise even if the underlying data describing those objects remains imperfect.
Incidents can still route to the responsible teams. Approvals can still reach authorised managers. Changes can still propagate through dependency structures. The ontology stabilises the environment. Which brings us back to the point. Perfect data may be desirable but ontology is essential.
Another critical component of enterprise ontology lies in identity systems. Platforms such as Microsoft Entra or Okta maintain a living map of organisational authority. They define who belongs to which teams, which systems individuals can access and which roles they perform. Those relationships quietly encode part of the enterprise’s operating structure.
For artificial intelligence, this authority layer is essential. An AI system cannot safely approve a payment, provision an employee account or modify a record unless it understands who is authorised to perform those actions. Governance therefore becomes structural rather than procedural. Security, identity and workflow together form the guardrails within which intelligent systems can operate.
Newer AI-native platforms are beginning to recognise this pattern as well. Systems such as Glean (in Australia, via Journ3y), construct knowledge graphs that map relationships between people, documents and projects across collaboration tools. Rather than attempting to impose a new security model, they inherit the permissions already defined in identity and collaboration platforms. If a document is accessible in its original system, it remains accessible in the AI environment. The insight is simple but powerful and this kind of leaning into the identity ontology approach underpins their growing success.
What this also reveals is that the meaning of the organisation can already exist in some places. It is simply scattered across systems, permissions and workflows. The challenge is therefore to surface those relationships. Once they are visible, the AI models themselves that feed the ontological structure become interchangeable. That’s why every big vendor is partnering with every AI model. It’s because ultimately the ontology becomes more important than the model.
The enterprise technology industry spent decades believing that clean data was the prerequisite for effective systems. It’s ok to say, structure the work first, and the data will eventually follow.
This shift carries another implication that the enterprise software industry has begun to recognise. Best-of-breed approaches to software work because humans reconcile the differences. AI cannot without a platform. Artificial intelligence operates far more effectively within environments where objects, relationships and authority are clearly defined. That environment increasingly emerges around platforms capable of modelling enterprise meaning. It’s part of the (very nuanced) argument discussing the “death of SaaS”.
Once such a platform exists, other systems begin to orbit around it. Workflows attach to it. Identity integrates with it. AI agents execute within it. Because ontology has gravity. Not AI. But AI is what captures attention. Ontology is what actually holds the system together.
This is why ServiceNow, Salesforce and Palantir are becoming strategically very very important. They are not simply applications. They are evolving to systems of meaning. And once an organisation begins to depend on a system of meaning, endlessly assembling best-of-breed tools (whatever-as-a-service) starts to lose its economic, financial, and technical appeal.
The bottom line is that we need to think differently about this. For decades we have pursued systems of record where the challenge was believed to be storing information correctly. Artificial intelligence forces a different question. It is no longer about where the data lives but whether the organisation has ever explained what the data means.
Therefore before machines can run the enterprise, someone must describe how the enterprise behaves. That description is not just a bunch of data schemas and lakes. It is an ontology. And the organisations that recognise this will discover that the biggest obstacle to AI was never bad data but understanding themselves.
That said, the answer to all this is not “buy a platform”, though I am glad that platform is now a broadly accepted conversation. It is more like “choose your entry point to platform.” That means identifying coordination failures within the business (problem statement). These coordination failures are usually the result of missing ontology.
I’ve included a simple example below. It reflects the kind of issue that commonly emerges during staff workshops and consultation when organisations are considering new systems. In one organisation we identified around thirty of these coordination problems in just a couple of days.
Let’s consider a common coordination failure like employee onboarding. In many organisations, provisioning a new employee across HR, payroll, finance, identity and IT service systems can take several days.
Coordination problem: Employee provisioning takes five days.
Desired outcome: Reduce onboarding time to two hours.
Why AI alone fails: AI cannot resolve cross-system discrepancies or coordinate approvals across multiple systems without understanding how those systems relate to each other.
The starting point is not the (new system or) platform. It is defining the ontology of the employee domain. That means identifying the core objects and relationships involved like employee, department, role, system access and approvals, and how they relate to one another. An employee belongs to a department. A department grants certain roles. A role determines which systems the employee should access and which manager must approve that access.
Once that structure is defined, the systems can be mapped against it. HR, payroll, finance, identity and IT service management platforms each manage part of that model, but none of them represent it completely on their own. The ontology provides the common structure that allows those systems to coordinate.
This is where platforms like ServiceNow become important.
Inside ServiceNow, those objects can be represented explicitly. An employee record may originate in the HR system, but ServiceNow can model the relationships between the employee, their department, their manager and the services they require. The platform’s data structures, including the configuration management database and related service models, allow those relationships to be expressed consistently across workflows.
Once the objects and relationships are visible, the missing capability becomes clear. Orchestrate the workflow across systems. That is the “simple” answer most execs want.
Using workflow automation and integration capabilities, ServiceNow can trigger provisioning steps across the relevant systems. HR creates the employee record. Identity systems provision accounts and access. IT service workflows allocate devices and system permissions. Finance systems configure payroll records. Approvals are routed automatically to the correct managers based on the defined relationships. So instead of integrating systems in isolation, the platform orchestrates the workflow across them.
At that point AI becomes useful. An AI agent can monitor the onboarding process, detect failures when provisioning steps break, investigate discrepancies between systems and recommend or trigger corrective actions. What previously required manual coordination across several teams can collapse into hours.
The larger point is that employee onboarding is only one example. Once organisations begin mapping coordination failures in the employee domain, a much broader pattern usually emerges.
In workshops and operational reviews across several organisations I’ve worked with, we routinely identify dozens of workflows that suffer from the same underlying problem. Work spans multiple systems, roles and approvals, but no single structure exists to coordinate them.
Examples include the creation and approval of position descriptions, recruitment workflows covering advertising, interviews, references and medical checks, employee induction processes including compliance training, leave request approvals, employee issue or case management, professional development requests and reimbursements, performance appraisal cycles, talent and skills searches, promotions and transfers, employee offboarding, and routine activities such as timesheet submission and approval.
Each of these processes touches multiple systems and involves several roles across the organisation, especially after more than a decade of whatever-as-a-service. Viewed individually they appear to be isolated workflow problems. Viewed together they reveal something more fundamental. The organisation lacks a shared model of how employee-related work flows across its systems.
This is where ontology begins to take shape. Each coordination problem exposes another part of the enterprise model that needs to be defined from the objects involved, the relationships between them, the authority required to act and the workflows that move work forward.
Over time those fragments accumulate into a coherent ontology of the employee domain. But that only works if the organisation has a platform capable of orchestrating across systems once those relationships are defined. Without that capability, the ontology remains theoretical. With it, the coordination problems begin to collapse.
That’s the power of a platform like ServiceNow. With or without clean data.