CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 32, NO. 1
  

We’re going to make some business people cringe right off the bat with this claim: there is an ontology in your near future. In this article, we will explain what that means and why we assert it.

Over the last 25 years, we’ve developed and perfected ways to model information — objects, classes, attributes, and relations — as well as activities and behaviors. There’s all this and more in the the Unified Modeling Language (UML) or, for complex systems, in the Systems Modeling Language (SysML), which might make you think we’ve reached modeling perfection. Sorry — but we’re going to disappoint you.

The system of systems that powers the modern enter­prise has become increasingly complex and inter­dependent. Each system has its own requirements, designs, and implementations. Each design has purpose-specific data architectures and schemata, reflecting the unique perspectives of the system’s stakeholders and unique implementation demands. As a result, the models developed to specify “system A” rarely contain the same definitions, relationships, constraints on data values, and so on, of various data objects as the models describing “system B.”

It doesn’t help that models rely on the ambiguous meanings of words in natural languages. In an oil company, for example, what a production engineer calls a “well” could be multiple “wells” to a driller. Similarly, different units of a bank may use the word “loan” or “transaction” to mean different things. In this system-of-systems scenario, we end up with application silos not just because people work separately in different parts of the organization, but because it is onerous or impossible to integrate systems that assume different semantics for a loan, a transaction, or an oil well. Data quality suffers, too. If systems A and B have different rules for entity E, what’s acceptable to A may be garbage when received by B.

So we need an approach to integrate these systems and designs, and to provide a common vocabulary and common semantics for what our data means across the system of systems. We’re not going to resolve fragmented data architectures by superimposing another data architecture on top! To federate designs and integrate data, we need a set of concepts that lasts, that reflects what the enterprise really does and what it is about — the concepts of the business, regardless of how we implement them.

We need to capture precisely the deeper meaning of “things” (customers, orders, assets, missions — whatever is the focus of the enterprise) in a machine-processable model, complete with relations, properties, constraints, rules, derivation formulas, and so on. This, in short, is what an ontology is.

This model of the business is not a data model but rather a reference (in business terms) for what data means to the business. Any particular stakeholder can take this common understanding and pivot to understand or design the data and messages that power specific systems. With a common, coherent model, data can be more easily integrated, shared, and federated. The information that supports processes, services, and business rules can be understood and traced through the system of systems in support of governance, integration, sharing, machine learning, and analytics.

Ontologies are more complete, powerful, and complex than taxonomies because they add all this semantic knowledge, couched in formal logic terms. In the ANSI definition of “controlled vocabularies,” you find lists (i.e., glossaries), taxonomies (glossaries plus synonyms and hierarchical relationships), and thesauri (taxonomies plus relationships other than “is a kind of”). Ontologies go further: they also tell you complex relationships (such as “a person can only be a car renter if his or her age is 25 or above”), which a taxonomy cannot represent.

Thinking in terms of a layered enterprise architecture framework, with the business strategy at the top and the computing infrastructure at the bottom, an ontology is close to the top level; it models the business capabilities and business processes across the entire organization. A UML model of a system, by contrast, lives at the lower level of individual applications and the data they manipulate. Once you have created an ontology for your business, there are semantic tools that you can use to automate many functions or derive additional logical consequences. And, as mentioned earlier, you can also use the ontology to derive consistent application-specific models.

This movement from system-specific data models to business-wide information models presents some challenges:

• Ontologies require understanding formal logic concepts. These include concepts such as intersection, union, implication, transitive relationships, existential qualifiers, and so forth. This comes more naturally to people who have had a good dose of math education — from the high school level and up.

• Some of the ways in which ontologies are expressed, such as the Web Ontology Language (OWL), are not easy for business users to understand. OWL looks like code. But ontologies can also be expressed in relatively simple graphical notations like UML, using a conceptual modeling profile. For those who are inclined to use OWL, massive open online courses offered by Coursera, Udemy, and others have made the training quite accessible.

• Ontology specialists are a bit like a secret society. They have special handshakes and speak in their own language. They tend to assume that the need for an ontology is going to be obvious to a business person, but the casual mention of the “O” word in the first conversation may send their client running away.

The good news is we are starting to see some real movement toward adoption. A multiyear collaboration between the Object Management Group (OMG) and the Enterprise Data Management (EDM) Council has produced the Financial Industry Business Ontology (FIBO), an expanding collection of standards that define financial instruments and concretely help financial institutions implement compliance with regulations such as the US Dodd–Frank Wall Street Reform and Consumer Protection Act. The number of vertical industry conferences, working groups, and standards committees that have the word “ontology” in their title is still small, but it is no longer zero. As a result, this work is very doable, even if it does take a reorientation of thinking from modeling data for a specific solution to modeling the business as a reference. The benefits will include integration, analytics, governance, and inference.

In the next few years, more industry sectors will discover the need for, and benefits of, a complete semantic model of their businesses. (And you know a concept promoted by IT people is important when it is mentioned in a prominent business journal like Forbes.) So, fear not, but learn what an ontology (or “business information model,” if you prefer) is and how to benefit from developing one before the lack of one becomes a disadvantage.