we can apply AI, we need two things: a core understanding of the business problem we are attempting to solve and a mechanism for identifying the important signals contained in the data. The ontology contains an overall set of labels for important business concepts—product names and descriptors. Marketing, for example, must track campaigns with categories for types of promotions, events, audiences, targets, personas, segments, assets, media, channels, and so on. Engineering uses classifications for techniques, materials, designs, problems, and specifications. Ecommerce websites allow customers to shop according to the classifications that are meaningful for them, such as brand, product type, size, color, and style.
If the ontology includes all of these different types of structures throughout the enterprise, then how can it be practical? The answer is that ontologies provide a consistent reference point to capture knowledge relationships. We make an ontology practical by building it piece by piece for particular purposes and to solve specific problems. The value of the ontology continues to increase as it is further refined and applied to organizational processes. Over time the ontology matures and is applied to solve customer problems and improve information flows.
Most organizations have costly and hard-to-manage problems with data quality. Because of this, technology integrations are brittle, making it slow to deploy changes to customer-facing functionality. This friction inexorably slows down the information metabolism and reduces the speed of product, service, and value creation. The ontology has the potential to vastly reduce these challenges.
The key to building a practical ontology is to focus on application and usage. Ontologies require consideration of focused problems and specific contexts. They become the North Star for new applications and systems, for new technology deployments, and for new products and services. Ontologies provide a guide point and are aspirational—they are never complete. If an ontology is not developed within an application-centric framework, it will become an academic exercise—a science project—with no end and little value.
ONLY A DELIBERATE APPROACH WILL WORK
Some AI experts actually frown on the idea of explicitly and carefully building an ontology to solve AI-related problems or power AI technologies. They imagine that the answer lies strictly in the data, and that statistical algorithms can analyze that data and automatically create a structure from it. But as you can imagine from what I’ve described so far, this approach is inadequate. A machine cannot read a random collection of data and understand the goals of the business. Though AI can help identify patterns, only a comprehensive human-driven review of the data, systems, and processes can create the Rosetta Stone that the whole business will run on.
That doesn’t mean you must start from scratch. Organizing principles and architectures are already embodied across multiple systems and embedded throughout the organization’s processes. In practice, these architectures tend to be fragmented, lacking consistent, standard ways of managing different levels of detail. This effectively makes them “accidental” ontologies. Accidental ontologies result from changes that are not governed or managed, business units that do not collaborate, vendors with inconsistent architectures, and developers who create technologies without reference standards. They can also arise from integration of acquisitions, consolidation of data sources, architecture layers evolving at different rates of change, and other changes in day-to-day operations. Frequently, they are haphazard and inconsistent because there is little awareness of how they should be integrated, cross-mapped, unified, or managed. They present many varied views of the truth, in contrast to the unified view represented by a deliberately created ontology.
How do these incompatible views develop? As I described in chapter 1, different parts of the organization have varying process clock speeds and rates of change. Social media marketing requires fast turnaround and fast responses to customer issues. The social media technology also changes rapidly within the already fast-evolving digital marketing technology ecosystem. Because the functionality of those systems will constantly evolve, the underlying architectures, organizing principles, and models will never be completely aligned.
While they may try, IT staffs rarely have the resources or skills to solve these problems in a systematic way, by applying end-to-end principles combined with metrics-driven feedback loops in ways that are appropriate to the problem. A carefully developed comprehensive ontology can help. If the social media marketing technology needs to interface with an ecommerce system, which will have slower-changing components, the ontology will provide a translation layer between faster-and slower-moving layers. The ecommerce system may sit on top of an enterprise resource planning (ERP) system that changes at an even slower rate and, once again, the ontology can act as a shock layer between those systems.
Ontologies Vary from Industry to Industry and from Business to Business
You could imagine a world in which a single organizing principle would allow all data structures to interoperate. While there are many standards to improve interoperability, a perfectly interoperable world does not exist, because businesses and their processes are diverse. The concepts and processes that comprise the world of a commercial insurance company, for example, are fundamentally different from those of a life sciences company. Insurance is about risks and regions, types of businesses, exposure, and so on. A life sciences company deals with diseases, treatments, indications, generic compounds, drug brands, mechanisms of action, and biochemical pathways, among other things. In each case, the ontology describes the various concepts and buckets of information along with relationships between those concepts—for example, “risks in a region” or “treatments for a disease.” Taxonomies describe each concept, and the ontology consists of all the taxonomies and all the relationships among them. But even for companies within the same industry selling to the same customers and with similar products and services, there are differences. Their competitive differentiation comes from differences in how they interact with their customers and how they present solutions, communicate, and position their brand in the marketplace. Their ontologies will reflect those differences and embody their competitive advantages.
BUILDING AND APPLYING THE ONTOLOGY
Ontologies have to solve specific, meaningful business problems. It takes time and money for organizations to develop the necessary detailed use cases and scenarios with the associated content models and ontology. However, building ontologies using a holistic approach that correctly identifies information flow dependencies can solve many related problems at little additional cost. I will describe two ways to begin building an ontology: a “user- and problem-centric” approach, which focuses on the users and their challenges, and a “data- and content-centric” approach, which focuses on organizing the data. Enterprises have to use both approaches to some degree or another; user challenges deal with information and data, and data has to be organized around a user need or context.
The User- and Problem-Centric Approach to Creating an Ontology
The user- and problem-centric approach, focusing on users and their challenges, includes nine steps:
1.Observe and gather data (pain) points. Many of the world’s greatest thinkers have stated that identifying the problem constitutes most of the work toward finding a solution.5 Identification of the main problem establishes the context for the ontology and relates it to any other problems you’re working on. When solving a problem, one gathers observations and data points from multiple perspectives. Problems have symptoms, and grouping those symptoms together and identifying the root cause for that grouping provides the context for the ontology. The symptoms (data points/observations) can come from anywhere, including customer complaints, interviews with people at the front lines, executive interviews, surveys, journey maps, call logs, search logs, working sessions, strategic plans, competitive analyses, quality problems, usability metrics, and heuristic evaluations. Identifying the source of each observation or data point is important
