Foundations of a Business Ontology
A business offers services by using its resources. These resources can be its own people, infrastructure (equipment, facilities, assets, machinery, etc.), the people and infrastructure of its trading partners (other organizations), and consumable resources (e.g. raw materials).
For instance, a consumer electronics company manufactures products (a service) using its manufacturing staff (people), manufacturing equipment, manufacturing facilities, and parts supplied by its suppliers (organizations). It also supports consumers (another service) using its support staff (people). It offers repair services for products that do not function as designed, using its repair facilities, repair equipment, and people.
Roughly, the things in the business world can be broken down into things I do, and the things I do them with. The things I do are verbs, and the things I do them with are nouns. These nouns, or entities, can be grouped into the domains of people, infrastructure, equipment, organizations, and raw materials. All of these could be viewed as resources within the enterprise. All of these entities work together to create a product or provide a service. These entities have characteristics, some of which we can perceive through our senses (e.g. colour, hardness, thickness, sweetness, odour, etc.), and some of which become apparent when the entity is utilzed (e.g. strength, durability, adaptability to other entities, etc.). Some of these entities have capabilities (people that have skills, equipment that can be used to do specific tasks) that only become apparent when the entity is utilized. For instance, a person might be capable of packing small boxes, but not capable of packing pallets. Similarly, a truck can be capable of carrying liquids, but not flammable liquids.
Fig.1: Types of enterprise resources
When creating a model of an entity, it is possible to create a single model for all of its characteristics irrespective of how its utilized, or to create a model of the entity independent of utilization, and another for when the entity is utilized. Creating a single model for the entity for all of its utilization scenarios is feasible, but would probably result in a bulky model that probably doesn't cover every eventuality. On the other hand, creating a model for the entity independent of utilization will result in a relatively simple and resuable model of the entity. Let's consider the example of a person.
Richard is a father of 2 children, married to Anne, and owns a house in the suburbs of Amsterdam. He is 40 years old, and he was born in the United Kingdom). He works as a IT manager in a bank, and is a good tennis player. First, let's consider the characteristics of Richard independent of any of his activities or roles (father, husband, IT manager, tennis player, house owner). Richard is first and foremost a person, and he has a gender (male), age (40), and a place of birth (somewhere in the United Kingdom). These characteristics are true of any person (gender, age, and place of birth), and we can create a simple model of a person.
Next, Richard has several roles. His 2 family-oriented roles are that of a father and that of a husband. A father is a type of parent, and parenthood requires children. Unless we want to capture specific behaviour of a father, then it is more efficient to model the role of a father as a parent. We can then reuse this role if we want to create a model for Anne. Similarly, we can either model his relationship with Anne through the role of a husband or spouse. If there isn't any husband or wife specific behaviour we want to capture, it is sufficient to capture the role as a spouse.
Fig.2: Segmenting the roles of a person
When Richard is at work, he will usually exhibit the behaviour of an IT manager. As an IT manager, he will need to have an understanding of his responsibilities, his daily tasks, his deliverables, and his accountability. All of this behaviour is directly related to the organization where Richard works. A model of this organization, knowledge required by Richard to perform his role, tasks, and deliverables will be shared to some extent by other people in his department and by other people in his organization. In order for Richard to work in his organization, he first needs to be an employee of the company. An employee has a contract (permanent or temporary) which outlines their compensation, position, and responsibilites. Every person who works in Richard's organization is an employee, and so we can make a reusable model for an employee for all members of the organization.
Fig.3: Separating the different roles a person can have
Similarly, almost any physical object has characteristics that are applicable all the time, and other characteristics that are true some of the time. For instance, a table is a piece of furniture that has a smooth flat top that is usually supported by one or more vertical legs. Books and computers can be placed on the table, and a person can choose to use the table for work. Similarly, plates of food can be placed on the same table, and it can be used for a social event. The table's characteristics, however, remain the same. It has 4 legs, perhaps a few drawers, and a large flat surface. There are several ways the table can be used, and the table can play the role of a dining table or a desk. It is possible to capture a lot of information about the table. We can capture information the material used to construct the table, its load-bearing capacity, its size and dimensions, and even the name of the people who made the table. Given that we are building a business system, the nature of the business will govern what kind of information, and how much information, we need to capture about the table.
Ontological depth: Creating microworlds
How much information should we capture about the nature of things for a business? It really depends on the nature of the business, and how much value each additional level of detail adds to the business. The perspective a business has on information usually depends on its operating business models. The required amount and depth of information differs from business to business. A shop that sells articles of clothing will have an ontology that covers the names of the materials used in their clothing, but probably not require the molecular structure of each of these materials. An ontology should represent the concepts that are important for the business to function, and refer to existing ontologies whenever possible. The primary objective of an ontology is to communicate the nature of things relevant to the business.
Concepts that are common to other businesses, such as molecular structures of materials, should be managed through references to external ontologies, such as industry standards.
Each business should create an ontology that draws clear boundaries on its knowledge requirements. An ontology for clothing could cover materials, molecular structures, the elements that make the molecules, the atoms that make up the elements, and the sub-atomic particles that make up the atoms, but in doing so, the business derives little value. Thus, the business creates an ontology of a microworld, an ontology that is applicable to its business boundaries. A key aspect of creating an ontology is to create a microworld, and identify the applicable boundaries for the business.
To see how business shape their own microworlds, let's consider 2 business domains: a warehouse and a furniture store that exclusively sells tables. Each of them has to deal with the notion of a table. Let's explore some relevant models for tables in each of these cases.
The warehouse: Tables are used in the warehouse for packing and unpacking items. Tables should be sturdy, capable of bearing loads of up to 500 kilograms, and have between 2 to 3 square meters of space. This table is relevant to at least 3 people, the operator who uses the table, the asset manager who manages things that belong to the company, and the procurement manager who buys things for the company. The operator is primarily concerned with the fact that he or she has a sturdy working surface. In fact, the operator doesn't even require a table, just a flat surface that has the necessary space and that is capable of bearing the required load. We could build a model that doesn't even consider the fact that a table is required, and just model a generic "flat surface", and treat the table as a flat surface. Operationally, it is even possible that the operator uses the floor when there isn't a table available, as the floor is a flat surface that meets or exceeds all the requirements. Next, the procurement manager is primarily concerned about purchasing tables from vendors. The procurement officer needs to know the exact dimensions of the table, and the materials from which the table is made. Finally, the asset manager, who is responsible for ensuring that tables remain in the company until they are intentionally removed, needs to able to identify and locate each table.
Fig.4: An ontology for tables for the warehouse microworld
The table store: The table store sells several kinds of tables, such as dining tables, desks, coffee tables, and table-tennis tables. Salespersons and customers need to know the features of each kind of table, the materials used to make the tables, and their dimensions.
First, let us look at the nature of each of these tables:
Dining table: A dining table is a table where meals are served. A dining table will have seating capacity for at least 1 person. The surface of a dining table should be at a level suitable for dining by adults between 140 cm and 180 cm in height.
Desk: A desk is a table with a writing surface and usually drawers or other compartments. A desk will have seating capacity for 1 person. The surface of a desk should be at a level where an adult between 140 cm and 180 in height can write comfortably. An adjustable desk is a type of desk where the height of the desk can be adjusted. Note that workplace regulations in EU countries make it mandatory to use adjustable desks in offices.
Coffee table: A coffee table is a long and low table, often placed before seating in a living room, on which drinks may be served and magazines or books may be placed. A coffee table will have a surface area and it should be of a height where it is easy to reach for drinks or reading material from a seating area near the coffee table.
Table-tennis table: A table-tennis table is 2.74 m long, 1.525 m wide, and 76 cm high. It is made with Masonite, a type of hardboard and layered with a smooth, low-friction coating. It is used to play table-tennis, and should be placed in a room with plenty of clearance for the players.
Fig.5: A simple taxonomy of tables
Having characterized 4 different types of tables, we can define an abstraction for a table, which can be defined as a piece of furniture that has a smooth flat top that is usually supported by one or more vertical legs. Examining the nature of the 4 tables, we can find some common patterns. First, almost all of them are named based on how they are used or situated. A dining table is a table used to serve meals, usually placed in the dining room. A desk, which can also be called a working table, is a table used for work, usually placed in an area intended for work, such as an office. A coffee table is used to serve beverages, usually placed in the living room. A table-tennis table is used to play tennis, and is usually placed in an entertainment or sports-oriented area.
So, from this, we can derive 2 characteristics that are common for tables, one for how the table is designed to be utilized, and the second for where the table should ideally be situated. We can also make the hypothesis that the most salient characteristic of a table, i.e. the distinguishing and principal characteristic, is how the table is used. In fact, making a reference between a person and a specific type of table will result in some implicit inferences. For instance, if I call up my friend Richard in the evening, and ask him what he is doing, and he responds with either of the following:
1) "I am eating dinner at the table."
2) "I am eating dinner at my desk."
From the first statement, I can assume that Richard is at home with his family eating his dinner at his dining table, and tell him that I will call back later. From the second statement, I can assume that Richard is still at work, and demand to know what he is doing at work at such an hour. Thus, our hypothesis can be formalized into the fundamental basis on how different types of tables should be modeled, and using its manner of utilization as the key for classification.
Fig.6: An ontology for a store microworld
For the table store, it is important to catalog the different types of tables, and use it as a fundamental cornerstone in their business. The primary purpose of different types of tables can become the basis of product merchandising. For instance, all of the dining tables can be placed in one part of the store. Coffee tables, which have a similar purpose, can be placed near the dining tables. Desks, drawing tables, and other work-related tables can be placed in another part of the store. Pool or billiards tables and table-tennis tables can be placed in a gaming area of the store. Similarly, if the table store were to have an online store, the purpose can be used as the basis for categories.
© Flying Bed
Fig.7: An ontology for a dual-purpose desk-bed
The store microworld has an ontology for tables based on a single purpose. On the other hand, it is possible for tables to have multiple purposes. I can choose to work on my dining table. I could choose to nap on my couch and not my bed. In the world of sales, the classification of products is quite important, the classification key is based upon the principal value the product provides to the customer.
If however, we were considering a model for a hotel or office that uses dual-purpose furniture, we will require a model that captures the different roles for furniture. Similar to the example for Richard, who is always a person, and sometimes a father or IT manager, a piece of furniture can have the roles of being either a bed or desk. Once again, such a model should only be developed if it adds business value, and should not be the result of modeling rigour. For instance, if we need to capture information about changing bedsheets for the desk-bed, we need to capture its behaviour as a bed. If employees bring their own bedsheets to work, and the desk-bed is primarily used as a desk, capturing its behaviour simply as a desk is sufficient. On a personal note, I think the desk-bed is a terrible idea for the workplace, and this example shouldn't be seen as an endorsement. I do think it is a nice idea for a very small apartment.
In these 2 businesses, one had a need to establish different types of tables (the table store) and another didn't (the warehouse). The purpose of developing a microworld is to identify the boundaries for an ontology. If we were to examine the microworld of a furniture factory, then the ontology for a table would be far more extensive. For instance, we haven't covered construction materials, coating, veneer, leg dimensions, and adjustability, which would be necessary in a microworld concerned with manufacturing tables.
