>The Awesome Implications of Gmail and Enterprise Architecture

>Recently, I took the leap from Yahoo! and added a Gmail Account.

For a long time, I thought, “What can be the difference? E-mail is e-mail.” Further, I thought people were just switching because it was the latest fad, and they wanted to be associated with the then-upcoming Google versus the troubled Yahoo!

While this may be partly true, there are some tangible advantages to Gmail. Gmail has a better interface than Yahoo!—it provides one look and feel while Yahoo! has a switching mechanism between the legacy email and a new Yahoo! mail, which is still kind of quirky. Gmail better integrates other tools like instant messaging and VOIP. Gmail offers a huge amount of storage. Gmail associates email strings so you can easily expand or click through the chain.

And finally, Gmail has a label structure for emails versus Yahoo’s folder structure. This is the one that matters most.

The label structure is superior to the folders. You can have multiple labels for an e-mail and can therefore locate items of interest much more easily by checking in any of the pertinent label categories. In contrast, in the Yahoo! folder structure, you can only store the e-mail in one folder, period. This makes it it difficult to store, connect, and discover items that cross categories.

For example, if you have e-mails on enterprise architecture topics from a particular source, you may want to label it by the topic EA and by the source it came from, so in the future you can find it by topic or by source.

Reflecting on this archiving structure from an enterprise architecture perspective, it became apparent to me that the legacy folder structure used in Yahoo! mail and the typical Microsoft Office applications such as Outlook and My Documents is built according to a typical taxonomy structure. By this I mean that here are one “parent” to multiple “children” relationships (i.e. a folder has one or more files/emails, but a file/email is constrained to only one folder).

However, in Gmail, the archiving structure is built according to an ontology structure, where there are multiple relationships between objects, so that there is a many-to-many relationship. (i.e. a label category can have multiple files/emails and files/emails can be tagged to many labels)—a much more efficient and expansive metadata structure.

So in short, the analogy goes like this–

Folder structure : Taxonomy : : Labels : Ontology

And Google wins in e-mail archiving hands down!

In enterprise architecture, the implications are enormous. For example, Microsoft, which is the defacto standard in most of our organizations, rules the way we store files in the legacy folder structure. Perhaps, the time has come for us to evolve to the superior metadata structure using labeling. This will make it far easier and more productive for the average user to search and discover information they need.

Further, metadata is at the heart of enterprise architecture, where we seek to break down the siloes in and between our organizations and make for better interoperability and information sharing. The goal is a holistic view of what’s going on in our organization and between organizations, and the only way to achieve that from an IT perspective is to label information so that it is discoverable and usable outside stereotypical stovepipes.

>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.

>Web 3.0 and Enterprise Architecture

>

While the Web 1.0 is viewed as an information source, and Web 2.0 as participatory, Web 3.0 is envisioned as Semantic (or the Semantic Web).

MIT Technology Review, March 2007 reports in an article entitled “A Smarter Web” by John Borland that Web 3.0 will “give computers the ability—the seeming intelligence—to understand content on the World Wide Web.” The goals is to “take the web and make it …a system that can answer questions, not just get a pile of documents that might hold an answer.”

In The New York Times, November 2007, John Markoff defined Web 3.0 “as a set of technologies that offer efficient new ways to help computers organize and draw conclusions from online data.”

Not only individuals would benefit from the Semantic Web, but companies too that “are awash in inaccessible data on intranets, in unconnected databases, even on employees’ hard drives.” The idea is to bring the data together and make it useful.

Many of you have heard of the Dewey Decimal System for organizing information. Melvin “Dewey was no technologist, but the libraries of his time were as poorly organized as today’s Web. Books were often placed in simple alphabetical order, or even lined up by size…Dewey found this system appalling: order, he believed, made for smoother access to information.” (MIT Technology Review) Melvin Dewey developed in 1876 what became The Dewey Decimal System, a library classification attempts to organize all knowledge.” (Wikipedia) In the Dewey system, books on a similar subject matter are co-located aiding discovery and access to information.

MIT Technology Review contends that like Melvin Dewey, web browser and search engine companies, like Microsoft and Google, want to help consumers locate information more efficiently.

“By the mid-1990’s, the computing community as a whole was falling in love with the idea of metadata, a way of providing Web pages with computer-readable instruction or labels…metadata promised to add the missing signage. XML—the code underlying today’s complicated websites, which describes how to find and display content, emerged as one powerful variety.” The problem with this was that it was not a systematic way of labeling data, since each developer used “their own custom ‘tags’—as if different cities posted signs in related but mutually incomprehensible dialects.”

In 1999, the World Wide Web Consortium (W3C) came up with the Resource Description Framework (RDF) for locating and describing information. Since then the vision has been for “a web that computers could browse and understand much as humans do…analogous to creating detailed road signs that cars themselves could understand and upon which they could act,” independent of human action. However, the obstacles remain for how to create ontologies that everyday busy people would use to relate data across the web—data that is currently described in myriad number of ways today—so that computers could then read and understand the data.

A second area of doubt on the realism of a Semantic Web is whether computers can truly understand the intricacies (or connotations) of human language. For example, can a computer realistically make sense of a word like marriage that can have subtle distinctions of “monogamy, polygamy, same-sex relationships, and civil unions?”

Despite the perceived obstacles, many remain not only fixated, but enamored with the notion of a Semantic Web that can not only provide amazing amounts of information, but also, like a human being, is able to analyze the data holistically, and provide actionable artificial intelligence (AI).

To enterprise architects, the Semantic Web (or Web 3.0) would be an incredible leap forward enabling organizations and individuals to get more intelligence from the web, be more productive, and ultimately provide for more efficient and effective business processes, supported by a higher order of computing enablement. Additionally, for enterprise architects themselves that deal with inordinate amounts of business and technical data—structured and unstructured—Web 3.0 technologies and methods for better mining and analyzing the data would be a welcome capability for advancing the discipline.

>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.”

(http://koolplaces.blogspot.com/2007/02/so-what-is-difference-between-taxonomy.html)

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.