Showing posts with label Classification. Show all posts
Showing posts with label Classification. Show all posts

May 16, 2008

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.


Share/Save/Bookmark

March 4, 2008

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.


Share/Save/Bookmark