Building Enterprise Ontology — Part II — Business Overview— What is an Enterprise Ontology?

Managing the operation of a large enterprise company is challenging. Sometimes, you have to read a 300-page manual for every little action or write a 300-page manual to get things done right and get everyone to read it. Enterprise Ontology can solve this challenge by efficiently organizing the structure of the organization's hierarchy of resources and applying specific policies to various parts of the hierarchy. This part is meant for business analysts and IT administrators and explores some examples of such problems and how ontologies can simplify the solutions.

This is part II of the series on "Building Enterprise Ontology," and you are welcome to read the other more technical parts here:

• Part I — Overview of Ontology Solution on AWS.
• Part II — Business Overview — What is an Enterprise Ontology? (this post)
• Part III — Ontology Data Store — AWS Cloud Directory.
• Part IV — Ontology Access API — GraphQL on AppSync and Lambda Resolver.
• Part V — Ontology Setup and Data Loading — AWS Step Functions Automation (coming soon).
• Part VI — Reliable Authorization with Ontology — Amazon Verified Permission (coming soon).
• Part VII — Natural Language Interfaces for Policies — Amazon Bedrock Agents.

Questions that can be answered with Ontology?

Ontology plays a crucial role in answering diverse and complex questions within large enterprises, addressing everything from employee privileges and regulatory compliance to customer service policies and promotions. For example:

• Can a specific employee access a particular customer record?
• How many days of vacation should I offer to a new employee in Germany?
• What is a valid air pressure for a minivan delivery truck in the winter?
• Can you ship whiskey from Texas to Florida?
• What is the minimum driver age for renting a car in Alabama?
• Can you return a used pair of shoes to the Costco facility in Washington?
• What do you do when you discover that the temperature on the display cooler in the fish department in the supermarket is higher than 5°C?
• What maximum discount can be offered to a new customer over 55 who wants to switch to your mobile service without the supervisor's approval?

At the heart of addressing these inquiries lies the need to navigate a labyrinth of policies dynamically crafted to balance various facets of business operations for safety, efficiency, sales, and profitability. They are also specific to narrow aspects of the operation, as "it depends on the context" is the most common answer to "can I/should I…" questions. The policies are also affected by changing laws and regulations in different jurisdictions and market changes such as competition, supply, demand, and marketing promotions. A significant challenge for large enterprises is ensuring employees are up-to-date with these ever-changing policies, a task made increasingly difficult by the high turnover and mobility seen in younger workforces.
The ideal solution is a system where every employee or customer can ask such questions and get current answers based on the context and the only relevant policies. Managers can update policies in response to changing business needs, with the assurance that these updates are immediately operational. Furthermore, it centralizes policy management, allowing all organizational data systems to reference a single source of truth for policy documents rather than embedding disparate business logic across multiple systems. This approach streamlines policy administration and ensures consistency and compliance across the enterprise.

Example of policy Q&A for shipping of Alcohol

Enterprise Ontology Core Concepts

The core concepts of Enterprise Ontology are hierarchical data and policies attached to specific nodes on the hierarchical trees. Hierarchical data is not only related to the popular org charts, which present the organization's hierarchy. It is also based on the concept of Trees, a fundamental and widely used data structure in computer science. Trees are used for many tasks, including organizing and searching large sets of entities. The policies defined in the organization shouldn't be on the lowest level of the leaves of the trees of the employees or the customers, as it is not practical to have an entirely personal policy. The policies shouldn't also be on the root level as it is impossible to define a single policy that will be applied to the whole organization without exceptions and context details. The policies are scattered across the various levels of the hierarchy, and thanks to the ability to traverse the tree hierarchy efficiently, it is easy to get the specific list of policies relevant to each leaf or node.

Let's explore some of the example questions above and see how they relate to the concepts of hierarchy data structure and policies:

For example, "What is the minimum driver age for renting a car in Alabama?" can be based on the rental company's global (root) policy, a policy unique to the US (mid-level node), or even a more specific policy to Alabama (leaf). Each jurisdiction might have different laws and regulations, or the company can decide to self-regulate itself due to recent incidents.

Another example of "What is a valid air pressure for a minivan delivery truck in winter?" is more complicated as it also requires taking local weather conditions, and the ontology must include details such as facility location and adjust the policy to the current conditions in each place.

Suppose you try to define a policy at a higher level ("You have to turn on vehicle headlights between November and March," for example). In that case, you risk wasting resources on the many sunny days during this period or missing a few low visibility days outside these months. The same logic applies to giving generous discounts in regions where you don't have any competition and losing business in other areas where the competition is intense. Specificity is the key to efficient operation.

Defining Ontology Schema

The best place to start defining your organization's ontology is the Active Directory (AD), which includes regions, offices, groups, and users. Over time, you can add more entities, attributes, and relationships to better describe the fine-grained details of the organization's operation. Ontology is a flexible extension of the AD that can serve many other data systems in the organization with policies related to the various entities of these data systems.

For example, Ontology can help CRM systems define customer-related policies based on the customer's region, size, segment, or other group memberships. Ontology can also map the fleet of vehicles or other resources the organization operates daily and define its various policies for these resources. Determining the ontology schema is similar to business analysis for different data systems. It is similar to defining a relational database schema for other data systems in the organization.

Let's explore a few examples:

A rental company wants to answer the question, "What is the minimum driver age for a rental car?". If we review the multiple public web pages on this topic of one of the leading rental companies, we can create the following Ontology:

Rental car minimum driver age ontology and policies

The benefits of this structure are clear, as it is easy to understand and calculate the minimum driver age in various use cases. The default age is defined at the root of the ontology, and it is overridden on different levels based on the location or the type of vehicle. It is also easy to add more exceptions and specific use cases by extending the tree for additional locations, vehicle types, and other aspects such as the customers ("group of more than two people must have at least one driver over 23", for example). It is also easy to load other policies on the ontology, such as insurance requirements, marketing promotions, types and lengths of driving licenses, etc.

Let's explore a more complex example of shipping policies. Shipping Alcohol across state borders is a complex issue that the following ontology and policies can represent:

Alcohol Shipping Restrictions

Once you understand the policy format, calculating a specific policy decision is still reasonably easy. For example, if you want to know if you can ship wine to Florida, you can see on the right that, in general, wine is allowed to be shipped unless forbidden at the state level. The Florida (FL) on the left doesn't add a specific wine policy; therefore, the shipment is permitted. On the other hand, Beer is forbidden in general on the right, and Florida has a particular Beer policy that allows shipping for "Intrastate Retailer Shipment" (the fourth Y on the "Beer: N | N | N | Y" policy for FL). Therefore, such beer shipment is permitted in Florida.

Business analysts take complicated policies to implement and translate them into the ontology's entities, facets, relationships, and policy documents. The mapping can include the company's employees, customers, products, and resources. They can describe how the business is organized to meet market requirements with the correct hierarchy definition. They should then decide which section of the hierarchy to apply any policy for their business's operation. The hierarchical structure of the ontology allows easy ways to override some higher-level policies with more specific lower-level ones, as we saw in the examples above.

Generative AI to the rescue

Generative AI technology such as GPT, Claude, and other large language models (LLM) can make the two tasks described above easier:

• Policy Q&A — Instead of asking the internal employees to learn the structure of the ontology and policy format and spend time reviewing the data, we will build an agent that automates this process and can answer complicated compliance questions without mistakes.
• Schema Creation—LLM's power in generating structured output based on unstructured natural language input makes it easy to automate the process of generating the various schemas in the ontology, including the hierarchy structure and entity attributes.

We will cover these AI-based parts of the solution in one of the coming parts of this series.

Ontology Evolution

The Ontology can evolve over time, starting with the AD schema and adding more organizational data. The ontology can be connected to different data systems to support rich policy language based on organizational structure and hierarchy.

As we saw in the example above, the policy documents are not processed by the ontology itself at the beginning, and the ontology is only responsible for storing them and retrieving them for each node or leaf when queried by external applications. The applications are also responsible for resolving conflicts in a policy when similar policy documents (for example, for wine shipping or minimum driver age) have different values from different levels of ontology. The application can prefer higher or lower levels and apply "And" or "Or" operators on their values and similar business logic.
In part V of this ontology series, we discuss the option to transfer the decision on the policy outputs to a more reliable service, Amazon Verified Permissions (AVP). More critical authorization permissions should be handled with more scrutiny and care, and we will discuss building the schema for the AVP service and the policies to be processed by it. Nevertheless, other decisions can be delegated to external applications, such as the LLM agent, that use the ontology only as an efficient way to store the hierarchical structure and the relevant policy documents on it.

Summary

Developing an ontology enhances and broadens the capabilities of traditional Active Directory, enables it to encompass a more comprehensive array of enterprise operations, and exposes it to natural language Q&A interfaces. This advancement significantly streamlines the creation and application of fine-grained and intricate policies throughout an organization. In this post, we explored various business scenarios that underscore the necessity for an ontology and the analytical processes involved in its formulation. In the coming parts, we discuss the technical aspects of implementing dynamic ontologies to meet the specific requirements of different companies and the enterprise-grade requirements of simplicity, scalability, availability, and security.