may not be functioning optimally) can see the source and the observation or symptom can be justified. This is part of the audit trail of the ontology.
2.Summarize into themes. Since we don’t solve one issue at a time and multiple issues can have the same cause, you must group and categorize the problems. (Categorization is a major part of ontology and this is the first categorization exercise!) Themes are a step toward diagnosing a problem; finding the root cause of as many problems as possible is the objective of this part of the exercise. The categorization process also helps people in the organization understand how problems and processes are related and how addressing one class of problem will make many others disappear.
3.Translate themes into conceptual solutions. Developing conceptual solutions by considering all the possibilities gets people thinking creatively and without constraints. A solution can be as obvious as asking, “Wouldn’t it be great if we could . . . ?” and answering the question with the absence of the problem. For example, my problem is that I can’t find things. Wouldn’t it be great if I could find the document I wanted within 30 seconds? But of course, we need more detail than that—what things are we trying to find? During what process? To accomplish what task?
4.Develop scenarios that comprise solutions. This is getting to the next level of detail. What does the solution look like? What do people need to do? What would a day in the life of a worker look like if this new capability were in place? How exactly would people go about solving their problem or doing their job?
5.Identify audiences whom the scenarios affect. Sometimes the scenario involves just a few audiences (e.g., customers and marketing), while at other times, it has an effect on every department. When the solution or problem impacts many other groups, that means the value of the new capability extends beyond solving the initial problem. This step also identifies other potential stakeholders, decision-makers, process owners, funding sources, operational bottlenecks, constraints, benefits, and dependent processes.
6.Articulate tasks that audiences execute in scenarios. This is another layer of granularity to the context and solution scenarios. Now we are at the ground level of detailed tasks that people have to accomplish. As we go deeper, we are uncovering more layers of detail and more nuances.
7.Build detailed use cases around tasks and audiences. Use cases are the next layer of detail. These are the testable assumptions about what an individual has to do to achieve the outcome described in a step-by-step manner. This level of detail is not always needed and can become painstakingly elaborate. However, after you develop use cases, you can categorize and generalize them so that one type of use case can become a model for dozens of similar ones.
8.Identify content needed by audiences in specific use cases. We are finally at the level of understanding what people need. Where do they go for answers, information, or inputs? What piece of information do they need? What do they call it? What do others call it?
9.Develop organizing principles for data and content. Now we can describe a piece of information. Imagine that I hand you a document or fact. What is it? Is it a contract? A policy? A risk profile? A customer record? That is what we call the “is-ness.” The next question you need to ask is, If I had one thousand pieces of that thing, how would I tell them apart? If they are contracts, what kinds of contracts? What piles would I put them in? How many different types of piles could I create? For example, I could classify them by contract type, by region, by customer type, by issue, by topic, and so on. These characteristics are what we call the “about-ness” of the information. Is-ness and about-ness are the metadata descriptors of the content. Each kind of is-ness forms a vocabulary. Each kind of about-ness also forms a vocabulary. Those vocabularies are also organized into hierarchies—taxonomies. When you have created the relationships among taxonomies and described all of the different types of information and ways of describing that information, you have developed your ontology. Table 2-1 summarizes this method.
The Data- and Content-Centric Approach to Ontologies
The user- and problem-centric approach to ontologies is more generally applicable, but it doesn’t always create a complete picture. The data- and content-centric approach can be helpful as well.
Sometimes the ontology problem is presented as a pile of data that needs to be better organized—perhaps a website, an intranet, a knowledge base, or a content or document repository. This approach, while starting with the data, still needs a context, though that context can be quite broad. A starting point for analyzing that context is to gather groups of stakeholders together and provide packages of sticky notes and markers to each person in the room. The objective is to write down, as quickly as possible, everything that they work with on a day-to-day basis. You must be thinking, “Seriously? That would take forever.” This is actually a speed-and-volume exercise. Recall that I started with context—the context could be a department, such as marketing, sales, engineering, or finance. Each of these groups will be able to write down at least 20 or 30 items on sticky notes that represent their information interactions.
The exercise can be very revealing. Sometimes people stay at too high a level and say things like “documents,” “email,” or “communications.” In that case, we go back and say “Try again”: What kinds of documents? What are the emails about? The goal is to get as granular as possible. Then the group places their sticky notes on a wall of flip-chart pages and tries to group them into logical groupings. Sometimes they end up with very large buckets, a result that reveals a group of “lumpers”—people who like to combine things. At other times they are split into numerous categories—a characteristic of “splitters,” who like to separate things. You need to repeat this exercise with multiple different groups to get a sense of the elements and classifications they consider to be important. This process can inform the mental model of the user and then lead to the development of organizing principles that can be applied to knowledge bases and document repositories.
Table 2-1: Steps in the User- and Problem-Centric Method of Creating an Ontology
| Process Step | Answer the Following | Examples |
| 1.Observe and gather data (pain) points | What are the specific problems and challenges that users are identifying? | “We can’t locate information about policies for specialty coverage.” “We need to look in multiple systems to find prior experience data when underwriting new policies in high risk areas.” “Different terminology is used in different systems, which makes queries difficult.” |
| 2.Summarize into themes | What are the common elements to observations? How can symptoms and pains be classified according to overarching themes? | Inability to locate policy and underwriting information using common terminology |
| 3.Translate themes into conceptual solutions | Wouldn’t it be great if we could . . . ? | Wouldn’t it be great if we could access all policy and prior experience data across multiple systems using a single search query and return consistent results? |
| 4.Develop scenerios that comprise solutions | What would a day in the life of a user look like if this solution were in place? | At a high level, describe how underwriters go about their work in writing policies for specialty and high-risk clients. Describe each potential situation and how they would go about their work. |
| 5.Identify audiences whom the scenarios affect |
|
