Ontology-Driven Analysis

If, like me, you haven’t come across the word ‘Ontology’ since long-ago college days in giant dusty tomes, here’s a quick refresher of its definition:

on·tol·o·gy
änˈtäləjē/
noun
1. the branch of metaphysics dealing with the nature of being.

So what does the nature of being have to do with software development? A lot, actually.

In the role of analyst, I like to describe my job as “organizer of chaos.” The first step to organizing chaos is taking inventory. This is where the concept of ontology becomes incredibly useful.

I can’t speak to metaphysics, but one way ontology helps in the field of software development is by providing a structure to help understand the objects, classes, relationships, concepts, stakeholders, external systems, and basically anything and everything you might come across in research and requirements gathering. However, ontology is more than just an ERD. It’s an accounting of all elements, both tangible and intangible, that impact the world in which your system operates. And using an ontology helps you see that your system is more than just the software - it also includes the people, organizations, and other systems that interact with it either directly or indirectly, and how their influence is represented within the software design.

The use of ontology in software development is backed up by a credible body of research and documentation 1.

1For additional research or study, you may be interested in the following books or whitepapers: http://www.springer.com/us/book/9783642312250, http://www.hpl.hp.com/techreports/2005/HPL-2005-13.html, https://km.aifb.kit.edu/ws/swese2006/final/happel_full.pdf

I’ll let you spend your own time reading the academic explanations, and try to break down in layman’s terms how you can use ontology as a tool in your analysis efforts. I’m a visual learner, so I’ll start with a few examples from previous work I’ve done2.

2I've streamlined the objects represented and removed any identifying information to protect client confidentiality in a way that should not detract from the overall readability of the representation.

The first example depicts the ontology for a system that supports and tracks information related to regulated entities. Throughout the process of gathering requirements, we made an effort to map all of the ideas, concepts, and entities along with their relationship to the primary entity in our system. For our purposes, the regulated entity itself was the focus of our perspective, and everything else in the system would be defined by its relationship to this entity. So, for our ontology we placed the regulated entity at the center, and mapped the relationships in an expanding circle of concepts.

This approach helped us identify not only the technical design, but also laid the foundation for our basic user experience. Using the ontology as a guide, we developed a workflow that allowed the user to navigate from the regulated entity home screen (middle of the ontology) to the next levels, and from there drill down to more detailed information.

Regulated Entity Ontology

Another example comes from the creation of an accounts receivable system. For this system, we had to identify many different kinds of concepts and relationships within the system. The ontology below captures the concepts related to facilities and their organizational structures and relationship to one another through parent companies, financial transactions, revenue, types of revenue, programs, and other details. Developing an ERD and the resultant database structure for this project was incredibly complex; however, the creation of an ontology made this effort a much more structured and informed process.

Accounts Receivable Ontology

How you structure the ontology is going to vary based on the purpose and nature of the system. The ontology is something that you should expect to refine and grow as you learn more about the project.

The ontology can contain representations of high level business rules, requirements, or validations, but should contain only those which are necessary for understanding the vital relationships between elements of the system. The ontology should contain a representation of all of the major elements with which a user can interact.

Creating an ontology is an extra effort that must also be supported with proper requirements and technical documentation such as an ERD, but provides a tangible benefit to the team. Ontology provides some of the big-picture context that many project deliverables are lacking, and can help orient the client and the project team to the concepts and relationships that make up the foundations of the system in a very easy to read way.

A properly structured ontology can serve as both a tool for analysis and design, as well as testing. A visual representation of the universe in which your system operates can help you identify not only happy path workflows but also edge cases and exceptions by looking at objects that don’t seem to connect with one another. Can two boxes that do not share a link be related to one another in the system? Can a user successfully navigate from one item on the ontology to another? Does the system navigation map accurately to the organization for the ontology? Are all items listed in the ontology covered by a test case?

One final benefit of creating an ontology is that it can help serve as an orientation tool for training and user help files. It easily provides context to users on the basic rules and relationships upon which the system was built, and can, with some adjustment, be used as the organizational basis for the creation of end user documentation.

I know that some of the articles and publications I’ve linked to can provide a much more thorough and advanced understanding of the concepts related to ontologies and their use in the semantic web but I hope that my examples can at least show you the benefit of thinking ontologically, and perhaps inspire you to explore this approach on your next project.