>Classification Schema and Enterprise Architecture


User-centric Enterprise architecture captures organizational information, analyzes it, and classifies it, and serves it up to the end user in useful and usable ways to enhance decision-making.

I came across a helpful article in DM Review, May 2008, called “Ontology and Taxonomy” that clarified the classification schemas used in EA.

First of all what the heck is a classification schema?

Simply put, a classification schema is a way of organizing information by putting things into categories. This helps us make sense of the information by being able to relate items to one another. For example, is an item, part of a larger supertype? Does an item has subtypes? Are items part of a common set? Is there a one to one relationship, a one to many, or a many to many? An understanding of these relationships between information helps us to understand the information and better use it for sound decision making.

Here are the two classification schema:

  1. Ontology—“includes putting things into categories and relating these categories to each other…an ontology is a model…’ontology concerns itself with the organization of knowledge’…the body of knowledge includes both class and instance.” Ontologies define relationships. In ontologies, we identify the intersection of different items with each other, so for example a man intersects with “person,” “male,” and “adult.”
  2. Taxonomy—“A taxonomy is an ontology in the form of a hierarchy.” Typically, taxonomy takes the form of a tree diagram, with parent (class) and child relationships. Taxonomies are decompositions. “For example, a parent may be automobiles and the children may be trucks, SUVS, sedans, compacts, and so on. Then the children for trucks may be pick-ups, vans, refrigerated, etc.

One of the problems with taxonomies is that you cannot easily define everything neatly into categories and subcategories, such as in cataloging a body of knowledge. For example, in the Dewey decimal system, “Where do you put a book about the history of mathematics in the Islamic world? History? Mathematics? Religion? That points out the problem with most taxonomies. Most of our knowledge is not hierarchical.”

The limitation of taxonomies is why we need to use more sophisticated ontologies such as business, data, and system models in enterprise architecture to understand the complexity of the relationship between business processes, information required to perform those, and the systems that serve those up.

>John Zachman and Enterprise Architecture

>In the Journal of Enterprise Architecture, February 2008, John Zachman, the father of EA, talks about core definitional elements of enterprise architecture.

  • Enterprise versus IT or Applications Architecture—”First Enterprise Architecture constitutes a paradigm shift and many people have not yet been inclined to make the mental, cultural, and behavioral adjustment to engineering and manufacturing the enterprise” and I love that phase—engineering the enterprise!

“Because…many of the skills required to the work of enterprise architecture are typically found in the Information Systems community, some people misconstrue the Framework intent as an Information Systems schema rather than its true intent as an ENTERPRISE schema.”

And not only is the Zachman Framework misconstrued as an Information Systems schema, but many people mistakenly confuse the whole EA with IT or applications architecture. But EA is not focused on IT or applications, but rather on the overall organization—the enterprise.

  • Lexicon—“As global communication and collaboration expands, there is an increasing requirement for semantic coherence. If people’s words do not mean the same thing, there is neither communication nor collaboration”—another good one, semantic coherence!

Without a lexicon with common definitions and standards for usage, we will not be talking to each other, but past each other.

Moreover, if we can’t even define EA elements in a common way, then how can we ever make them interoperable?

As Zachman says, “The underlying classification and components of architecture must be consistent for any interoperability (internal or external) to be effected.”

  • Classification, Taxonomy, and Ontology—“Enterprises are complex. Managing the knowledge base of the enterprise that is required for enterprise operation and change is complex. The key to managing complexity is classification.”

This is so true. We need to categorize and relate items to make sense of them. Moreover, I would say we need to roll this information up to what I call the profile level—the big picture, strategic view using information visualization—so that our executives and decision makers can quickly understand the information and come to a decision point.

“Humanity for seven thousand years has found no mechanism for accommodating complexity and change other than architecture,” says Zachman.

EA is the way to plan, manage, and measure change in our increasingly complex world. And if we don’t take control over our enterprises and their future destiny, then we will be controlled by them.

>Taxonomy, Ontology, and Enterprise Architecture


The terms Taxonomy and Ontology are frequently confused; here are some basic definitions:

“Taxonomy is the practice and science of classification…Taxonomies, or taxonomic schemes, are composed of taxonomic units known as taxa (singular taxon), or kinds of things that are arranged frequently in a hierarchical structure, typically related by subtype-supertype relationships, also called parent-child relationships. In such a subtype-supertype relationship the subtype kind of thing has by definition the same constraints as the supertype kind of thing plus one or more additional constraints…Originally the term taxonomy referred to the classifying of living organisms (now known as alpha taxonomy); however, the term is now applied in a wider, more general sense and now may refer to a classification of things, as well as to the principles underlying such a classification. Almost anything — animate objects, inanimate objects, places, concepts, events, properties, and relationships — may be classified according to some taxonomic scheme.”

Ontology─ “In both computer science and information science, an ontology is a data model that represents a set of concepts within a domain and the relationships between those concepts. It is used to reason about the objects within that domain. Ontologies are used in artificial intelligence, the Semantic Web, software engineering, biomedical informatics and information architecture as a form of knowledge representation about the world or some part of it. Ontologies generally describe:

  • Individuals: the basic or “ground level” objects
  • Classes: sets, collections, or types of objects
  • Attributes: properties, features, characteristics, or parameters that objects can have and share
  • Relations: ways that objects can be related to one another
  • Events: the changing of attributes or relations”

“If you did not define attributes for the concepts you would have either a taxonomy or a controlled vocabulary. These are useful, but are not considered true ontologies.” (Wikipedia)

What is the real difference between taxonomies and ontologies?

A Taxonomy is a hierarchical representation of a specific data set…Taxonomies are useful in software for navigation, in fact Amazon.com does something like this. You select “Books”, and you can then select a subcategory, and drill down from there.

An Ontology is a set of concepts and the relationships between them. Concepts are nouns, and relationships are verbs. Two commonly used relationships are “is a and “has a“. Concepts have attributes, which are things that describe the concept. For instance, there is a concept “Retirement Account”. An IRA is a retirement account, and a 401(k) is a retirement account. An IRA “has a” balance. A balance is itself a concept, that has a “date” attribute and an amount attribute. In computer science, these things are relevant for areas such as search and text analysis…

That is the basic difference: ontology defines concepts and how they relate, and a taxonomy is a hierarchical breakdown of items.”


How are taxonomy and ontology used in EA?

For User-centric EA, taxonomies are useful for categorizing the elements of the enterprise into a useful and usable architecture. For example, in the business architecture, we use a taxonomy to classify our organization’s functions into core mission, mission support, and business support categories. The taxonomy adds value by providing context and depth to the information.

Additionally, ontology is necessary in enterprise architecture for identifying the relationships between elements in the architecture and for building the information repository in a relational database. For example, Systems are related to the business functions they support as well as to the underlying technologies that make up the system. The relationships between the perspectives of the architecture (performance, business, information, services, technology, security) and their elements is actually where core value from the information is derived from. Each perspective of the architecture has important information, but it is in relating the information, that deeper analysis becomes possible. For example, in a straight taxonomy of systems and applications, we may understand what systems and how many the organization has; however, when we relate those systems, for example, to functional areas, then we can see which functions have redundant systems or gaps and which are mission critical systems based on the functions they support.

The use of both taxonomy and ontology is important and necessary to structures the enterprise architecture and to analyzing it and provide meaningful findings and recommendations.