The Ontology *is* the Business

Admit it. Lots of you recoil a little bit when I wander off into discussions of ontology. It sounds so academic, so far from the practical. Maybe someone down in the trenches has to think about ontology, but surely it is not a business interest.

This is exactly wrong. Ontology is discovering the meaning in facts. Ontology is what gets discussed in the executive suite. Ontology is what is going to turn the meaningless details of building systems into new services, new money machines. Ontology is what turns process into service.

By example, consider accounting. At the low end there are clerks and bookkeepers. Their concerns are in properly classifying each event. Assign a name to each number, and make sure they balance. The math is trivial; the problems of introductory accounting are semantic problems of classification. Bookkeeping is never strategic. We use it to keep score. No one wants to be told what to do by the bean counters.

Bookkeeping turns into accounting when it begins to be used for making decisions. There can be several ways to do cost accounting to understand the problems of manufacture or of construction.. Financial ratios normalizes the books so you can compare the prospects of different businesses. The focus of accounting move from what ledger to put each item on to how do I understand the business.

Accounting grows from bookkeeping when we need ontologies created from the underlying semantics. (Well, or when we need a compliance framework, but I feel that is actually similar.) ERP establishes a common ontological framework for all the activities of an enterprise. The primary purpose of today’s sophisticated business software is ultimately ontological processing of the underlying process oriented semantic information.

This observation is allied with the truism that it is very difficult to apply a service oriented architecture to a procedure oriented enterprise, while it is straightforward to do so to a service oriented enterprise. Colleges and Universities often represent the quintessential procedure oriented enterprise, with little regard for outcomes and a slavish devotion to their pieces of paper and the processes they represent. You may remember how easy they are to work with.

Building systems are, for the most point, struggling upward to get to semantics. We know how to describe the low level actions. oBIX has provided a base syntax for semantic expansion, but does not yet provide all the nouns. Progress has been made. Yet even if we get fully fleshed out semantics for building systems, we will still not be at the right level for enterprise interaction.

Enterprise programmers cannot have a fruitful conversation with the inner processes of the building systems, no matter how semantically complete. As I believe these processes will more and more be self tuning and self managing, neither will anyone else except during configuration.

Large-scale integration and wide-scale integration, in which many systems are integrated and each system agent responds to many other actors, will require to conversations of two sorts. Enterprise programmers need to be able to specify the service they desire, and the price they are willing to pay for it. Building systems need to accept the terms, and be able to provide quality of service (QOS) or conformance information back.

And for that, we need an ontology of building service performance.