The AI-Powered Enterprise. Seth Earley

of thousands of relationships represent the semiconductor fabrication world: the knowledge domain of semiconductor fabrication equipment and methodologies.

      These various organizing systems and vocabularies allowed all 14 different knowledge, content, and data systems to be unified under a semantic layer that translated inconsistent information structures into a common framework. This information architecture (or knowledge architecture) also guided the development of the technicians’ experience: in this case, a search interface that let technicians navigate and retrieve their desired content using their mental model of how they thought about the problem.

      This allowed many different types of users with different problems to locate what they needed in the context of their problems. Taxonomies functioned as navigational filters and provided “see also” constructs to guide technicians to their answer. They consolidated multiple information sources from disparate systems using terminology that was mapped through the ontology.

      But the ontology did more than organize content and make queries more effective. It allowed the business to use AI approaches to classify content, identify security and IP issues, and automate some aspects of relationships among parts. The same ontology allows for analysis of anomalies, powers predictive maintenance, and identifies reliability issues and field usage patterns. The data it generates feeds upstream design and manufacturing processes to further improve products and innovate in semiconductor manufacturing—and to sustain Applied Materials’ leadership in that space.

       To Be a Source of Truth, Ontologies Must Be Comprehensive and Architectural

      The ontology becomes a reference point for the organization that provides consistent naming, structures, and standards for applications and new technologies. It becomes a source of truth.

      The ontology represents knowledge of the information structures and processes that drive information flows throughout the organization. The ontology is representative of products, services, processes, problems, tasks, intents, interests, user types, roles, content, data types, reference architectures, navigational structures, security classifications, applications, and every other entity, whether virtual or physical, in the enterprise. Any entity that someone interacts with can be part of the ontology.

      But it’s not just the elements of the data that count. The ontology reflects the architecture of that data. Data fundamentally has an architecture. It has to. Financial systems have charts of accounts. They have to. Algorithms can do a great deal with messy or missing data, but they must have a reference point containing the labels and information as a basis to find patterns. Pattern matching is inherently about classification, and the ontology forms the core structure for classifications of all sorts. Data dictionaries are part of the ontology; product catalogs are part of the ontology; financial charts of accounts are part of the ontology. The ontology represents the knowledge domain of the enterprise.

      Before 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